Re: GetOldestXmin going backwards is dangerous after all
От | Andres Freund |
---|---|
Тема | Re: GetOldestXmin going backwards is dangerous after all |
Дата | |
Msg-id | 20130204170205.GC22226@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: GetOldestXmin going backwards is dangerous after all (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: GetOldestXmin going backwards is dangerous after all
|
Список | pgsql-hackers |
On 2013-02-04 11:52:05 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.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. Don't get me wrong, I hate that solution, but that specific issue seems relatively easily solvable by pre-creating the option intially in vacuum_rel() in a separate transaction before entering lazy_vacuum_rel(). I unfortunately don't yet see a robust way without storing the last used horizon :(. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: