[BUGS] Server crash while trying to read expression using pg_get_expr()

2010-06-03 Thread Rushabh Lathia
Hi, Server crash while trying to read expression(wrong) using pg_get_expr(). postgres=# SELECT pg_get_expr('{FUNCEXPR', 1255); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lo

Re: [BUGS] Server crash while trying to read expression using pg_get_expr()

2010-06-03 Thread Heikki Linnakangas
On 03/06/10 10:21, Rushabh Lathia wrote: Server crash while trying to read expression(wrong) using pg_get_expr(). postgres=# SELECT pg_get_expr('{FUNCEXPR', 1255); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the reques

[BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading

2010-06-03 Thread Hartmut Goebel
The following bug has been logged online: Bug reference: 5488 Logged by: Hartmut Goebel Email address: h.goe...@goebel-consult.de PostgreSQL version: 8.3 / 8.4 Operating system: all Description:pg_dump does not quote column names -> pg_restore may fail when upgrading

Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading

2010-06-03 Thread Kevin Grittner
"Hartmut Goebel" wrote: > Description:pg_dump does not quote column names -> > pg_restore may fail when upgrading > If a 8.3 table contains a column named "window", the dump can not > be restored into a 8.4 database. Reasons: a) "window" is a new > keyword in 8.4 b)

Re: [BUGS] BUG #5364: citext behavior when type not in public schema

2010-06-03 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > I have documented this citext limitation with the attached, applied > > patch. > > Are you planning to insert similar verbiage into every other contrib > module's docs? Uh, do they all have this odd behavior? Most people assume they would get an error

Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading

2010-06-03 Thread Tom Lane
"Hartmut Goebel" writes: > If a 8.3 table contains a column named "window", the dump can not be > restored into a 8.4 database. Reasons: a) "window" is a new keyword in 8.4 > b) pg_dump does not quote column names. This is one of the cases where it's helpful to use the newer version's pg_dump. >

Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading

2010-06-03 Thread Kevin Grittner
>Hartmut Goebel wrote: > I dumped with the executable form 8.3. That's not expected to work for an upgrade to 8.4. > 8.4 did not allow accessing the 8.3 database What do you mean? (What did you try and what happened?) -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.o

Re: [BUGS] BUG #5469: regexp_matches() has poor behaviour and more poor documentation

2010-06-03 Thread Bruce Momjian
Bruce Momjian wrote: > Robert Haas wrote: > > On Mon, May 31, 2010 at 10:11 AM, Bruce Momjian wrote: > > > Robert Haas wrote: > > >> On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian wrote: > > >> > I have updated the patch, attached, to clarify that this returns text > > >> > arrays, and that you c

Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading

2010-06-03 Thread Hartmut Goebel
Am 03.06.2010 15:43, schrieb Kevin Grittner: > Note that the documentation recommends always running pg_dump using > the executable from the target version, not the source version. Are > you using the pg_dump executable from 8.4? I dumped with the executable form 8.3. 8.4 did not allow accessin

Re: [BUGS] BUG #5364: citext behavior when type not in public schema

2010-06-03 Thread Markus Wichitill
On 03.06.2010 05:05, Bruce Momjian wrote: > The schema containing the citext operators must be > in the current search_path (typically public); It's been a while, but the way I read my own example is that the schema containing the citext operators being in the current search_path isn't enough. "pu

Re: [BUGS] BUG #5364: citext behavior when type not in public schema

2010-06-03 Thread Bruce Momjian
Markus Wichitill wrote: > On 03.06.2010 05:05, Bruce Momjian wrote: > > The schema containing the citext operators must be > > in the current search_path (typically public); > > It's been a while, but the way I read my own example is that the schema > containing the citext operators being in the c

[BUGS] superuser unable to modify settings of a system table

2010-06-03 Thread Gurjeet Singh
On PG 8.4.4 I am unable to set per-table autovacuum setting for the pg_listener table. Being a superuser, I'd expect Postgres to allow me to do that. postgres=# select version(); version --- P

Re: [BUGS] superuser unable to modify settings of a system table

2010-06-03 Thread Tom Lane
Gurjeet Singh writes: > On PG 8.4.4 I am unable to set per-table autovacuum setting for the > pg_listener table. Being a superuser, I'd expect Postgres to allow me to do > that. See allow_system_table_mods. Even superusers should think twice before fooling with system catalogs...

Re: [BUGS] superuser unable to modify settings of a system table

2010-06-03 Thread Gurjeet Singh
On Thu, Jun 3, 2010 at 1:02 PM, Tom Lane wrote: > Gurjeet Singh writes: > > On PG 8.4.4 I am unable to set per-table autovacuum setting for the > > pg_listener table. Being a superuser, I'd expect Postgres to allow me to > do > > that. > > See allow_system_table_mods. Even superusers should thi

Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading

2010-06-03 Thread Hartmut Goebel
Am 03.06.2010 16:16, schrieb Kevin Grittner: >> 8.4 did not allow accessing the 8.3 database > > What do you mean? (What did you try and what happened?) If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed starting (something like "Database version mismatch"). So I downgraded to

Re: [BUGS] superuser unable to modify settings of a system table

2010-06-03 Thread Tom Lane
Gurjeet Singh writes: > allow_system_table_mods needs a restart :( .Yet another parameter I wish was > changeable on the fly. I'm not sure there's any compelling reason why it couldn't be SUSET. Maybe a TODO ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgs

Re: [BUGS] BUG #5443: Undetected deadlock situation

2010-06-03 Thread Tom Lane
Claudio Freire writes: > What I did do is analyze server load during the events, and as I > suspected, disk activity during the "deadlocks" seems to suggest a > vacuuming taking place. Although there was no autovacuum entry in > pg_stat_activity every time I checked, disk activity precisely matche

Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading

2010-06-03 Thread Kevin Grittner
Hartmut Goebel wrote: > If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed > starting (something like "Database version mismatch"). You need to be running the old server using 8.3 software and while using pg_dump from 8.4 software. Does your packager provide some way to instal

Re: [BUGS] BUG #5443: Undetected deadlock situation

2010-06-03 Thread Claudio Freire
On Fri, 2010-04-30 at 11:50 -0400, Tom Lane wrote: > "Kevin Grittner" writes: > > Eliminating null columns and mangling column headers for length, I > > get this: > > > locktype| tranid | virtualx | pid | mode | gr > > transactionid | 39773877 | 63/15761 | 11157 | ShareLock

Re: [BUGS] BUG #5443: Undetected deadlock situation

2010-06-03 Thread Claudio Freire
On Thu, 2010-06-03 at 13:42 -0400, Tom Lane wrote: > Claudio Freire writes: > > What I did do is analyze server load during the events, and as I > > suspected, disk activity during the "deadlocks" seems to suggest a > > vacuuming taking place. Although there was no autovacuum entry in > > pg_stat

Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading

2010-06-03 Thread Tom Lane
"Kevin Grittner" writes: > Hartmut Goebel wrote: >> If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed >> starting (something like "Database version mismatch"). > You need to be running the old server using 8.3 software and while > using pg_dump from 8.4 software. Does your pac

Re: [BUGS] BUG #5443: Undetected deadlock situation

2010-06-03 Thread Kevin Grittner
Claudio Freire wrote: > On Thu, 2010-06-03 at 13:42 -0400, Tom Lane wrote: >> Claudio Freire writes: >> > What I did do is analyze server load during the events, and as >> > I suspected, disk activity during the "deadlocks" seems to >> > suggest a vacuuming taking place. Although there was no >>

Re: [BUGS] BUG #5443: Undetected deadlock situation

2010-06-03 Thread Claudio Freire
On Thu, 2010-06-03 at 13:11 -0500, Kevin Grittner wrote: > Based on what I've heard so far, I wouldn't entirely > > rule out some sort of bloat being a factor, either. > > -Kevin Index/table bloat is the first thing I suspected, and both table and indices look all the right size. Knowing how

[BUGS] BUG #5489: SELECT ... RETURNING INTO ... in ecpg

2010-06-03 Thread Alexander
The following bug has been logged online: Bug reference: 5489 Logged by: Alexander Email address: goa...@gmail.com PostgreSQL version: 8.3.11 Operating system: CentOS 5.4 Description:SELECT ... RETURNING INTO ... in ecpg Details: I've been using PostgreSQL since ver

Re: [BUGS] Bad optimizer data for xml (WAS: xml data type implications of no =)

2010-06-03 Thread Mark Kirkwood
On 27/05/10 13:37, Mark Kirkwood wrote: On 25/05/10 16:43, Mark Kirkwood wrote: Today I ran into some interesting consequences of the xml data type being without an "=" operator. One I thought I'd post here because it has a *possible* planner impact. I'm not sure it is actually a bug as such,

Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading

2010-06-03 Thread Joshua Tolley
On Thu, Jun 03, 2010 at 06:04:16PM +0200, Hartmut Goebel wrote: > If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed > starting (something like "Database version mismatch"). So I downgraded > to 8.3, pg_dump'ed there, upgraded and pg_restore'd. pg_dump will complain if its version

Re: [BUGS] Support on Postgres Database Corruption

2010-06-03 Thread Robert Haas
On Wed, Jun 2, 2010 at 9:38 AM, botak wrote: > Dear sirs, > > Referring to the matter above. > > For your information, we are a government agency and been hosting a > management system since 2006. The system was developed with Postgres Sql and > PHP in Centos Platform. Recently, after a power fail