From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [bugfix] commit timestamps ERROR on lookup of FrozenTransactionId |
Date: | 2016-11-24 13:30:57 |
Message-ID: | 20161124133057.2phiorqa4h7ikxje@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I considered the argument here for a bit and I think Craig is right --
FrozenXid eventually makes it to a tuple's xmin where it becomes a burden
to the caller, making our interface bug-prone -- sure you can
special-case it, but you don't until it first happens ... and it may not
until you're deep into production.
Even the code comment is confused: "error if the given Xid doesn't
normally commit". But surely FrozenXid *does* commit in the sense that
it appears in committed tuples' Xmin.
We already have a good mechanism for replying to the query with "this
value is too old for us to have its commit TS", which is a false return
value. We should use that.
I think not backpatching is worse, because then users have to be aware
that they need to handle the FrozenXid case specially, but only on
9.5/9.6 ... I think the reason it took this long to pop up is because
it has taken this long to get to replication systems on which this issue
matters.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Karlsson | 2016-11-24 13:49:34 | Re: [PATCH] Reload SSL certificates on SIGHUP |
Previous Message | Vladimir Svedov | 2016-11-24 13:12:23 | Re: postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer |