Re: Hot Backup with rsync fails at pg_clog if under load

From: Linas Virbalas <linas(dot)virbalas(at)continuent(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot Backup with rsync fails at pg_clog if under load
Date: 2011-09-23 15:36:26
Message-ID: 7642135A793F9C41B8DCC83FF7DC7CB1FA494C65@EXVMBX003-1.exch003intermedia.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> But on the standby its size is the old one (thus, it seems, that the size
>> changed after the rsync transfer and before the pg_stop_backup() was
>> called):

> Now that seems pretty weird - I don't think that file should ever shrink.

It seems, I was not clear in my last example. The pg_clog file doesn't shrink. On the contrary, when rsync kicks in it is still small, but after it completes and somewhere around the pg_stop_backup() call, the pg_clog file grows on the master. Hence, it is left smaller on the standby.

> Are you sure that the rsync isn't starting until after
> pg_start_backup() completes?

100% - the procedure is scripted in a single threaded application, so rsync is started only after pg_start_backup(...) returns.

> Because if you were starting it just a
> tiny bit early, that would explain the observed symptoms perfectly, I
> think.

I agree, but that is not the case.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2011-09-23 15:36:31 Re: [pgsql-advocacy] Unlogged vs. In-Memory
Previous Message Greg Stark 2011-09-23 15:22:09 Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)