Peter Eisentraut schrieb:
Am Donnerstag, 3. Februar 2005 16:11 schrieb Rainer Frey:
A select should not lock a table even when it is not committed.
The SELECT obtains a read (shared) lock on the table, but the ALTER TABLE
requires a write (exclusive) lock. This is certainly necessary because you
On Sat, 5 Feb 2005, Oliver Jowett wrote:
> - Statement.setQueryTimeout(). This is *not* implemented by the current
> driver (it is a no-op), but shouldn't be too hard to implement as
> mapping to statement_timeout if you feel inclined to do some driver hacking.
>
I think it will be complicat
Peter Eisentraut wrote:
Am Freitag, 4. Februar 2005 11:54 schrieb Rainer Frey:
Is there any possibility to set a timeout for the lock, after which the
ALTER TABLE statement fails, instead of remaining in wait status (when
calling with JDBC?
Yes, there is a statement_timeout parameter or something l
Am Freitag, 4. Februar 2005 11:54 schrieb Rainer Frey:
> Thanks for the explanation, though I don't really get the necessity of a
> commit for a read-only statement. Can't a SELECT release its lock after
> it received the response?
If that is the end of the transaction, then you might as well comm
Am Donnerstag, 3. Februar 2005 16:11 schrieb Rainer Frey:
> A select should not lock a table even when it is not committed.
The SELECT obtains a read (shared) lock on the table, but the ALTER TABLE
requires a write (exclusive) lock. This is certainly necessary because you
don't want the structu
The following bug has been logged online:
Bug reference: 1459
Logged by: Rainer Frey
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Redhat Linux 9, Kernel 2.4.20-8, AMD Sempron 2500+, 1GB
RAM
Description:Connection hangs when other connec
