On Wed, Sep 21, 2011 at 12:22 PM, Euler Taveira de Oliveira
<euler@timbira.com> wrote:
> [This question doesn't belong to -hackers. Please post it in -general or
> -admin]
-hackers or -bugs seems appropriate to me; I think this is a bug.
>> 2.2. pg_start_backup(Obackup_under_loadš) on the master (this will take a
>> while as master is loaded up);
>
> No. if you use pg_start_backup('foo', true) it will be fast. Check the
> manual.
If the server is sufficiently heavily loaded that a checkpoint takes a
nontrivial amount of time, the OP is correct that this will be not
fast, regardless of whether you choose to force an immediate
checkpoint.
>> 2.3. rsync data/global/pg_control to the standby;
>
> Why are you doing this? If ...
>
>> 2.4. rsync all other data/ (without pg_xlog) to the standby;
>
> you will copy it again or no? Don't understand your point.
His point is that exercising the bug depends on doing the copying in a
certain order. Any order of copying the data theoretically ought to
be OK, as long as it's all between starting the backup and stopping
the backup, but apparently it isn't.
> The problem could be that the minimum recovery point (step 2.3) is different
> from the end of rsync if you are under load.
It seems pretty clear that some relevant chunk of WAL isn't getting
replayed, but it's not at all clear to me why not. It seems like it
would be useful to compare the LSN returned by pg_start_backup() with
the location at which replay begins when you fire up the clone.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company