On 21 September 2016 at 22:16, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Sep 21, 2016 at 3:40 AM, Craig Ringer <cr...@2ndquadrant.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.
Fair point. > [snip] > > 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. Yeah. 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 pain option. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
