| From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
|---|---|
| To: | <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | <kleptog(at)svana(dot)org>, <simon(at)2ndquadrant(dot)com>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <gsstark(at)mit(dot)edu>, <pg(at)rbt(dot)ca>, <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 16:14:37 |
| Message-ID: | 51082.68.143.134.146.1135872877.squirrel@www.dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian said:
> DROP would drop the table on a restart
> after a non-clean shutdown. It would do _no_ logging on the table and
> allow concurrent access, plus index access. DELETE is the same as
> DROP, but it just truncates the table (perhaps TRUNCATE is a better
> word).
>
> EXCLUSIVE would allow only a single session to modify the table, and
> would do all changes by appending to the table, similar to COPY LOCK.
> EXCLUSIVE would also not allow indexes because those can not be
> isolated like appending to the heap. EXCLUSIVE would write all dirty
> shared buffers for the table and fsync them before committing. SHARE
> is the functionality we have now, with full logging.
I an horribly scared that this will be used as a "performance boost" for
normal use. I would at least like to see some restrictions that make it
harder to mis-use. Perhaps restrict to superuser?
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-12-29 16:24:28 | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |
| Previous Message | Tom Lane | 2005-12-29 16:13:56 | Re: localization problem (and solution) |