Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Markus Wanner wrote:
> On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland <joe(at)mcknight(dot)de>
> wrote:
>> 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

In response to

pgsql-hackers by date

Next:From: Leonardo FDate: 2010-02-10 18:30:35
Subject: Re: I: About "Our CLUSTER implementation is pessimal" patch
Previous:From: Joachim WielandDate: 2010-02-10 18:10:40
Subject: Re: Parameter name standby_mode

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group