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: | Raw Message | Whole Thread | 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 |