Subject: Re: [PATCHES] Infrastructure changes for recovery (v8)
From: Simon Riggs <simon@2ndQuadrant.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
In-Reply-To: <49217D3F.9050603@enterprisedb.com>
References: <1222815151.4445.1397.camel@ebony.2ndQuadrant>
	<48EC9CC5.6060803@enterprisedb.com>
	<1223468660.4747.294.camel@ebony.2ndQuadrant>
	<1223472898.4747.310.camel@ebony.2ndQuadrant>
	<49217D3F.9050603@enterprisedb.com>
Content-Type: text/plain
Date: Mon, 17 Nov 2008 15:33:13 +0000
Message-Id: <1226935993.3790.12.camel@ebony.2ndQuadrant>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Mon, 2008-11-17 at 16:18 +0200, Heikki Linnakangas wrote:

> > +
> > +                       /*
> > +                        * Load the flat authorization file into
> postmaster's ca
> > +                        * startup process won't have recomputed
> this from the d
> > +                        * yet, so it may change following recovery.
> > +                        */
> > +                       load_role();
> 
> Is there a race condition here too, if the startup process is writing 
> the auth file at the same time? I guess we'd have the same problem
> with flat files in general, so maybe there's something else that
> mitigates the problem?

The flat file is not race condition proof. When the file is read it is
just a guide and the real data is re-accessed from catalog. So the
problem you see does exist, but is handled elsewhere - not in this
patch.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support