| 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: | m2ljjulqmj.fsf@hi-media.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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.
Regards,
--
dim
Hoping this won't be some more hand waving.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2009-10-01 22:07:41 | Re: FSM search modes |
| Previous Message | Kevin Grittner | 2009-10-01 21:23:52 | Re: FSM search modes |