Re: pgsql: Fix a couple of bugs in MultiXactId freezing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Date: 2013-12-03 18:11:13
Message-ID: 24535.1386094273@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> Any idea how to cheat our way out of that one given the current way
> heap_freeze_tuple() works (running on both primary and standby)? My only
> idea was to MultiXactIdWait() if !InRecovery but that's extremly grotty.
> We can't even realistically create a new multixact with fewer members
> with the current format of xl_heap_freeze.

Maybe we should just bite the bullet and change the WAL format for
heap_freeze (inventing an all-new record type, not repurposing the old
one, and allowing WAL replay to continue to accept the old one). The
implication for users would be that they'd have to update slave servers
before the master when installing the update; which is unpleasant, but
better than living with a known data corruption case.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Magnus Hagander 2013-12-03 18:14:33 Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Previous Message Andres Freund 2013-12-03 17:48:16 Re: pgsql: Fix a couple of bugs in MultiXactId freezing

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2013-12-03 18:14:33 Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Previous Message Andres Freund 2013-12-03 17:48:16 Re: pgsql: Fix a couple of bugs in MultiXactId freezing