Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Fri, Feb 12, 2016 at 12:56 PM, Andres Freund <andres(at)anarazel(dot)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(at)anarazel(dot)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?

I don't think that it's a bad thing to have a simple interface for
simple use cases and a complex one for more complex cases. I don't
feel any need to convert every use of ReadBuffer() in the source code
to ReadBufferExtended(), for example. Nor do I feel like we should
have changed every call to LockAcquire() instead of introducing
LockAcquireExtended(). This case seems analogous, and there are a few
advantages. One is that it avoids creating meaningless conflicts when
back-patching. Another is that when a function gets an extra
argument, that often turns out to be something that happens more than
once. It's nice not to keep having to whack around every call in the
tree every time the call signature changes. Also, finding the small
number of callers that need non-default behavior is simplified,
because you can just grep for the Extended version of the function and
there won't be many hits.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company