Well I think Greg hit on the problem. The remote server that issues
The sql had an outdated ODBC driver that was not issuing code to properly
Close cursors. So cursors remained open and apparently locks were never
Released. A newer driver version is currently being tested, cursors are
Being closed and when we push this out, everything will once again
Be right with the world.
Thanks to all for the help.
Mark Steben│Database Administrator│
@utoRevenue-R- "Join the Revenue-tion"
95 Ashley Ave. West Springfield, MA., 01089
413-243-4800 x1512 (Phone) │ 413-732-1824 (Fax)
@utoRevenue is a registered trademark and a division of Dominion Enterprises
-----Original Message-----
From: gsstark@gmail.com [mailto:gsstark@gmail.com] On Behalf Of Greg Stark
Sent: Tuesday, July 07, 2009 8:13 PM
To: Tom Lane
Cc: Scott Marlowe; Mark Steben; pgsql-admin@postgresql.org
Subject: Re: Concurrency question
On Tue, Jul 7, 2009 at 11:11 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Scott Marlowe <scott.marlowe@gmail.com> writes:
>> On Tue, Jul 7, 2009 at 3:40 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> The described situation is impossible: AccessSharelock doesn't block
>>> ShareUpdateExclusiveLock. There must have been some other lock or
>>> attempted lock involved (perhaps at a page or tuple level rather than
>>> the whole-relation level). But we can't tell much from this much
detail.
>
>> So something like alter table or something?
>
> Well, one possible way to block vacuum is that the idle transaction is
Another way to block vacuum is to be in the middle of scanning the
table and have a pin on a page that vacuum wants to clean. For
example, say that transaction has a cursor open for a sequential scan
of that table and has stopped reading from the cursor, just sitting
"idle" but with the cursor still stuck on that page. In that case
vacuum would wait on that page waiting for the query to make progress
and move onto a new page so it can clean it.
--
greg
http://mit.edu/~gsstark/resume.pdf