Re: BUG #3504: Some listening sessions never return from writing, problems ensue

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Peter Koczan" <pjkoczan(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3504: Some listening sessions never return from writing, problems ensue
Date: 2007-08-07 01:23:18
Message-ID: 6814.1186449798@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Peter Koczan" <pjkoczan(at)gmail(dot)com> writes:
> Here's my theory (and feel free to tell me that I'm full of it)...somehow, a
> lot of notifies happened at once, or in a very short period of time, to the
> point where the app was still processing notifies when the timer clicked off
> another second. The connection (or app, or perl module) never marked those
> notifies as being processed, or never updated its timestamp of when it
> finished, so when the next notify came around, it tried to reprocess the old
> data (or data since the last time it finished), and yet again couldn't
> finish. Lather, rinse, repeat. In sum, it might be that trying to call
> pg_notifies while processing notifies tickles a race condition and tricks
> the connection into thinking its in a bad state.

Hmm. Is the app trying to do this processing inside an interrupt
service routine (a/k/a signal handler)? If so, and if the ISR can
interrupt itself, then you've got a problem because you'll be doing
reentrant calls of libpq, which it doesn't support. You can only make
that work if the handler blocks further occurrences of its signal until
it finishes.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2007-08-07 01:30:53 Re: RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues
Previous Message Gregory Stark 2007-08-07 01:13:18 Re: RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues