I did that, and then realized it was time to call it an afternoon ...
Your comments have been very helpful.
Thanks
Tom
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/TRUNCATE-HANGS-tp3292333p3294007.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.co
tmoore wrote:
> I'm a little tired. I just indicated autocommit false, that was
> incorrect. Autocommit is true.
I would double-check that. As I said, what you showed us indicates
that something logging in through TCP on localhost is using
transactions, and not committing them when needed.
I'm a little tired. I just indicated autocommit false, that was incorrect.
Autocommit is true.
Sorry.
Thanks again for the comment.s
Tom
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/TRUNCATE-HANGS-tp3292333p3292468.html
Sent from the PostgreSQL - bugs mailing list ar
Thanks for the link.
Yes, the test is java with autocommit false, on the localhost is involved.
To clarify the no blocking comment, let me describe the test again.
Three threads of executions, java writer, java reader, and psql via
cron for truncation. As an experiment, the java reader was disabl
tmoore wrote:
> The test is not doing any transaction based work, the write
> functions just do sql insert, no begin commit blocks at the
> application level.
Well something is starting transactions; otherwise you wouldn't have
a transaction sitting "idle in transaction". Are you perhaps
acce
Can I ask you to elaborate on one of your comments before I move to the
general thread ?
You mention committing the 'idle thread'. The test is not doing
any transaction based work, the write functions just do sql insert, no begin
commit blocks at the application level.
Any tips on interpreting
tmoore wrote:
> Running this test, a deadlock can be created without fail.
You haven't shown any evidence of a deadlock -- just blocking.
That's not at all the same thing.
> postgres 16990 26837 44 11:20 ? 00:28:51 postgres: postgres uisdb
> 127.0.0.1(34405) idle in transaction
> postgres
Hello,
I'm running into a problem with truncate causing my test application to
fail. I've noticed some similar
problems posted but noting that quite lines up with what I'm seeing.
I have a partitioned table. Storing m records per partition, where I use a
sequence table
to keep track of the over
