From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | 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-04-29 18:03:14 |
Message-ID: | 200904292003.19272.dfontaine@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Tuesday 28 April 2009 20:43:38 Robert Treat wrote:
> We had started down the path of making a function to read deleted tuples
> from a table for a DR scenario we were involved with once. The idea was
> that you could do something like select * from
> viewdeletedpages('tablename') t (table type), which would allow you to see
> the dead rows. It ended up unnessesary, so we never finished it, but I
> still think the utility of such a function would be high... for most
> people, if you told them that they could do create table as select * from
> viewdeletedttuples(...) t(...) after doing a mis-placed delete/update, at
> the cost of having to sift through extra data, they would make that trade
> in a heartbeat.
There has been another idea proposed to solve this problem:
http://archives.postgresql.org/pgsql-hackers/2009-02/msg00117.php
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).
Hannu said:
>Reintroducing keeping old tuples "forever" would also allow us to bring
>back time travel feature, that is
>
>SELECT .... AS OF 'yesterday afternoon'::timestamp;
It could be that there's a simpler way to implement the feature than provide a
ticker daemon (one more postmaster child), but the linked thread show some
other use cases of an integrated ticker. I know we use PGQ alone here to
obtain reliable batches as presented at Prato:
http://wiki.postgresql.org/wiki/Image:Prato_2008_pgq_batches.pdf
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-04-29 18:04:24 | Re: idea: global temp tables |
Previous Message | Tom Lane | 2009-04-29 17:52:10 | Re: idea: global temp tables |