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.

Search Discussions

  • Bruno Wolff III at Oct 11, 2003 at 1:46 pm

    On Fri, Oct 10, 2003 at 23:07:59 -0400, Michael Brusser 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.
  • Tom Lane at Oct 14, 2003 at 4:01 pm

    Michael Brusser 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
  • Michael Brusser at Oct 14, 2003 at 4:09 pm
    Yes, we use NFS. Many of our customers use it as well.
    Mike.
    -----Original Message-----
    From: Tom Lane ... ...
    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
  • Tom Lane at Oct 14, 2003 at 5:15 pm

    Michael Brusser 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
  • Bruce Momjian at Oct 14, 2003 at 7:32 pm

    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
  • Larry Rosenman at Oct 14, 2003 at 7:37 pm
    --On Tuesday, October 14, 2003 15:31:42 -0400 Bruce Momjian
    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?

    http://www.postgresql.org/docs/faqs/FAQ.html


    --
    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
  • Bruce Momjian at Oct 14, 2003 at 7:39 pm
    Larry Rosenman wrote:
    -- Start of PGP signed section.

    --On Tuesday, October 14, 2003 15:31:42 -0400 Bruce Momjian
    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
  • Greg Stark at Oct 14, 2003 at 6:09 pm

    Michael Brusser writes:

    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?)
    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
  • Scott.marlowe at Oct 14, 2003 at 7:51 pm

    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 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?)
    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? :-)
  • Bruce Momjian at Oct 14, 2003 at 8:03 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedOct 11, '03 at 3:09a
activeOct 14, '03 at 8:03p
posts11
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase