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

Re: WIP: remove use of flat auth file for client authentication

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: remove use of flat auth file for client authentication
Date: 2009-08-29 15:19:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> Specifically, should I remove the parts of the HS patch that refresh
> those files?

Yes.  This was the last part that I was afraid might have insurmountable
problems.  There are some bits yet to do but they're in the nature of
crank-turning, I believe.  I think it's a good bet the flat files will
be gone before the next commitfest starts.

BTW, one of the to-do bits is to find another way to initialize the
XID wrap limit at database start.  Right now that's set up as a
side-effect of scanning pg_database to create the flat DB file.
The idea I had about it was to store the current wrap limit in
checkpoint WAL records and use the most recent checkpoint's value
as the initial limit.  Can you tell me what you're doing about the
wrap limit in HS and whether that solution would be an issue for you?

>> I suspect that
>> this means some things are actively broken during InitPostgres's
>> initial
>> transaction --- for example, if it happens to try to take a lock that
>> completes a deadlock cycle, the deadlock won't be detected because the
>> lock timeout SIGALRM interrupt will never occur. Another example is
>> that SI inval messaging isn't working during InitPostgres either.

> Are we doing anything in the initial transaction that *could* deadlock,

Sure --- we have to take locks to examine system catalogs.  Pretty weak
locks mind you, but there's certainly a potential there if someone else
is doing something like a VACUUM FULL on the catalogs.

> or cause an SI inval message?

I don't think InitPostgres could *cause* a SI inval, I was more worried
about whether it would fail to respond to them.  The worst case result
is probably a failure of the InitPostgres transaction to notice someone
else's relfilenode reassignment on a system catalog, which would end
up with a "failed to open file" kind of error.  Again, the probabilities
aren't very high, but they appear nonzero.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Grzegorz JaskiewiczDate: 2009-08-29 16:13:50
Subject: Re: clang's static checker report.
Previous:From: Tom LaneDate: 2009-08-29 15:06:44
Subject: Re: WIP: remove use of flat auth file for client authentication

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