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
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? |