Re: Hot Backup with rsync fails at pg_clog if under load - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Hot Backup with rsync fails at pg_clog if under load
Date
Msg-id CA+U5nMKx-N5Qmn6FwpvSoLhTqDp70U+tWJ59=t=--KUH3uhP7g@mail.gmail.com
Whole thread Raw
In response to Re: Hot Backup with rsync fails at pg_clog if under load  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Hot Backup with rsync fails at pg_clog if under load  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Oct 27, 2011 at 4:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Oct 26, 2011 at 12:16 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> This fixes both the subtrans and clog bugs in one patch.
>
>> I don't see the point of changing StartupCLOG() to be an empty
>> function and adding a new function TrimCLOG() that does everything
>> StartupCLOG() used to do.
>
> +1 ... I found that overly cute also.

It would have been even easier to move StartupCLOG() later, but then
we'd need a big comment explaining why CLOG starts up at one point and
subtrans starts up at another point, since that is very confusing way
of doing things. I wrote it that way first and it definitely looks
strange.

It's much easier to understand that StartupCLOG() is actually a no-op
and that we need to trim the clog at the end of recovery in all cases.

The patch isn't meant to be cute, just a better of way of expressing
what needs to be done, so I think the patch should stay that way.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Updated version of pg_receivexlog
Next
From: Fujii Masao
Date:
Subject: Re: Updated version of pg_receivexlog