From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Markus Wanner <markus(at)bluegap(dot)ch> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: synchronized snapshots |
Date: | 2010-02-10 18:15:32 |
Message-ID: | 4B72F7C4.2000401@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Markus Wanner wrote:
> On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland <joe(at)mcknight(dot)de>
> wrote:
>> http://www.postgresql.org/docs/8.4/static/backup-dump.html already
>> states about pg_dump: "In particular, it must have read access to all
>> tables that you want to back up, so in practice you almost always have
>> to run it as a database superuser." so I think there is not a big loss
>> here...
>
> Hm.. I doubt somewhat that's common practice. After all, read access to
> all tables is still a *lot* less than superuser privileges. But yeah,
> the documentation currently states that.
I think running as database owner gets you pretty far as far as pg_dump
goes. It would be good to lift the limitation that you have to be superuser.
>> But you are right: The proposed feature is a pragmatic and quick
>> solution for pg_dump and similar but we might want to have a more
>> general snapshot cloning procedure instead. Not having a delay for
>> other activities at all and not requiring superuser privileges would
>> be a big advantage over what I have proposed.
>
> Agreed.
Yeah, a big advantage of the proposed approach is that it's pretty
simple to implement as an external module, allowing you to write scripts
using it for older versions too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Leonardo F | 2010-02-10 18:30:35 | Re: I: About "Our CLUSTER implementation is pessimal" patch |
Previous Message | Joachim Wieland | 2010-02-10 18:10:40 | Re: Parameter name standby_mode |