The following bug has been logged online:
Bug reference: 5129
Logged by: Thach Anh Tran
Email address: myqua...@gmail.com
PostgreSQL version: 8.3.8
Operating system: Linux
Description:LIMIT not correct.
Details:
the LIMIT clause is not reply correct number of rows a
Hi, Kevin.
Thank you for your reply.
This is a problem of connection pooling, not of transaction.
public void testConnection() {
Connection con = dataSource.getConnection(); // get a connection
from pool (If DB server restarted, invalid connection will be
returned)
boolean valid = true;
The following bug has been logged online:
Bug reference: 5128
Logged by:
Email address: landrevi...@deadtreepages.com
PostgreSQL version: 8.4
Operating system: FreeBSD
Description:Returning nested composite types in plpython
Details:
I have nested custom types and
I've seen it happen on a wide range of win2k3 servers. From a fresh
image with nothing but VMWare tools under Add/Remove Programs, to a
heavily used shared dev server with MSVC, Cygwin, and tons of other
stuff. Some of our beta testers have also seen the issue. In fact I
can't really think of an
takiguchi wrote:
> public void testConnection() {
>Connection con = dataSource.getConnection(); // get a connection
> from pool (If DB server restarted, invalid connection will be
> returned)
>boolean valid = true;
>try {
>// execute some DMLs...
>con.commit();
>}
takiguchi wrote:
> This is a problem of connection pooling, not of transaction.
>
> public void testConnection() {
>Connection con = dataSource.getConnection(); // get a connection
> from pool (If DB server restarted, invalid connection will be
> returned)
>boolean valid = true;
>tr
Dave Page writes:
> On Tue, Oct 20, 2009 at 3:48 PM, Tom Lane wrote:
>> Do we have any idea why?
> Honestly? No. I have a vague hand-wavy idea about there being
> something preventing us properly modifying the token of an existing
> process in some configurations, but nothing even remotely jello
On Tue, Oct 20, 2009 at 3:48 PM, Tom Lane wrote:
> Dave Page writes:
>> The patch doesn't change what the code aims to do, only the way it
>> does it. The existing code does this:
>> ...
>> The net result /should/ be the same, but the second method is
>> apparently a little more robust.
>
> Do we
Dave Page writes:
> The patch doesn't change what the code aims to do, only the way it
> does it. The existing code does this:
> ...
> The net result /should/ be the same, but the second method is
> apparently a little more robust.
Do we have any idea why? I am always distrustful of random chang
wrote:
> If PostgreSQL server is restarted, old Connection pooled in
> Application server's ConnectionPool cannot connect to DB.
> That's OK.
> But, I can call rollback() on old Connection and it throws no
> exception.
Hmmm What problem are you having? The transaction would have
been r
The following bug has been logged online:
Bug reference: 5127
Logged by:
Email address: tak...@gmail.com
PostgreSQL version: 8.3.7
Operating system: CentOS 5.1
Description:AbstractJdbc2Connection#doRollback should throws
Exception if connection is closed
Details:
I
On Mon, Oct 19, 2009 at 7:03 PM, Andrew Dunstan wrote:
>
> However, I'd like a bit more comment added on just why doing this is safe.
The patch doesn't change what the code aims to do, only the way it
does it. The existing code does this:
- Creates a restricted security token
- Creates a new (su
Steffen,
the File you are searching for is probably the MSI-Installer at
http://www.postgresql.org/ftp/binary/v8.3.8/win32/
more specifically:
http://wwwmaster.postgresql.org/download/mirrors-ftp/binary/v8.3.8/win32/postgresql-8.3.8-1.zip
best wishes
Harald
On Mon, Oct 19, 2009 at 11:04 PM,
13 matches
Mail list logo
