On 9/07/2011 4:05 PM, Dmitriy Savricov wrote:
As i figured out, the reason is in "<IDLE> in transaction" process,
which hangs after table filling. From yestaday, I could not understand
what the process keeps the lock, and thinked that reason was inside
FTS - from system tables (pg_class) it was impossible to determine who
has locked the database. Today, I accidentally found the python
process in transaction.
Thank you very much for your help, and sorry for false report.
No worries. In future it'd be best to submit a test case that can be run
as an SQL file, along with things like the contents of pg_locks and
pg_stat_activity during the suspected fault, log excerpts, etc etc if
you find something that you think might be a bug. If in doubt, ask on
the pgsql-general mailing list, providing as much detail as you can.
Thanks for following up.
--
Craig Ringer
POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
