Обсуждение: pg_hba.conf pre-parsing change
Bruce Momjian - CVS <momjian@hub.org> writes:
> Load pg_hba.conf and pg_ident.conf on startup and SIGHUP into List of
> Lists, and use that for user validation.
While this should be a nice speedup, it bothers me somewhat that the old
behavior of reacting immediately to pg_hba.conf and pg_ident.conf
updates has been changed. (And you didn't update the documentation to
say so --- tsk tsk.)
Would it make sense to do fstat calls on these files and reload whenever
we observe that the file modification time has changed? That'd be an
additional kernel call per connection attempt, so I'm not at all sure
I want to do it ... but it ought to be debated. Comments anyone?
regards, tom lane
> Bruce Momjian - CVS <momjian@hub.org> writes: > > Load pg_hba.conf and pg_ident.conf on startup and SIGHUP into List of > > Lists, and use that for user validation. > > While this should be a nice speedup, it bothers me somewhat that the old > behavior of reacting immediately to pg_hba.conf and pg_ident.conf > updates has been changed. (And you didn't update the documentation to > say so --- tsk tsk.) Oh, I didn't realize we documented that. > Would it make sense to do fstat calls on these files and reload whenever > we observe that the file modification time has changed? That'd be an > additional kernel call per connection attempt, so I'm not at all sure > I want to do it ... but it ought to be debated. Comments anyone? We could, but we don't with postgresql.conf so it made sense to keep the behavior the same for the two files. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Would it make sense to do fstat calls on these files and reload whenever
>> we observe that the file modification time has changed? That'd be an
>> additional kernel call per connection attempt, so I'm not at all sure
>> I want to do it ... but it ought to be debated. Comments anyone?
> We could, but we don't with postgresql.conf so it made sense to keep the
> behavior the same for the two files.
I'm inclined to agree --- for one thing, this allows one to edit the
files in place without worrying that the postmaster will pick up a
partially-edited file. But I wanted to throw the issue out to pghackers
to see if anyone would be really unhappy about having to SIGHUP the
postmaster after changing the authorization conf files.
In any case, if we don't change the code, the change in behavior from
prior releases needs to be documented...
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Would it make sense to do fstat calls on these files and reload whenever > >> we observe that the file modification time has changed? That'd be an > >> additional kernel call per connection attempt, so I'm not at all sure > >> I want to do it ... but it ought to be debated. Comments anyone? > > > We could, but we don't with postgresql.conf so it made sense to keep the > > behavior the same for the two files. > > I'm inclined to agree --- for one thing, this allows one to edit the > files in place without worrying that the postmaster will pick up a > partially-edited file. But I wanted to throw the issue out to pghackers > to see if anyone would be really unhappy about having to SIGHUP the > postmaster after changing the authorization conf files. OK. > In any case, if we don't change the code, the change in behavior from > prior releases needs to be documented... You mean in the SGML or in the release highlight text? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tuesday 31 July 2001 19:20, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > We could, but we don't with postgresql.conf so it made sense to keep the > > behavior the same for the two files. > I'm inclined to agree --- for one thing, this allows one to edit the > files in place without worrying that the postmaster will pick up a > partially-edited file. But I wanted to throw the issue out to pghackers > to see if anyone would be really unhappy about having to SIGHUP the > postmaster after changing the authorization conf files. Hmmm... I much prefer having to SIGHUP postmaster -- that is semistandard daemon behavior, no? If enough people want the other behavior, add a postgresql.conf setting to activate 'modification notification' for config files. If nothing else, an 'accidental' pg_hba.conf corruption, deletion, or malicious change has to have a 'confirmation' step before a running postmaster sees the changes. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> In any case, if we don't change the code, the change in behavior from
>> prior releases needs to be documented...
> You mean in the SGML or in the release highlight text?
Both. client_auth.sgml specifically states that editing the file is
sufficient to make changes, and I think that it'd better be mentioned
in the release notes too.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> In any case, if we don't change the code, the change in behavior from > >> prior releases needs to be documented... > > > You mean in the SGML or in the release highlight text? > > Both. client_auth.sgml specifically states that editing the file is > sufficient to make changes, and I think that it'd better be mentioned > in the release notes too. Got it, and pg_hba.conf talked about it too. Also, I added a mention of SIGHUP to pg_ident.conf.sample. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026