From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allowing multiple concurrent base backups |
Date: | 2011-01-24 18:22:20 |
Message-ID: | AANLkTik35YADW29XxfzUyUA4v8pWZzzn0NVJNPyErVON@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 24, 2011 at 17:52, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 13.01.2011 23:32, Heikki Linnakangas wrote:
>>
>> Anyway, here's an updated patch with all the known issues fixed.
>
> Another updated patch. Fixed bitrot, and addressed the privilege issue
> Fujii-san raised here:
> http://archives.postgresql.org/message-id/4D380560.3040400@enterprisedb.com.
> I changed the privilege checks so that pg_start/stop_backup() functions
> require superuser privileges again, but not for a base backup via the
> replication protocol (replication privilege is needed to establish a
> replication connection to begin with).
I'm not entirely sure the replication privilege removal is correct.
Doing that, it's no longer possible to deploy a slave *without* using
pg_basebackup, unless you are superuser. Do we really want to put that
restriction back in?
(And if we do, the docs proably need an update...)
I can't see an explicit check for the user ttempting to do
pg_stop_backup() when there is a nonexclusive backup running? Maybe
I'm reading it wrong? The case being when a user has started a backup
with pg_basebackup but then connects and manually does a
pg_stop_backup. ISTM it drops us ina codepath that just doesn't do the
decrement, but also doesn't throw an error?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-01-24 19:21:35 | Re: READ ONLY fixes |
Previous Message | Tom Lane | 2011-01-24 18:00:22 | Re: Patch to add a primary key using an existing index |