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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Lane Sent: den 15 maj 2002 17:37 To: Niclas Gustafsson Cc: [EMAIL PROTECTED] Subject: Re: [ADMIN] PG_XLOG grows and grows "Niclas Gustafsson" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
