aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/cluster.c
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2014-06-27 14:43:39 -0400
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2014-06-27 14:43:39 -0400
commitb2770576486265c2ce35b64e875028672a3bb7b5 (patch)
treef51e2bc1148073679fe5f8a18d21bc466d105b74 /src/backend/commands/cluster.c
parent1147035203a47a424b2399fc74829d097b7061e4 (diff)
downloadpostgresql-b2770576486265c2ce35b64e875028672a3bb7b5.tar.gz
postgresql-b2770576486265c2ce35b64e875028672a3bb7b5.zip
Fix broken Assert() introduced by 8e9a16ab8f7f0e58
Don't assert MultiXactIdIsRunning if the multi came from a tuple that had been share-locked and later copied over to the new cluster by pg_upgrade. Doing that causes an error to be raised unnecessarily: MultiXactIdIsRunning is not open to the possibility that its argument came from a pg_upgraded tuple, and all its other callers are already checking; but such multis cannot, obviously, have transactions still running, so the assert is pointless. Noticed while investigating the bogus pg_multixact/offsets/0000 file left over by pg_upgrade, as reported by Andres Freund in http://www.postgresql.org/message-id/20140530121631.GE25431@alap3.anarazel.de Backpatch to 9.3, as the commit that introduced the buglet.
Diffstat (limited to 'src/backend/commands/cluster.c')
0 files changed, 0 insertions, 0 deletions