Re: [GENERAL] pg_upgrade ?deficiency - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [GENERAL] pg_upgrade ?deficiency
Date
Msg-id 1385167133.97610.YahooMailNeo@web162902.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: [GENERAL] pg_upgrade ?deficiency  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: [GENERAL] pg_upgrade ?deficiency  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote:
>> Oddly, it didn't complain about creating users within a read-only
>> transaction.  That seems like a potential bug.
>
> There's lots of things that escape XactReadOnly. I've thought (and I
> think suggested) before that we should put in another layer of defense
> by also putting a check in AssignTransactionId(). Imo the compatibility
> woes (like not being able to run SELECT txid_current();) are well worth
> the nearly ironclad guarantee that we're not writing.

I agree that something like that is would be a good idea; however,
I'm sure you would agree that would not be material for a
back-patch to a stable branch.

Another thing I've mused about is having some way to lock a
database to read-only, such that only the owner or a superuser
could change that.  Another setting which I know some people would
like to lock is transaction isolation level.  I haven't really
thought of a good UI for that sort of thing, though.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: [GENERAL] pg_upgrade ?deficiency
Next
From: Gurjeet Singh
Date:
Subject: Re: Shave a few instructions from child-process startup sequence