Re: snapshot too old, configured by time

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > I disagree. A developer that sees an unadorned BufferGetPage() call
> > doesn't stop to think twice about whether they need to add a snapshot
> > test. Many reviewers will miss the necessary addition also. A
> > developer that sees BufferGetPage(NO_SNAPSHOT_TEST) will at least
> > consider the idea that the flag might be right; if that developer
> > doesn't think about it, some reviewer may notice a new call with the
> > flag and consider the idea that the flag may be wrong.
>
> I'm unconvinced ...

Well, nobody opposed this when I proposed it originally. Robert just
stated that it caused a problem for him while backpatching but didn't
state opinion on reverting that change or not. Maybe we should call for
a vote here.

> > I understand the backpatching pain argument, but my opinion was the
> > contrary of yours even so.
>
> I merely point out that the problem came up less than ten days after
> that patch hit the tree. If that does not give you pause about the
> size of the back-patching problem we've just introduced, it should.

Undersootd. Kevin's idea of applying a no-op syntax change is on the
table. I don't like it either, but ISTM better than the other options
so far.

> TBH, there is nothing that I like about this feature: not the underlying
> concept, not the invasiveness of the implementation, nothing. I would
> dearly like to see it reverted altogether. I do not think it is worth
> the pain that the current implementation will impose, both on developers
> and on potential users. Surely there was another way to get a similar
> end result without mucking with things at the level of BufferGetPage.

Ah well, that's a completely different angle, and perhaps we should
explore this before doing anything in the back branches.

So it seems to me we have these options

1) revert the whole feature
2) revert the BufferGetPage syntax change
3) apply a no-op syntax change so that BufferGetPage looks the same on
backbranches as it does on master today, keeping API and ABI
compatibility with existing code
4) do nothing

Any others? (If we decide to call for a vote, I suggest we open a new
thread)

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services