On Wed, Sep 21, 2011 at 12:22 PM, Euler Taveira de Oliveira <eu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers