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

Re: Cause of "can't wait without a PROC structure"

From: Scott Shattuck <ss(at)technicalpursuit(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Cause of "can't wait without a PROC structure"
Date: 2002-09-25 15:57:25
Message-ID: 1032969446.3351.47.camel@idearat (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, 2002-09-25 at 09:52, Tom Lane wrote:
> I've identified the reason for the occasional "can't wait without a PROC
> structure" failures we've seen reported.  I had been thinking that this
> must occur during backend startup, before MyProc is initialized ...
> but I was mistaken.  Actually, it happens during backend shutdown,
> and the reason is that ProcKill (which releases the PGPROC structure
> and resets MyProc to NULL) is called before ShutdownBufferPoolAccess.
> But the latter tries to acquire the bufmgr LWLock.  If it has to wait,
> kaboom.

Great news that you've identified the problem. We continue to see this
every few days and it's the only thing that takes our servers down over
weeks of pounding.

> The ordering of these shutdown hooks is the reverse of the ordering
> of the startup initialization of the modules.  It looks like we'll
> need to rejigger the startup ordering ... and it also looks like that's
> going to be a rather ticklish issue.  (See comments in BaseInit and
> InitPostgres.)  Any thoughts on how to do it?

Sorry I can't add any insight at this level...but I can say that it
would be significant to my customer(s) and my ability to recommend PG to
future "ex-Oracle users" ;) to see a fix make it into the 7.3 final.


Scott Shattuck
Technical Pursuit Inc.

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2002-09-25 16:20:36
Subject: Re: Cause of "can't wait without a PROC structure"
Previous:From: Tom LaneDate: 2002-09-25 15:52:57
Subject: Cause of "can't wait without a PROC structure"

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