Re: GetOldestXmin going backwards is dangerous after all

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GetOldestXmin going backwards is dangerous after all
Date: 2013-02-04 16:52:05
Message-ID: 566.1359996725@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> I absolutely hate to suggest it, but what about storing the last
> vacuum's xmin horizon in the main table's pg_class.options in the back
> branches?

Not workable. This would require a non-in-place update of the table's
pg_class row (at least in cases where the option wasn't stored already).
Which would require VACUUM to have an XID, which would make a whole lot
of assumptions fall over.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2013-02-04 16:59:27 Re: sql_drop Event Trigger
Previous Message Andres Freund 2013-02-04 16:43:41 Re: GetOldestXmin going backwards is dangerous after all