Re: synchronized snapshots

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

In response to

Browse pgsql-hackers by date

  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