| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Rod Taylor <pg(at)rbt(dot)ca> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |
| Date: | 2005-12-29 15:10:40 |
| Message-ID: | 1135869040.2964.824.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2005-12-29 at 09:35 -0500, Rod Taylor wrote:
> > So, my thinking would be to separate things into two:
> > a) Add a TODO item "shared temp tables" that caters for (1) and (4)
> >
> > ALTER TABLE name RELIABILITY
> > {DELETE ROWS AT RECOVERY | FULL RECOVERY}
> > (syntax TBD)
>
> DELETE ROWS AT RECOVERY would need to be careful or disallowed when
> referenced via a foreign key to ensure the database is not restored in
> an inconsistent state.
I think we'd need to apply the same rule as we do for temp tables: they
cannot be referenced by a permanent table.
There are possibly some other restrictions also. Anyone?
Best Regards, Simon Riggs
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-12-29 15:49:23 | Re: Removing SORTFUNC_LT/REVLT |
| Previous Message | Rod Taylor | 2005-12-29 14:35:27 | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |