pg_ctl reload - is it safe?
Env: Postgres 7.3.4 on Unix
I have a script to create a new database user and update pg_hba.conf.
I was wondering whether I need to restart server, or simply run pg_ctl
reload.
The question is what happens to all active clients when all backends get the
signal.
I ran such client process which was very busy querying and updating
database.
At the same time I kept executing "pg_ctl reload". Soon after client
reported
database error.
Here's the excerpt from the database log:
... ...
2003-10-10 22:33:12 LOG: Received SIGHUP, reloading configuration files
<25 successful SIGHUPs, about 2 seconds apart from each other>
... ...
2003-10-10 22:37:05 ERROR: cannot read block 0 of s_noteimportlinks:
Interrupted system call
...
From the client log I see that problem occured while trying to SELECT
nextval from
sequence s_noteimportlinks
We are going to pass this script to the customers and we have to know what
to recommend:
reload or shut down/restart. I hope they won't do reload 25 times... but
they may have
25 or more active client processes at any time.
Thanks in advance,
Mike.
On Fri, Oct 10, 2003 at 23:07:59 -0400,
Michael Brusser <michael@synchronicity.com> wrote:
Env: Postgres 7.3.4 on Unix
I have a script to create a new database user and update pg_hba.conf.
Do you run multiple databases with not all users having access to all
databases? If any valid use will have access to a particular database,
then you can use 'any' for the username in the pg_hba.conf file and
not have to worry about updating it.
Michael Brusser <michael@synchronicity.com> writes:
2003-10-10 22:37:05 ERROR: cannot read block 0 of s_noteimportlinks:
Interrupted system call
Hmm. I found this hard to believe at first, but indeed my local man
pages for read() and write() say they can return EINTR if interrupted
by a signal. This may depend on the filesystem in use (are you using
NFS?)
We had probably better fix fd.c to retry on EINTR.
regards, tom lane
Yes, we use NFS. Many of our customers use it as well.
Mike.
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
... ...
Show quoted text
Michael Brusser <michael@synchronicity.com> writes:
2003-10-10 22:37:05 ERROR: cannot read block 0 of s_noteimportlinks:
Interrupted system callHmm. I found this hard to believe at first, but indeed my local man
pages for read() and write() say they can return EINTR if interrupted
by a signal. This may depend on the filesystem in use (are you using
NFS?)We had probably better fix fd.c to retry on EINTR.
regards, tom lane
Michael Brusser <michael@synchronicity.com> writes:
Yes, we use NFS. Many of our customers use it as well.
You are of course aware that this is not real safe...
regards, tom lane
Michael Brusser <michael@synchronicity.com> writes:
Michael Brusser <michael@synchronicity.com> writes:
2003-10-10 22:37:05 ERROR: cannot read block 0 of s_noteimportlinks:
Interrupted system callHmm. I found this hard to believe at first, but indeed my local man
pages for read() and write() say they can return EINTR if interrupted
by a signal. This may depend on the filesystem in use (are you using
NFS?)
The traditional unix semantics are the read/write my return EINTR if
interrupted -- but that that would only EVER happen for network connections.
The traditional semantics are that it would NEVER happen on disk i/o. BSD
kernels at least, and probably all unix kernels, do an uninterruptible sleep
on disk accesses, hence the dreaded "D" in ps listings.
Yes, we use NFS. Many of our customers use it as well.
Normally NFS guarantees the traditional unix semantics.
Unless you're using either "soft" or "intr" options.
If you are, well, stop.
If you use "intr" then this type of thing can happen. Lots of programs assume
the unix semantics for disk accesses. You can get all kinds of bugs when
they're violated.
If you use "soft" then the consequences can be much much worse. If your
fileserver were to reboot you could silently lose disk writes corrupting your
database.
--
greg
Tom Lane wrote:
Michael Brusser <michael@synchronicity.com> writes:
Yes, we use NFS. Many of our customers use it as well.
You are of course aware that this is not real safe...
Maybe we should throw a "stop using NFS" if we get an EINTR from
read()/write(), or explain what NFS options they should avoid.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
--On Tuesday, October 14, 2003 15:31:42 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Tom Lane wrote:
Michael Brusser <michael@synchronicity.com> writes:
Yes, we use NFS. Many of our customers use it as well.
You are of course aware that this is not real safe...
Maybe we should throw a "stop using NFS" if we get an EINTR from
read()/write(), or explain what NFS options they should avoid.
Err, some of us use NetApp filers as NFS servers for our PG data, and I
believe that that negates at least some of the risk. I don't want to see
us (PG) not support something just because it *MAY* be unsafe.
LER
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
-- Start of PGP signed section.
--On Tuesday, October 14, 2003 15:31:42 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:Tom Lane wrote:
Michael Brusser <michael@synchronicity.com> writes:
Yes, we use NFS. Many of our customers use it as well.
You are of course aware that this is not real safe...
Maybe we should throw a "stop using NFS" if we get an EINTR from
read()/write(), or explain what NFS options they should avoid.Err, some of us use NetApp filers as NFS servers for our PG data, and I
believe that that negates at least some of the risk. I don't want to see
us (PG) not support something just because it *MAY* be unsafe.
True. I was going by the guy who said that only unsafe NFS flags will
cause this behavior --- and of course, 1/2 of it was a joke, and the
other 1/2 was just an idea thrown out.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On 14 Oct 2003, Greg Stark wrote:
Michael Brusser <michael@synchronicity.com> writes:
Michael Brusser <michael@synchronicity.com> writes:
2003-10-10 22:37:05 ERROR: cannot read block 0 of s_noteimportlinks:
Interrupted system callHmm. I found this hard to believe at first, but indeed my local man
pages for read() and write() say they can return EINTR if interrupted
by a signal. This may depend on the filesystem in use (are you using
NFS?)The traditional unix semantics are the read/write my return EINTR if
interrupted -- but that that would only EVER happen for network connections.
The traditional semantics are that it would NEVER happen on disk i/o. BSD
kernels at least, and probably all unix kernels, do an uninterruptible sleep
on disk accesses, hence the dreaded "D" in ps listings.Yes, we use NFS. Many of our customers use it as well.
Normally NFS guarantees the traditional unix semantics.
Unless you're using either "soft" or "intr" options.If you are, well, stop.
If you use "intr" then this type of thing can happen. Lots of programs assume
the unix semantics for disk accesses. You can get all kinds of bugs when
they're violated.If you use "soft" then the consequences can be much much worse. If your
fileserver were to reboot you could silently lose disk writes corrupting your
database.
What if the WAL was local on disk, and the data was going to nfs storage,
would that be safe, or saferer? :-)
wscott.marlowe wrote:
If you use "intr" then this type of thing can happen. Lots of programs assume
the unix semantics for disk accesses. You can get all kinds of bugs when
they're violated.If you use "soft" then the consequences can be much much worse. If your
fileserver were to reboot you could silently lose disk writes corrupting your
database.What if the WAL was local on disk, and the data was going to nfs storage,
would that be safe, or saferer? :-)
Not sure --- we do a sync() on the entire machine before recycling the WAL logs.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073