[BUGS] BUG #3474: Failed to create batch file

2007-07-20 Thread Vishal Gungah
The following bug has been logged online: Bug reference: 3474 Logged by: Vishal Gungah Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4-1 Operating system: Windows Vista Description:Failed to create batch file Details: I am getting this error message when

Re: [BUGS] chr() function leads to OOM / killed connection with 8.1, 8.2

2007-07-20 Thread Wiktor Wodecki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane wrote: > Wiktor Wodecki <[EMAIL PROTECTED]> writes: >> I found something that I believe to be a bug in postgresql handling of >> the chr function. This function takes an ascii code and returns the >> character. > > What database encoding are

[BUGS] BUG #3475: SQL: 7/2 = 3

2007-07-20 Thread vasile
The following bug has been logged online: Bug reference: 3475 Logged by: vasile Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Centos 4.4 Description:SQL: 7/2 = 3 Details: When you divide 2 int the result is also int, is truncated: On

Re: [BUGS] BUG #3475: SQL: 7/2 = 3

2007-07-20 Thread Magnus Hagander
On Fri, Jul 20, 2007 at 07:34:59AM +, vasile wrote: > > The following bug has been logged online: > > Bug reference: 3475 > Logged by: vasile > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.4 > Operating system: Centos 4.4 > Description:SQL: 7/2 = 3

[BUGS] WAL replay of truncate fails if the table was dropped

2007-07-20 Thread Heikki Linnakangas
mdtruncate throws an error if the relation file doesn't exist. However, that's not an error condition if the relation was dropped later. Non-existent file should be treated the same as an already truncated file; we now end up with an unrecoverable database. This bug seems to be present from 8.0 on

Re: [BUGS] WAL replay of truncate fails if the table was dropped

2007-07-20 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > mdtruncate throws an error if the relation file doesn't exist. Interesting corner case. The proposed fix seems not very consistent with the way we handle comparable cases elsewhere, though. In general, md.c will cut some slack when InRecovery if a

Re: [BUGS] WAL replay of truncate fails if the table was dropped

2007-07-20 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Interestingly, this bug isn't triggered unless there's an already empty > or uninitialized page at the end of table. If vacuum removes the last > tuple from the page, that will be WAL-logged and replay of that calls > smgrcreate. Yeah, I tried other

Re: [BUGS] WAL replay of truncate fails if the table was dropped

2007-07-20 Thread Heikki Linnakangas
Tom Lane wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: >> mdtruncate throws an error if the relation file doesn't exist. > > Interesting corner case. The proposed fix seems not very consistent > with the way we handle comparable cases elsewhere, though. In general, > md.c will cut some

Re: [BUGS] WAL replay of truncate fails if the table was dropped

2007-07-20 Thread Simon Riggs
On Fri, 2007-07-20 at 11:38 -0400, Tom Lane wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > > Interestingly, this bug isn't triggered unless there's an already empty > > or uninitialized page at the end of table. If vacuum removes the last > > tuple from the page, that will be WAL-logged

Re: [BUGS] WAL replay of truncate fails if the table was dropped

2007-07-20 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> writes: > If I understand this: the primary would be initialised yet the standby > would remain uninitialised? I don't think that matters because the > actual the data contents are still zero. >From a logical perspective the page is "empty" either way. The only b