This should of course be rsync -a ... . Much better now :-)
Sorry for this extra round.
On Tue, Apr 12, 2011 at 2:32 PM, Gerhard Hintermayer <
gerhard.hintermayer@gmail.com> wrote:
> my basebackup is done via the following ($1 is the parameter for the
> server where the basebackup is taken from)
>
> rsync -r --delete --progress ${1}::postgresql-data/
> /var/lib/postgresql/9.0/data/
>
> Am I doing something wrong here ? I rsync _over_ the existing data dir.
>
> Gerhard
>
> On Mon, Apr 11, 2011 at 9:06 PM, Kevin Grittner
> <
Kevin.Grittner@wicourts.gov> wrote:
>> Gerhard Hintermayer <
gerhard.hintermayer@gmail.com> wrote:
>>
>>> Just checked my indices, looks like the only table in all my 5
>>> DB's that has a hash index is the one I ran tests on.
>>
>> Well, actually that's pretty lucky. If you'd tested with other
>> indexes, you might have gone live with the broken index. I would
>> seriously consider converting the index to btree at this point, to
>> simplify life, unless you can show a significant performance benefit
>> with the hash index running your actual application mix.
>>
>>> But the other thing is the huge amount of transfer volume when
>>> rsyncing the data dir from the new primary to set up the new
>>> replication slaves. But this should go away when I stop using
>>> REINDEX DATABASE, right ?
>>
>> That should make a big difference, yeah.
>>
>> -Kevin
>>
>
