Skip site navigation (1) Skip section navigation (2)

Re: FSM search modes

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, decibel <decibel(at)decibel(dot)org>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FSM search modes
Date: 2009-10-01 22:02:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> That doesn't preclude also providing some more-invasive tools
> that people can use when they do get into that situation; 

About this side of things, what about having any query which asks for
system columns (any of them) take a specific (new) exclusive row level
lock. The tuple moving utility would try to take the same lock before
moving any tuple, thus allowing those who need it to continue relying on
the ctid / xmin queries trick.

If that idea has any chance to fly, the tuple moving facility could even
be integrated into autovacuum for actively self-healing PostgreSQL.


Hoping this won't be some more hand waving.

In response to

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-10-01 22:07:41
Subject: Re: FSM search modes
Previous:From: Kevin GrittnerDate: 2009-10-01 21:23:52
Subject: Re: FSM search modes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group