From: | Rainer Frey <rainer(dot)frey(at)inxmail(dot)de> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #1459: Connection hangs when other connection is not |
Date: | 2005-02-04 10:54:56 |
Message-ID: | 42035480.2060707@inxmail.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-jdbc |
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
> don't want the structure of the table to be changed while you are reading it.
> Additionally, the locking protocol requires that all locks once obtained need
> to be held until the end of the transaction. Both of these issues together
> explain the problem you are seeing. There is nothing that can be done about
> it.
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?
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?
Rainer Frey
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel | 2005-02-04 12:05:01 | BUG #1460: unable dwonloads |
Previous Message | Peter Eisentraut | 2005-02-04 09:54:16 | Re: BUG #1459: Connection hangs when other connection is not committed |
From | Date | Subject | |
---|---|---|---|
Next Message | Stéphane RIFF | 2005-02-04 13:16:50 | Re: [SPAM] - Re: [SPAM] - Re: JDBC HighLoad - Found word(s) |
Previous Message | Markus Schaber | 2005-02-04 10:42:41 | Re: context classloader |