Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group