Re: Failure to COMMIT -- Timeout?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ben Lanson <lanson(at)bellatlantic(dot)net>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: Failure to COMMIT -- Timeout?
Date: 2000-08-26 16:42:06
Message-ID: 3236.967308126@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

Ben Lanson <lanson(at)bellatlantic(dot)net> writes:
> BEGIN WORK
> UPDATE table
> (network outage prevents a COMMIT)

> If I am reading correctly, all other transactions will hang waiting to see
> if Transaction 1 commits.

Not "all others", just those that actually need to care whether that
xact commits --- in practice, xacts that want to update the same tuples
it did.

> Will postgres eventually time out the transaction and catch this problem?

In the current implementation, loss of connection to the client will be
detected eventually because we run TCP connections with SO_KEEPALIVE
set. However KEEPALIVE is quite unaggressive; IIRC it takes about 2
hours before the kernel will lose all hope and declare the connection
lost.

> Testing in psql shows that the transaction is considered stopped (and
> rolled back) when the connection from psql is broken. Is a broken network
> link (in this case established in PHP) an equivalent situation?

Once the kernel tells the backend that the connection is gone, the
backend will rollback its transaction and exit. Your question therefore
reduces to a transport issue: when will the TCP stack report connection
loss/closure?

regards, tom lane

In response to

Browse pgsql-novice by date

  From Date Subject
Next Message Charles Curley 2000-08-26 16:42:11 Pg.pm oddity with apostrophes
Previous Message Fredrick Bartlett 2000-08-26 16:04:04 Simple question