On Fri, 2008-11-28 at 12:45 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Fri, 2008-11-28 at 11:44 -0500, Tom Lane wrote:
> >> I hadn't been following the discussion closely enough to know what the
> >> problem is.
>
> > When we replay an AccessExclusiveLock on the standby we need to kick off
> > any current lock holders, after a configurable grace period. Current
> > lock holders may include some read-only backends that are
> > idle-in-transaction. SIGINT, which is what the current patch uses, is
> > not sufficient to dislodge the idle backends.
>
> Hm. People have complained of that fact from time to time in normal
> usage as well. Should we simply change SIGINT handling to allow it to
> cancel an idle transaction?
I'm looking at allowing SIGINT cancel an idle transaction.
Just edit StatementCancelHandler() in postgres.c, so that it doesn't
ignore a signal when DoingCommandRead at line 2577.
This patch does actually do what I wanted, but it has some unintended
consequences as well. These mask the fact that it does actually work,
which is confusing and has taken me a while to understand.
The backend accepts the signal and throws an error which then cancels
the transaction. The ERROR appears in the log immediately. However, a
psql client does not respond in any way when this occurs and only when a
new request is sent do we then generate the ERROR message on the client.
pg_stat_activity continues to show "<IDLE> in transaction", even after
global xmin is higher than the xid of the cancelled backend.
Then afterwards the client gets out of sync with the server and starts
putting replies on the wrong messages. Wow.
I'm not sure why recv() doesn't return with EINTR, but I guess I'm about
to find out. Hopefully?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support