On Tue, Apr 19, 2016 at 11:02 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Andres Freund wrote:
>> On 2016-04-19 12:03:22 -0300, Alvaro Herrera wrote:
>
>>>> Since this change to BufferGetPage() has caused severe back-patch
>>>> pain for at least two committers so far, I will revert that (very
>>>> recent) change to this patch later today unless I hear an
>>>> objections.
>>>
>>> I vote for back-patching a no-op change instead, as discussed elsewhere.
>>
>> What about Tom's argument that that'd be problematic for external code?
>
> Kevin offered to code it in a way that maintains ABI and API
> compatibility with some trickery.
I pointed out that it would be possible to do so, but specifically
said I wasn't arguing for that. We would need to create a new name
for what BufferGetPage() does on master, and have that call the old
BufferGetPage() on back-branches. That seems pretty ugly.
I tend to think that the original approach, while it puts the
burden on coders to recognize when TestForOldSnapshot() must be
called, is no more onerous than many existing issues coders much
worry about -- like whether to add something to outfuncs.c, as an
example. I have been skeptical of the nanny approach all along,
and after seeing the impact of having it in the tree for a few
days, I really am inclined to pull back and put this on the same
footing as the other things hackers need to learn and tend to as
they code.
> Robert Haas wrote:
>
>> That wouldn't have fixed my problem, which involved rebasing a patch.
>
> True. I note that it's possible to munge a patch mechanically to sort
> out this situation.
I admit it is possible. I'm becoming more convinced with each post
that it's the wrong approach. I feel like I have been in the
modern version of an Æsop fable here:
http://www.bartleby.com/17/1/62.html
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
