From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tim Dudgeon <tdudgeon.ml@gmail.com>
cc: pgsql-sql@postgresql.org
Subject: Re: commit not completing - how to investigate?
In-reply-to: <e00cc4cd-05d1-7fd1-a7a0-e7fea6e81919@gmail.com>
References: <5e59f5e0-7168-fb80-d038-7fe9adad4aa9@gmail.com>
 <29711.1500646472@sss.pgh.pa.us>
 <e00cc4cd-05d1-7fd1-a7a0-e7fea6e81919@gmail.com>
Comments: In-reply-to Tim Dudgeon <tdudgeon.ml@gmail.com>
	message dated "Fri, 21 Jul 2017 16:18:49 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17754.1500657810.1@sss.pgh.pa.us>
Date: Fri, 21 Jul 2017 13:23:30 -0400
Message-ID: <17755.1500657810@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

Tim Dudgeon <tdudgeon.ml@gmail.com> writes:
> Yes, the state is "idle", and the command is "COMMIT".
> But if the COMMIT has completed then the process should finish and the 
> row not be present?

Well, that's up to the connected client whether it's going to terminate
the session or not.

> So is what you are suggesting that in my case I'm using a connection 
> pool, and the COMMIT has completed successfully, the connection released 
> back to the pool, but not yet closed, so that process is still running?

That's sort of the point of a connection pooler, to re-use database
sessions rather than establishing new ones all the time.  But the
database doesn't know that a pooler is in use; it just sees a client
connection that's not doing anything right now.

			regards, tom lane


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql