From: | g(dot)hintermayer(at)inode(dot)at (Gerhard Hintermayer) |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: database shutdown with persistent client connections |
Date: | 2002-08-01 07:32:59 |
Message-ID: | bd4db85f.0207312332.616c80e7@posting.google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) wrote in message news:<27612(dot)1028124591(at)sss(dot)pgh(dot)pa(dot)us>...
> g(dot)hintermayer(at)inode(dot)at (Gerhard Hintermayer) writes:
> > Is there a notification sen't out in either smart or fast shutdown
> > mode ?
>
> Sure: the backend sends an error message
> FATAL: This connection has been terminated by the administrator.
> before closing the connection.
>
> The problem you're describing is that the client-side code isn't looking
> for any communication from the server except when it's involved in a SQL
> command. I'm not sure what you can do about that except restructure the
> client.
>
What I tried is (for libpgtcl):
Everytime if I do PQconsumeInput (when the backend channel gets
readable) I check for the return value. (0 == error) and generate a
notification manually, e.g. connection_closed) and pass it to the TCL
event queue. The only bad thing I had to do is to comment out removing
all pending events in PgStopNotifyEventSource. Could there be any
sideeffects ? Maybe I should do that only if the connection was
unexpectedly closed (i.e. called from within PgNotifyTransferEvents) ?
Gerhard
From | Date | Subject | |
---|---|---|---|
Next Message | frbn | 2002-08-01 07:57:53 | Re: problem insert time into column timestamp |
Previous Message | Xavier Bugaud | 2002-08-01 07:31:17 | FW: very slow updates |