| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Michael Paesold <mpaesold(at)gmx(dot)at> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCHES] TRUNCATE, VACUUM, ANALYZE privileges |
| Date: | 2006-01-05 14:41:47 |
| Message-ID: | 20060105144146.GY6026@ns.snowman.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
* Michael Paesold (mpaesold(at)gmx(dot)at) wrote:
> Stephen Frost wrote:
> >I'm not a particularly big fan of this though because, while I'd
> >like to be able to give TRUNCATE permissions I'm not a big fan of SET
> >RELIABILITY because it would affect PITR backups.
>
> As far as I have understood the discussion... with WAL archiving turned on,
> the whole RELIABILITY changes would be no-ops, no?
> Just as the CTAS optimization etc. only skip WAL if WAL archiving is turned
> off.
Oh, I thought the reliability bit would bypass WAL even with archiving
turned on (which could be fine in some cases, just not all cases :). Of
course, all of this is still up in the air somewhat. :) If it's a noop
in that case then the 'bypass' bit might be alright to have control SET
RELIABILITY. I'd rather have the flexibility to have them be seperately
grantable though.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2006-01-05 15:02:11 | Re: Improving N-Distinct estimation by ANALYZE |
| Previous Message | Michael Paesold | 2006-01-05 14:37:32 | Re: [PATCHES] TRUNCATE, VACUUM, ANALYZE privileges |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2006-01-05 15:33:05 | Re: [BUGS] Solaris cc compiler on amd: PostgreSQL does not have native |
| Previous Message | Michael Paesold | 2006-01-05 14:37:32 | Re: [PATCHES] TRUNCATE, VACUUM, ANALYZE privileges |