[HACKERS] Re: pg_hba.conf pre-parsing change
> Bruce Momjian - CVS <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: pg_hba.conf pre-parsing change
Bruce Momjian <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: pg_hba.conf pre-parsing change
> Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: pg_hba.conf pre-parsing change
On Tuesday 31 July 2001 19:20, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: pg_hba.conf pre-parsing change
Bruce Momjian <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: pg_hba.conf pre-parsing change
> Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
