On Tue, Apr 19, 2016 at 1:23 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Apr 19, 2016 at 3:14 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers