Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
Date
Msg-id CAB7nPqSxxo77VfUoABJ6oXtDsgkKuXwpTn5FTsuoe_L=sej-Ww@mail.gmail.com
Whole thread Raw
In response to Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
List pgsql-hackers
On Sat, Feb 13, 2016 at 1:01 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Feb 12, 2016 at 12:56 PM, Andres Freund <andres@anarazel.de> wrote:
>> On 2016-02-12 12:37:35 -0500, Robert Haas wrote:
>>> On Mon, Feb 8, 2016 at 4:18 AM, Andres Freund <andres@anarazel.de> wrote:
>>> > I'm not really a fan. I'd rather change existing callers to add a
>>> > 'flags' bitmask argument. Right now there can't really be XLogInserts()
>>> > in extension code, so that's pretty ok to change.
>>>
>>> Yeah, but to what benefit?  You're just turning a smaller patch into a
>>> bigger one and requiring churning a bunch of code that wouldn't
>>> otherwise need to be touched.  I think Michael has a good point.
>>
>> It has the advantage of not ending up with an extra interface, that
>> we're otherwise never going to get rid of? If not now, when would we
>> remove it? Sure it touches a few more lines, but that's entirely trivial
>> mechanical changes, so what?

Note: the patch has grown from 15kB to 46kB by switching to the
extended interface to the addition of an argument in XLogInsert().

> I don't feel that there's only one right way to do this, but I think
> Michael's position is both reasonable and similar to what we have done
> in previous cases of this sort.

To be honest, my heart still balances for the Extended() interface.
This reduces the risk of conflicts with back-patching with 9.5.
-- 
Michael



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: schema PL session variables
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.