The following bug has been logged online:
Bug reference: 1239
Logged by: Martin Pollard
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: Win32
Description:Stale postmaster.pid prevents server start
Details:
A stale or invalid post
On Mon, Sep 06, 2004 at 04:41:32PM +1000, Koju Iijima wrote:
Hi,
> template1=# BEGIN;
> BEGIN
> template1=# CREATE TABLE FOO ( a int unique);
> NOTICE: CREATE TABLE / UNIQUE will create implicit index "foo_a_key" for table "foo"
> CREATE TABLE
> template1=# INSERT INTO FOO VALUES ( 0 );
> INSERT
The following bug has been logged online:
Bug reference: 1240
Logged by: Roland Walter
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.3
Operating system: SuSE Linux 9.0, Windows CYGWIN, J2SDK 1.4.2_x
Description:memory leak in JDBC driver build 215
Deta
328 [main] DEBUG com.mosaicag.rwa.dbutil.standard.DefaultCsvExport -
executing SQL-Stmt: SELECT * FROM transaction WHERE transaction_date >=
to_timestamp('01.01.2002', 'DD.MM.') AND transaction_date <
to_timestamp('01.01.2003', 'DD.MM.')
java.lang.OutOfMemoryError
Exception in thread "m
Dear bug-hunters,
With a nearly current cvs head version I have the following:
psql> SELECT VERSION();
...
PostgreSQL 8.0.0beta2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
3.3.4 (Debian 1:3.3.4-6sarge1)
psql> CREATE TABLE foo(id SERIAL PRIMARY KEY, data TEXT);
psql> CREATE FUNCTION add_data(
> Operating system: Win32
> Description:Stale postmaster.pid prevents server start
I believe this is fixed as of CVS tip. But thanks for the report!
regards, tom lane
---(end of broadcast)---
TIP 5: Have you check
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The problem is that there's a pin on an index page when the smgr tries
> to drop its buffers. This patch corrects this problem, by having
> resowner cleanup before smgr.
Good diagnosis, not very good fix. You didn't do anything about
adjusting the com
Fabien COELHO <[EMAIL PROTECTED]> writes:
> psql> CREATE FUNCTION add_data(TEXT) RETURNS boolean LANGUAGE SQL AS
>'BEGIN; INSERT INTO foo(data) VALUES($1); COMMIT; SELECT TRUE;';
> psql> SELECT add_data('hello');
> FATAL: EndTransactionBlock: unexpected state BEGIN
> CONTEXT: SQL functio
The following bug has been logged online:
Bug reference: 1241
Logged by: Xiaoyu Wang
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.3
Operating system: Mandrake Linux 9.2 3.3.1-2mdk
Description:returns different result for the same result with
differnt
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> Description:returns different result for the same result with
> differnt plans.
> database: TPC-H with scale factor=1.0
> query: 13.sql (TPC-H)
This is not *nearly* enough information to let someone else reproduce
the problem. (Heck,
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> [ fix broken CHECK_FOR_INTERRUPTS macro ]
Applied. I see how this might change detection of statement_timeout,
but I do not actually see what it's got to do with deadlock detection.
In the deadlock situation the process that needs to wake up is goin
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Given that pg_dump does put out GRANT/REVOKE operations on the sequence,
>> it's certainly aware that the sequence exists. I suspect this is just a
>> fixable bug (ie, suppression of output of the sequence CREATE command is
>> being done at th
12 matches
Mail list logo
