Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args

2009-11-04 Thread Fujii Masao
Hi, Sorry for this late reply. On Wed, Aug 19, 2009 at 6:45 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Is pg_standby killed correctly when postmaster dies? No. In my test (v8.3.7 on Win), an immediate shutdown was able to kill postmaster, but not pg_standby and the

Re: [HACKERS] Skip WAL in ALTER TABLE

2009-11-04 Thread Heikki Linnakangas
Simon Riggs wrote: On Thu, 2009-10-15 at 13:18 +0900, Itagaki Takahiro wrote: Simon Riggs si...@2ndquadrant.com wrote: Is it possible to use WAL-skipping and BulkInsertState in ATRewriteTable() ? If ok, I'll submit a patch for the next commitfest. Yes Patch attached. This patch skip WAL

Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args

2009-11-04 Thread Heikki Linnakangas
Fujii Masao wrote: On Wed, Aug 19, 2009 at 6:45 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Is pg_standby killed correctly when postmaster dies? No. In my test (v8.3.7 on Win), an immediate shutdown was able to kill postmaster, but not pg_standby and the startup

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

2009-11-04 Thread Alvaro Herrera
KaiGai Kohei wrote: postgres=# SELECT * FROM t2; ERROR: could not find inherited attribute b of relation t3 Because t3.b is also inherited from the t2, but ALTER TABLE does not care about multiple inherited columns well. I think we should not allow to rename a column with

Re: [HACKERS] DISTINCT ON

2009-11-04 Thread Emmanuel Cecchet
Tom Lane wrote: Greg Stark gsst...@mit.edu writes: On Wed, Nov 4, 2009 at 3:17 AM, Emmanuel Cecchet m...@asterdata.com wrote: SELECT DISTINCT ON ('1'::varchar, '1'::varchar) a FROM (SELECT 1 AS a) AS a ORDER BY '1'::varchar, '1'::varchar, '2'::varchar; This sounds

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

2009-11-04 Thread Thom Brown
2009/11/4 Alvaro Herrera alvhe...@commandprompt.com: KaiGai Kohei wrote:   postgres=# SELECT * FROM t2;   ERROR:  could not find inherited attribute b of relation t3 Because t3.b is also inherited from the t2, but ALTER TABLE does not care about multiple inherited columns well. I think we

[HACKERS] PL/Python array support

2009-11-04 Thread Peter Eisentraut
Here is a patch to support arrays in PL/Python as parameters and return values. It converts an array parameter to a Python list, and converts a Python sequence return value back to an array. I have settled on two implementation restrictions for the moment: - Only supports one-dimensional

[HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

2009-11-04 Thread Bernd Helmle
I just run across an issue with ALTER TABLE and inheritance (i don't know wether this is of the same kind of issue KaiGai reported today, so i keep it on a separate thread). Consider the following workflow: CREATE TABLE foo(id integer NOT NULL, val text NOT NULL); CREATE TABLE

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

2009-11-04 Thread Tom Lane
Thom Brown thombr...@gmail.com writes: 2009/11/4 Alvaro Herrera alvhe...@commandprompt.com: KaiGai Kohei wrote: I think we should not allow to rename a column with attinhcount 1. I think we should fix ALTER TABLE to cope with multiple inheritance. I'd be interested to see how this should

Re: [HACKERS] PL/Python array support

2009-11-04 Thread Robert Haas
On Wed, Nov 4, 2009 at 9:02 AM, Peter Eisentraut pete...@gmx.net wrote: Here is a patch to support arrays in PL/Python as parameters and return values.  It converts an array parameter to a Python list, and converts a Python sequence return value back to an array. This is probably a stupid

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

2009-11-04 Thread Tom Lane
Bernd Helmle maili...@oopsware.de writes: Consider the following workflow: CREATE TABLE foo(id integer NOT NULL, val text NOT NULL); CREATE TABLE foo2(another_id integer NOT NULL) INHERITS(foo); Now someone decides he doesn't want the NOT NULL constraint on the inherited column val

Re: [HACKERS] PL/Python array support

2009-11-04 Thread Peter Eisentraut
On ons, 2009-11-04 at 09:44 -0500, Robert Haas wrote: On Wed, Nov 4, 2009 at 9:02 AM, Peter Eisentraut pete...@gmx.net wrote: Here is a patch to support arrays in PL/Python as parameters and return values. It converts an array parameter to a Python list, and converts a Python sequence

Re: [HACKERS] WIP: pushing parser hooks through SPI and plancache

2009-11-04 Thread Alvaro Herrera
Tom Lane wrote: It turns out that this typedef is needed in two relatively low-level .h files: nodes/params.h and utils/plancache.h. My original idea had been to define the hook typedef in parser/parse_node.h where struct ParseState is defined. But that would have required pulling a

Re: [HACKERS] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

2009-11-04 Thread Jaime Casanova
On Tue, Nov 3, 2009 at 6:31 AM, Peter Eisentraut pete...@gmx.net wrote: Is anyone planning to do further work on this?  This appears to be blocking the client_encoding=auto feature. yes, i'm planning to make an attempt to do it as soon as i get some time... but if you think it's important

Re: [HACKERS] Proposal - temporal contrib module

2009-11-04 Thread Chris Browne
arta...@comcast.net (Scott Bailey) writes: Disk format - A period can be represented as [closed-closed], (open-open), [closed-open) or (open-closed] intervals. Right now we convert these to the most common form, closed-open and store as two timestamptz's. I mentioned this at the 2009 PGCon,

Re: [HACKERS] Proposal - temporal contrib module

2009-11-04 Thread Jeff Davis
On Wed, 2009-11-04 at 12:08 -0500, Chris Browne wrote: I'm a lot less certain about the merits of PK/FK constraints - it is a lot less obvious what forms of constraints will be able to be applied to particular applications. Can you clarify, a little? A temporal key just means non-overlapping

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

2009-11-04 Thread Bernd Helmle
--On 4. November 2009 09:57:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote: I think the consensus was that the way to fix this (along with some other problems) is to start representing NOT NULL constraints in pg_constraint, turning attnotnull into just a bit of denormalization for performance.

[HACKERS] ERROR: could not read block 6 ...: read only 0 of 8192 bytes after autovacuum cancelled

2009-11-04 Thread Alvaro Herrera
A customer of ours recently hit a problem where after an autovacuum was cancelled on a table, the app started getting the message in $subject: ERROR: could not read block 6 of relation 1663/35078/1761966: read only 0 of 8192 bytes (block numbers vary from 1 to 6). Things remained in this

Re: [HACKERS] WIP: pushing parser hooks through SPI and plancache

2009-11-04 Thread Tom Lane
Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: ... For the moment I've worked around this by putting the typedef into nodes/params.h itself, but I can't say I find that a pleasing solution. Has anyone got a better idea? Should we make a parser/something header that just

Re: [HACKERS] ERROR: could not read block 6 ...: read only 0 of 8192 bytes after autovacuum cancelled

2009-11-04 Thread Tom Lane
Alvaro Herrera alvhe...@commandprompt.com writes: What I thought could have happened is that the table was truncated, and then the sinval message telling that to other backends was not sent due to the rollback. Hmm. So far as I can see, what we need is to make sure the sinval message is

[HACKERS] Experimental patch: generating BKI revisited

2009-11-04 Thread John Naylor
Hello everyone, I was quite intrigued by a discussion that happened this past summer regarding generation of bootstrap files such as postgres.bki, and the associated pain points of maintaining the DATA() statements in catalog headers. It occurred to me that the current system is backwards:

Re: [HACKERS] WIP: pushing parser hooks through SPI and plancache

2009-11-04 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: ... For the moment I've worked around this by putting the typedef into nodes/params.h itself, but I can't say I find that a pleasing solution. Has anyone got a better idea? Should we make a

Re: [HACKERS] A small bug in gram.y

2009-11-04 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: ... But pointing to ESCAPE is just weird. I've changed these all to @2 (LIKE, ILIKE, SIMILAR TO). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Architecture of walreceiver (Streaming Replication)

2009-11-04 Thread Tatsuo Ishii
Recently, the development of SR is not progressing because of the indecision on whether walreceiver should be a subprocess of the startup process (i.e., a stand-alone program), or of postmaster. Since time is running out, I'd like to discuss about this and advance the project. The related

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

2009-11-04 Thread KaiGai Kohei
Tom Lane wrote: Thom Brown thombr...@gmail.com writes: 2009/11/4 Alvaro Herrera alvhe...@commandprompt.com: KaiGai Kohei wrote: I think we should not allow to rename a column with attinhcount 1. I think we should fix ALTER TABLE to cope with multiple inheritance. I'd be interested to

[HACKERS] Shall we just get rid of plpgsql's RENAME?

2009-11-04 Thread Tom Lane
According to http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-RENAMING-VARS the RENAME declaration in plpgsql has been known broken since PG 7.3. Nobody has bothered to fix it. Shall we just rip it out? The reason I'm looking at it right now is that

Re: [HACKERS] Shall we just get rid of plpgsql's RENAME?

2009-11-04 Thread David E. Wheeler
On Nov 4, 2009, at 5:34 PM, Tom Lane wrote: According to http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-RENAMING-VARS the RENAME declaration in plpgsql has been known broken since PG 7.3. Nobody has bothered to fix it. Shall we just rip it out?