pgsql: Exclude VACUUMs from RunningXactData
Exclude VACUUMs from RunningXactData
GetRunningTransactionData() should ignore VACUUM procs because in some
cases they are assigned xids. This could lead to holding back xmin via
the route of passing the xid to standby and then having that hold back
xmin on master via feedback.
Backpatch to 9.1 needed, but will only do so on supported versions.
Backpatch once proven on the buildfarm.
Reported-by: Greg Stark
Author: Simon Riggs
Reviewed-by: Amit Kapila
Discussion: /messages/by-id/CANP8+jJBYt=4PpTfiPb0UrH1_iPhzsxKH5Op_Wec634F0ohnAw@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/32ac7a118fc17f5baac1b370f50d759c30bee00a
Modified Files
--------------
src/backend/storage/ipc/procarray.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Simon Riggs <simon@2ndQuadrant.com> writes:
Exclude VACUUMs from RunningXactData
GetRunningTransactionData() should ignore VACUUM procs because in some
cases they are assigned xids.
Uh, what? Lazy vacuum shouldn't acquire an xid. If it does, that
would suggest it's running code that it's unsafe for
GetRunningTransactionData to ignore.
regards, tom lane
On 2018-06-07 16:24:30 -0400, Tom Lane wrote:
Simon Riggs <simon@2ndQuadrant.com> writes:
Exclude VACUUMs from RunningXactData
GetRunningTransactionData() should ignore VACUUM procs because in some
cases they are assigned xids.Uh, what? Lazy vacuum shouldn't acquire an xid. If it does, that
would suggest it's running code that it's unsafe for
GetRunningTransactionData to ignore.
Well, we currently do acquire an xid at the end when truncating (see
[1]: http://archives.postgresql.org/message-id/20180607211918.h2cdja26ypriw2sm%40alap3.anarazel.de
these xids. Let's continue the discussion over there?
Greetings,
Andres Freund
[1]: http://archives.postgresql.org/message-id/20180607211918.h2cdja26ypriw2sm%40alap3.anarazel.de