Yes, that would be the preferred way to do it, if the problem would
occur more often then it does, I've seen it happen twice in three
months time.
I'd like to peek into the transaction that _has_ stalled and see what
It has done so far. I.e. the backend that is idle in transaction.
If that is not possible, I'll just have to turn on the information
as you mentioned below, and wait a month or two for it to occur again.
Regards,
Niclas Gustafsson
-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Tom Lane
Sent: den 15 maj 2002 17:37
To: Niclas Gustafsson
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] PG_XLOG grows and grows
"Niclas Gustafsson" <niclas.gustafsson@codesense.com> writes:
> Yes, I know that, I would like to know what commands the client
> has issued sofar in the transaction as this would help us to
> track down if there is some problems in the client, and which
> client that is stalling ( As we have a bunch of different clients
> Working towards the database).
Turn on debug_print_query, log_pid, log_timestamp, and perhaps
log_connections in postgresql.conf. The postmaster log will then
provide a pretty effective trace of what's going on.
BTW, in 7.2 you need to SIGHUP the postmaster after changing
postgresql.conf. I forget whether 7.1 expected that or not.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html