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: 4B72F7C4.2000401@enterprisedb.com (view raw or flat)
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

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-2014 The PostgreSQL Global Development Group