Обсуждение: best method of reloading pg_hba.conf
Is the best method of reloading pg_hba.conf to SIGHUP the master process? David
David Ford wrote: > > Is the best method of reloading pg_hba.conf to SIGHUP the master process? You dont need to reload it. It all happens automatically - just edit it and it will be consulted at next connect. -------------- Hannu
> Is the best method of reloading pg_hba.conf to SIGHUP the master process? In 7.2, yes, pg_ctl restart or SIGHUP. On 7.1.X pg_hba.conf is reread on every connection request. -- 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 wrote: > > > Is the best method of reloading pg_hba.conf to SIGHUP the master process? > > In 7.2, yes, pg_ctl restart or SIGHUP. On 7.1.X pg_hba.conf is reread > on every connection request. Why was it changed ? -------- Hannu
> Bruce Momjian wrote: > > > > > Is the best method of reloading pg_hba.conf to SIGHUP the master process? > > > > In 7.2, yes, pg_ctl restart or SIGHUP. On 7.1.X pg_hba.conf is reread > > on every connection request. > > Why was it changed ? Performance. Peter E found that considerable startup time was being wasted reading the file. -- 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
> > Performance. Peter E found that considerable startup time was being > > wasted reading the file. > > But can't we read it only when needed ? > > Just stat'ing it should be much cheaper than reading it each time. We thought about that but it seems we could be reading partial writes to the file. This way the administrator controls when the changes become effective. -- 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
Hannu Krosing <hannu@tm.ee> writes:
> Bruce Momjian wrote:
>> In 7.2, yes, pg_ctl restart or SIGHUP. On 7.1.X pg_hba.conf is reread
>> on every connection request.
> Why was it changed ?
To cut a few more percent off connection startup time. (According to
Bruce's measurements, reading pg_hba.conf was a measurable fraction
of startup.)
regards, tom lane
Bruce Momjian wrote: > > > Bruce Momjian wrote: > > > > > > > Is the best method of reloading pg_hba.conf to SIGHUP the master process? > > > > > > In 7.2, yes, pg_ctl restart or SIGHUP. On 7.1.X pg_hba.conf is reread > > > on every connection request. > > > > Why was it changed ? > > Performance. Peter E found that considerable startup time was being > wasted reading the file. But can't we read it only when needed ? Just stat'ing it should be much cheaper than reading it each time. ---------------- Hannu
Hannu Krosing <hannu@tm.ee> writes: > Bruce Momjian wrote: > > > > > Is the best method of reloading pg_hba.conf to SIGHUP the master process? > > > > In 7.2, yes, pg_ctl restart or SIGHUP. On 7.1.X pg_hba.conf is reread > > on every connection request. > > Why was it changed ? I think to give the admin control over when it gets reread. Say it's being automatically generated by a cron job for some reason, and a connection request comes in while it's being written--the backend would get a corrupted version of the file. (Or if a text editor's in the midst of saving it). -Doug -- Let us cross over the river, and rest under the shade of the trees. --T. J. Jackson, 1863
Bruce Momjian wrote: > > > > Performance. Peter E found that considerable startup time was being > > > wasted reading the file. > > > > But can't we read it only when needed ? > > > > Just stat'ing it should be much cheaper than reading it each time. > > We thought about that but it seems we could be reading partial writes to > the file. This way the administrator controls when the changes become > effective. > Hannu, It is not only much safer (you get a 2nd chance to check what you've done) but is also consistent with the behavior of other Unix daemons. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9
>> But can't we read it only when needed ?
>> Just stat'ing it should be much cheaper than reading it each time.
We'd already created a precedent for read-on-HUP for postgresql.conf,
and no one seemed to be complaining about that. So although this change
will doubtless annoy some existing users, I don't see a big problem
with it. I'm happy to avoid the stat() call --- every kernel call we
can remove from the startup sequence is another small win.
regards, tom lane
Fernando Nasser wrote: > > Bruce Momjian wrote: > > > > > > Performance. Peter E found that considerable startup time was being > > > > wasted reading the file. > > > > > > But can't we read it only when needed ? > > > > > > Just stat'ing it should be much cheaper than reading it each time. > > > > We thought about that but it seems we could be reading partial writes to > > the file. This way the administrator controls when the changes become > > effective. You could do the writing in a proper way - write to temp file and then rename. > Hannu, > > It is not only much safer (you get a 2nd chance to check what you've > done) > but is also consistent with the behavior of other Unix daemons. Well, that much I already knew ;) Except for sendmail where I must run newaliases, that is. Sending a HUP is actually ok with me, it just came as a surprise. ---------------------- Hannu