| From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
| Cc: | "Hannu Krosing" <hannu(at)skype(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Chad Wagner" <chad(dot)wagner(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "RPK" <rohitprakash123(at)indiatimes(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New feature request: FlashBack Query |
| Date: | 2007-02-19 14:38:46 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA57901CAF1B5@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > >First we must run the query in serializable mode and replace the
> > >snapshot with a synthetic one, which defines visibility at the
start
> > >of the desired transaction
> > >
> > >probably it is a good idea to take a lock on all tables involved to
> > >avoid a vacuum to be started on them when the query is running.
> > Would the xmin exported by that transaction prevent vacuum from
> > removing any tuples still needed for the flashback snapshot?
>
> Sure, and that makes the mentioned lock unnecessary.
Problem is, that that transaction sets a historic snapshot at a later
time, so it is not yet running when vacuum looks at "global xmin".
So something else needs to hold up global xmin (see prev post).
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Smet | 2007-02-19 14:39:02 | Re: WIP patch - INSERT-able log statements |
| Previous Message | Zeugswetter Andreas ADI SD | 2007-02-19 14:32:36 | Re: New feature request: FlashBack Query |