|From:||Craig Ringer <craig(at)2ndquadrant(dot)com>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Petr Jelinek <petr(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>|
|Subject:||Re: [PATCH] Transaction traceability - txid_status(bigint)|
|Views:||Raw Message | Whole Thread | Download mbox|
On 21 September 2016 at 22:16, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Sep 21, 2016 at 3:40 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>> The only non-horrible one of those is IMO to just let the caller see
>> an error if they lose the race. It's a function that's intended for
>> use when you're dealing with indeterminate transaction state after a
>> server or application error anyway, so it's part of an error path
>> already. So I say we just document the behaviour.
> I am not keen on that idea. The errors we're likely to be exposing
> are going to look like low-level internal failures, which might scare
> some DBA. Even if they don't, I think it's playing with fire. The
> system is designed on the assumption that nobody will try to look up
> an XID that's too old, and if we start to violate that assumption I
> think we're undermining the design integrity of the system in a way
> we'll likely come to regret. To put that more plainly, when the code
> is written with the assumption that X will never happen, it's usually
> a bad idea to casually add code that does X.
> It might not be too hard to add a second copy of oldestXid in shared
> memory that is updated before truncation rather than afterward... but
> yeah, like you, I'm not finding this nearly as straightforward as
> might have been hoped.
I suspect that'll be the way to go, to add another copy that's updated
before clog truncation. It just seems ... unclean. Like it shouldn't
be necessary, something else isn't right. But it's probably the lowest
I'm going to take a step back on this and see if I can spot an alternative.
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
|Next Message||Craig Ringer||2016-09-27 01:34:47||Re: patch: function xmltable|
|Previous Message||Michael Paquier||2016-09-27 00:55:40||Re: [COMMITTERS] pgsql: pg_ctl: Detect current standby state from pg_control|