| From: | Greg Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Anton Egorov <anton(dot)egoroff(at)gmail(dot)com> |
| Subject: | Re: Restore deleted rows |
| Date: | 2009-05-01 10:01:34 |
| Message-ID: | 4136ffa0905010301k760d487cm90451c8048d9f301@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 29, 2009 at 7:03 PM, Dimitri Fontaine
<dfontaine(at)hi-media(dot)com> wrote:
> The idea is to have VACUUM not discard the no more visible tuples but store
> them on a specific fork (which you'll want to have on a WORM (cheap)
> tablespace, separate issue).
> Then you want to be able to associate the tuple xid info with a timestamptz
> clock, which could be done thanks to txid and txid_snapshot by means of a
> ticker daemon. PGQ from Skytools has such a daemon, a C version is being
> prepared for the 3.0 release (alpha1 released).
I think you would use the xid "epoch" which the txid data type stores.
You would need a mapping somewhere to translate timestamps to
snapshots and the epoch to use for that snapshot.
There's a tricky problem of how to find the old tuple values in the
new fork. You can't just store them in the same ctid slot because you
could have many with the same ctid. I suspect you might be able to get
away with making the new fork a btree with the ctid as the key.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2009-05-01 10:04:56 | Re: Creating a tablespace directory in recovery |
| Previous Message | Dave Page | 2009-05-01 07:42:00 | Re: windows shared memory error |