On Mon, Jan 31, 2005 at 11:21:31AM -0500, Tom Lane wrote:
> I put it into 8.0, since that was just a quick copy, but I did not risk
> touching older versions. If you like you can make back-patches for 7.*.
It appears that 7.4 does not segfault. Maybe it does not free this
memory at all . But I'd
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
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
The following bug has been logged online:
Bug reference: 1461
Logged by: Prabin Gade
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: win2k and xp
Description:pg_restore fails to authenticate on win
Details:
Description: pg_restore is not
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
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
