pgsql: Fix broken Assert() introduced by 8e9a16ab8f7f0e58

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема pgsql: Fix broken Assert() introduced by 8e9a16ab8f7f0e58
Дата
Msg-id E1X0bAb-00084p-2X@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
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.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/b2770576486265c2ce35b64e875028672a3bb7b5

Modified Files
--------------
src/backend/access/heap/heapam.c |    8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: pgsql: Have multixact be truncated by checkpoint, not vacuum
Следующее
От: Alvaro Herrera
Дата:
Сообщение: pgsql: Don't allow relminmxid to go backwards during VACUUM FULL