Re: snapshot too old, configured by time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Steve Singer <steve(at)ssinger(dot)info>, Kevin Grittner <kgrittn(at)ymail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: snapshot too old, configured by time
Date: 2016-04-18 18:14:50
Message-ID: 1447.1461003290@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
> On Mon, Apr 18, 2016 at 8:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Surely there was another way to get a similar end result without
>> mucking with things at the level of BufferGetPage.

> To get the feature that some customers have been demanding, a check
> has to be made somewhere near where any page is read in a scan.

I'm not really convinced that we need to define it exactly like that,
though. In particular, why not just kill transactions as soon as their
oldest snapshot is too old? That might not work exactly like this does,
but it would have some pretty substantial benefits --- for one, that the
timeout could be configured locally per session rather than having to be
PGC_POSTMASTER. And it would likely be far easier to limit the
performance side-effects.

I complained about this back when the feature was first discussed,
and you insisted that that answer was no good, and I figured I'd hold
my nose and look the other way as long as the final patch wasn't too
invasive. Well, now we've seen the end result, and it's very invasive
and has got performance issues as well. It's time to reconsider.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-04-18 18:37:21 Postgres 9.6 scariest patch tournament
Previous Message Pavel Stehule 2016-04-18 16:35:10 Re: Relax requirement for INTO with SELECT in pl/pgsql