diff options
author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2014-06-27 14:43:38 -0400 |
---|---|---|
committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2014-06-27 14:43:38 -0400 |
commit | 5c538442a0a73b9d4f3fa11ecac6d5b93a982aca (patch) | |
tree | ae08db24d3f8452ff68d8f82a28bcaabb0361b55 /src/backend/commands/cluster.c | |
parent | a2db7b7d0135c4068ebc3806931e60d5edd8f5cf (diff) | |
download | postgresql-5c538442a0a73b9d4f3fa11ecac6d5b93a982aca.tar.gz postgresql-5c538442a0a73b9d4f3fa11ecac6d5b93a982aca.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