pgsql/src backend/libpq/hba.c backend/postmast ...

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, Pennsylvania 19026

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, Pennsylvania 19026

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, Pennsylvania 19026