Re: 7.4b4 undetected deadlock?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Creager <Robert_Creager(at)LogicalChaos(dot)org>
Cc: PGBugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: 7.4b4 undetected deadlock?
Date: 2003-10-06 03:58:08
Message-ID: 19301.1065412688@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Robert Creager <Robert_Creager(at)LogicalChaos(dot)org> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> confessed:
>> so indeed everyone is waiting for this process:
>>
>> postgres 29304 20209 0 17:37 pts/4 00:00:00 postgres: robert tassiv
>> 192.168.0.250 idle in transaction

> Hmmm... Not sure what that was doing. I'm only running one client.
> I had just aborted an import, and may have left the client suspended,
> rather than killing it.

Well, the problem may just reduce to that then.

>> ... I'd have to counsel rethinking that ---
>> even though there's no deadlock in this case, you are surely risking
>> deadlocks. Since REINDEX needs an exclusive lock, you should try to
>> minimize the number of other locks you have when you start the REINDEX.

> Well, I'm inserting single records into 4 tables, updating another
> using a temp table, importing ~3k records into two tables (each), then
> joining those last two tables (hence the REINDEX) to get matching
> entries, then selecting the results into the final table, all in one
> transaction.

This is perfectly okay as long as you're not expecting concurrent
transactions on those same tables. If you are then there may be a risk.
The temp table is obviously not a problem, but without detailed analysis
of access patterns to the permanent tables, it's hard to say whether
this is problematic or not.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2003-10-06 14:26:33 Re: 7.4beta4: make check broken?
Previous Message Robert Creager 2003-10-06 03:51:45 Re: 7.4b4 undetected deadlock?