Re: snapshot too old, configured by time

On Tue, Apr 19, 2016 at 1:23 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Apr 19, 2016 at 3:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Or in short: this is a whole lot further than I'm prepared to go to
>> satisfy one customer with a badly-designed application. And from what
>> I can tell from the Feb 2015 discussion, that's what this has been
>> written for.
>
> This holds true. I imagine that a lot of people at least on this list
> have already spent some time in tracking down long-running
> transactions in someone's application and actually tuned the
> application so as the bloat gets reduced and things perform better for
> other transactions taking a shorter time. Without the need of this
> feature.

So I don't want to be too vociferous in defending a feature that (a)
was written by a colleague and (b) obviously isn't perfect, but I will
point out that:

1. There was a surprising amount of positive reaction when Kevin first
proposed this. I expected a lot more people to say this kind of thing
at the beginning, when Kevin first brought this up, but in fact a
number of people wrote into say they'd really like to have this.
Those positive reaction shouldn't be forgotten just because those
people aren't wading into a discussion about the merits of adding
arguments to BufferGetPage.

2. Without this feature, you can kill sessions or transactions to
control bloat, but this feature is properly thought of as a way to
avoid bloat *without* killing sessions or transactions. You can let
the session live, without having it generate bloat, just so long as it
doesn't try to touch any data that has been recently modified. We
have no other feature in PostgreSQL that does something like that.

At the moment, what I see happening is that Tom, the one person who
has hated this feature since the beginning, still hates it, and we're
on the verge of asking Kevin to revert it because (1) Tom hates it and
(2) Kevin changed the BufferGetPage stuff in the way that Alvaro
requested. I think that's not quite fair. If we want to demand that
this feature be reverted because it causes a performance loss even
when turned off, I get that. If we think that it's badly implemented,
fine, I get that, too. But asking somebody to revert a patch because
the author adjusted things to match what the reviewer wanted is not
fair. The right thing to do about that is just change it back to the
way Kevin had it originally.

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