Re: [HACKERS] I s this a bug of spgist index in a heavy write condition?

at 2013-01-12 02:21, Tom Lane wrote: =?gb2312?B?wO66o8H6?= writes: This time I will give you the contents of the table route_raw, the download link is https://www.box.com/s/yxa4yxo6rcb3dzeaefmz or http://dl.dropbox.com/u/203288/route_raw_spgist.sql.tar.gz . Th

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

On Sunday, January 13, 2013 2:45 PM Boszormenyi Zoltan wrote: 2013-01-13 05:49 keltezéssel, Amit kapila írta: > On Sunday, January 13, 2013 12:41 AM Tom Lane wrote: > Boszormenyi Zoltan writes: No, I mean the reaper(SIGNAL_ARGS) function in src/backend/postmaster/postmaster.c where your

Re: [HACKERS] count(*) of zero rows returns 1

On Sun, Jan 13, 2013 at 4:43 PM, Tom Lane wrote: > Gurjeet Singh writes: > > Can somebody explain why a standalone count(*) returns 1? > > postgres=# select count(*); > > count > > --- > > 1 > > (1 row) > > The Oracle equivalent of that would be "SELECT count(*) FROM dual". > Does it m

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

Stephen Frost writes: > Attached is a patch to add a 'COMPRESSED' option to COPY which will > cause COPY to expect a gzip'd file on input and which will output a > gzip'd file on output. Included is support for backend COPY, psql's > \copy, regression tests for both, and documentation. I

Re: [HACKERS] Possible PANIC in PostPrepare_Locks

Heikki Linnakangas writes: > On 11.01.2013 04:16, Tom Lane wrote: >> Also, it looks like we'll need two code paths in PostPrepare_Locks to >> deal with the possibility that a conflicting entry already exists? >> I'm not sure this is possible, but I'm not sure it's not, either. > If I understand t

[HACKERS] [PATCH] COPY .. COMPRESSED

Greetings, Attached is a patch to add a 'COMPRESSED' option to COPY which will cause COPY to expect a gzip'd file on input and which will output a gzip'd file on output. Included is support for backend COPY, psql's \copy, regression tests for both, and documentation. On top of this I p

Re: [HACKERS] pgcrypto seeding problem when ssl=on

On Sun, Jan 13, 2013 at 05:46:12PM -0500, Tom Lane wrote: > Marko Kreen writes: > > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote: > >> How about instead calling RAND_cleanup() after each backend fork? > > > Attached is a patch that adds RAND_cleanup() to fork_process(). > > I remain uncon

Re: [HACKERS] Wide area replication postgres 9.1.6 slon 2.1.2 large table failure.

Tory M Blue wrote: > Postgres 9.1.4 slon 2.1.1 > -and- > Postgres 9.1.6 slon 2.1.2 If it is possible, it never hurts to rule out bugs for which fixes are already available in production releases: http://www.postgresql.org/support/versioning/ > Symptoms, slon immediately dies after transferring

Re: [HACKERS] pgcrypto seeding problem when ssl=on

Marko Kreen writes: > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote: >> How about instead calling RAND_cleanup() after each backend fork? > Attached is a patch that adds RAND_cleanup() to fork_process(). I remain unconvinced that this is the best solution. Anybody else have an opinion?

Re: [HACKERS] pgcrypto seeding problem when ssl=on

On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote: > How about instead calling RAND_cleanup() after each backend fork? Attached is a patch that adds RAND_cleanup() to fork_process(). That way all forked processes start with fresh state. This should make sure the problem does not happen in any p

Re: [HACKERS] count(*) of zero rows returns 1

Gurjeet Singh writes: > Can somebody explain why a standalone count(*) returns 1? > postgres=# select count(*); > count > --- > 1 > (1 row) The Oracle equivalent of that would be "SELECT count(*) FROM dual". Does it make more sense to you thought of that way? > I agree it's an odd thin

Re: [HACKERS] erroneous restore into pg_catalog schema

"Erik Rijkers" writes: > On Sun, January 13, 2013 22:09, Tom Lane wrote: >> BTW, although Erik claimed this behaved more sanely in 9.2, a closer >> look at the commit logs says that the bogus commit shipped in 9.2, >> so AFAICS it's broken there too. > [ not so ] Hm, you are right, there's anoth

Re: [HACKERS] erroneous restore into pg_catalog schema

On 2013-01-13 12:29:08 -0500, Tom Lane wrote: > "Erik Rijkers" writes: > > If you dump a table with -t schema.table, and in the receiving database > > that schema does not > > exist, pg_restore-9.3devel will restore into the pg_catalog schema: > > ... > > Off course the workaround is obvious, but

Re: [HACKERS] erroneous restore into pg_catalog schema

On Sun, January 13, 2013 22:09, Tom Lane wrote: > > BTW, although Erik claimed this behaved more sanely in 9.2, a closer > look at the commit logs says that the bogus commit shipped in 9.2, > so AFAICS it's broken there too. But earlier releases would have > rejected the SET as expected. I think

Re: [HACKERS] erroneous restore into pg_catalog schema

Tom Lane writes: > "Break"? You can't possibly think that's a good idea. I don't think it is. It's been used as a hack mainly before we had per-user and per-database settings, from what I've seen. > Right, that is the argument for ignoring missing schemas, and I think it > is entirely sensible

Re: [HACKERS] [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: >> Basically, the aspects of this that I think are likely to be >> reproducible wins across different platforms are (a) teaching the >> compiler that elog(ERROR) doesn't return, and (b) reducing code size as >> much as possible. The single-function change isn't going to help

[HACKERS] count(*) of zero rows returns 1

Can somebody explain why a standalone count(*) returns 1? postgres=# select count(*); count --- 1 (1 row) I agree it's an odd thing for someone to query, but I feel it should return 0, and not 1. -- Gurjeet Singh http://gurjeet.singh.im/

Re: [HACKERS] erroneous restore into pg_catalog schema

Dimitri Fontaine writes: > Tom Lane writes: >> I think maybe what we should do is have namespace.c retain an explicit >> notion that "the first schema listed in search_path didn't exist", and >> then throw errors if any attempt is made to create objects without an >> explicitly specified namespac

[HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-13 15:44:58 -0500, Tom Lane wrote: > Andres Freund writes: > > And if you look at the disassembly of ERROR codepaths: > > I think your numbers are being twisted by -fno-omit-frame-pointer. > What I get, with the __builtin_unreachable version of the macro, > looks more like The only d

Re: [HACKERS] erroneous restore into pg_catalog schema

Tom Lane writes: > I think maybe what we should do is have namespace.c retain an explicit > notion that "the first schema listed in search_path didn't exist", and > then throw errors if any attempt is made to create objects without an > explicitly specified namespace. I don't much like this. S

[HACKERS] Re: logical changeset generation v3 - comparison to Postgres-R change set format

On 01/13/2013 12:28 AM, Noah Misch wrote: [Catching up on old threads.] On Sat, Nov 17, 2012 at 03:40:49PM +0100, Hannu Krosing wrote: On 11/17/2012 03:00 PM, Markus Wanner wrote: On 11/17/2012 02:30 PM, Hannu Krosing wrote: Is it possible to replicate UPDATEs and DELETEs without a primary ke

Re: [HACKERS] [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: > On 2013-01-13 14:17:52 -0500, Tom Lane wrote: >> I find these numbers pretty hard to credit. > There are quite some elog(DEBUG*)s in the backend, and those are taken, > so I don't find it unreasonable that doing less work in those cases is > measurable. Meh. If there are

Re: [HACKERS] ToDo: log plans of cancelled queries

Tom Lane writes: >> Set auto_explain.log_min_duration to 19 mins or maybe 17 and be done? > > That would only help if he were willing to wait for the long-running > command to be done (instead of canceling it). It's not hard to think > of commands that will still be running after the heat death o

Re: [HACKERS] Re: logical changeset generation v3 - comparison to Postgres-R change set format

Hannu Krosing writes: >> Does this hint that postgreSQL also needs an sameness operator >> ( "is" or "===" in same languages). > > How do people feel about adding a real sameness operator ? Well. I would prefer it if we can bypass the need for it. Then Do we need the full range of eq, eql, equal

Re: [HACKERS] Re: logical changeset generation v3 - comparison to Postgres-R change set format

On 01/13/2013 06:02 PM, Markus Wanner wrote: On 01/13/2013 12:30 PM, Hannu Krosing wrote: On 01/13/2013 10:49 AM, Hannu Krosing wrote: Does this hint that postgreSQL also needs an sameness operator ( "is" or "===" in same languages). How do people feel about adding a real sameness operator ?

[HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-13 14:17:52 -0500, Tom Lane wrote: > Andres Freund writes: > > the numbers are: > > old definition: 10393.658ms, 5497912 bytes > > old definition + unreachable: 10011.102ms, 5469144 bytes > > stmt, two calls, unreachable:

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: > the numbers are: > old definition: 10393.658ms, 5497912 bytes > old definition + unreachable: 10011.102ms, 5469144 bytes > stmt, two calls, unreachable: 10036.132ms, 5468792 bytes > stmt, one call, unreacha

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-12 16:36:39 -0500, Tom Lane wrote: > Andres Freund writes: > >>> It does *not* combine elog_start and elog_finish into one function if > >>> varargs are available although that brings a rather measurable > >>> size/performance benefit. > > >> Since you've apparently already done the me

Re: [HACKERS] Porting to Haiku

> > On 01/13/2013 12:18 PM, Mark Hellegers wrote: > >> I understand. I will start working on reapplying my patches to > >> master. > >> Git is still new to me, but I'm making progress. > >> > > I'm running into a little problem with applying my patches. > > It seems I made a quick fix in my port t

Re: [HACKERS] [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: > On 2013-01-12 15:39:16 -0500, Tom Lane wrote: >> This is actually a disadvantage of the proposal to replace the abort() >> calls with __builtin_unreachable(), too. The gcc boys interpret the >> semantics of that as "if control reaches here, the behavior is >> undefined" >

[HACKERS] psql binary output

I whipped this up some months ago and forgot that I hadn't sent in the patch. This implements two psql commands: \gb and \gbn Both fetch and output results in binary mode - \gb uses separators, while \gbn does not. Examples: [andrew@emma inst.psql-binout.5705]$ echo "select bytea '\\x0001

Re: [HACKERS] [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-12 18:15:17 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2013-01-12 13:16:56 -0500, Tom Lane wrote: > >> However, using a do-block with a local variable is definitely something > >> worth considering. I'm getting less enamored of the __builtin_constant_p > >> idea after findin

[HACKERS] Re: logical changeset generation v3 - comparison to Postgres-R change set format

On 2013-01-13 12:44:44 -0500, Tom Lane wrote: > Hannu Krosing writes: > > How do people feel about adding a real sameness operator ? > > Just begs the question of "what's sameness?" > > In many places we consider a datatype's default btree equality operator > to define sameness, but not all type

Re: [HACKERS] Re: logical changeset generation v3 - comparison to Postgres-R change set format

On 01/13/2013 12:30 PM, Hannu Krosing wrote: > On 01/13/2013 10:49 AM, Hannu Krosing wrote: >> Does this hint that postgreSQL also needs an sameness operator >> ( "is" or "===" in same languages). > > How do people feel about adding a real sameness operator ? We'd need to define what "sameness" m

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-12 19:47:18 -0500, Tom Lane wrote: > Heikki Linnakangas writes: > > When I compile with gcc -O0, I get one warning with this: > > > datetime.c: In function �DateTimeParseError�: > > datetime.c:3575:1: warning: �noreturn� function does return [enabled by > > default] > > > That sugges

[HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-12 15:39:16 -0500, Tom Lane wrote: > Heikki Linnakangas writes: > > On 12.01.2013 20:42, Andres Freund wrote: > >>> I don't care for that too much in detail -- if errstart were to return > >>> false (it shouldn't, but if it did) this would be utterly broken, > > > With the current erep

Re: [HACKERS] Re: logical changeset generation v3 - comparison to Postgres-R change set format

Hannu Krosing writes: > How do people feel about adding a real sameness operator ? Just begs the question of "what's sameness?" In many places we consider a datatype's default btree equality operator to define sameness, but not all types provide a btree opclass (in particular, anything that hasn

Re: [HACKERS] enhanced error fields

Peter Geoghegan writes: > I felt that this was quite unnecessary because of the limited scope of > the patch, and because this raises thorny issues of both semantics and > implementation. Tom agreed with this general view - after all, this > patch exists for the express purpose of having a well-pr

Re: [HACKERS] Porting to Haiku

On 01/13/2013 12:18 PM, Mark Hellegers wrote: I understand. I will start working on reapplying my patches to master. Git is still new to me, but I'm making progress. I'm running into a little problem with applying my patches. It seems I made a quick fix in my port that I can't commit and I'm n

Re: [HACKERS] ToDo: log plans of cancelled queries

Dimitri Fontaine writes: > Pavel Stehule writes: >> My propose is proposed for different dimensions and purpose - for >> example - we have a limit 20 minutes for almost all queries, and after >> this limit we killing queries. But we have to know little bit more >> about these bad queries - and we

Re: [HACKERS] ToDo: log plans of cancelled queries

2013/1/13 Dimitri Fontaine : > Pavel Stehule writes: >> My propose is proposed for different dimensions and purpose - for >> example - we have a limit 20 minutes for almost all queries, and after >> this limit we killing queries. But we have to know little bit more >> about these bad queries - and

Re: [HACKERS] erroneous restore into pg_catalog schema

"Erik Rijkers" writes: > If you dump a table with -t schema.table, and in the receiving database that > schema does not > exist, pg_restore-9.3devel will restore into the pg_catalog schema: > ... > Off course the workaround is obvious, but shouldn't this be prevented from > happening in the firs

Re: [HACKERS] [Pgbuildfarm-members] Version 4.10 of buildfarm client released.

On 01/13/2013 10:58 AM, Kevin Grittner wrote: Andrew Dunstan wrote: Part of the trouble with detecting rogue postmasters it might have left lying around is that various things like to decide what port to run on, so it's not always easy for the buildfarm to know what it should be looking for.

Re: [HACKERS] Porting to Haiku

> I understand. I will start working on reapplying my patches to > master. > Git is still new to me, but I'm making progress. > I'm running into a little problem with applying my patches. It seems I made a quick fix in my port that I can't commit and I'm not sure what the best way to fix this

Re: [HACKERS] [Pgbuildfarm-members] Version 4.10 of buildfarm client released.

Andrew Dunstan wrote: > Part of the trouble with detecting rogue postmasters it might have left > lying around is that various things like to decide what port to run on, > so it's not always easy for the buildfarm to know what it should be > looking for. For Linux, perhaps some form of lsof wi

Re: [HACKERS] erroneous restore into pg_catalog schema

"Erik Rijkers" writes: > (and yes, I did restore a 65 GB table into the pg_catalog schema of a dev > machine; how can I > remove it? I could initdb, but it's 200+ GB; I'd rather not have to rebuild > it) See allow_system_table_mods http://www.postgresql.org/docs/9.2/static/runtime-config-dev

Re: [HACKERS] ToDo: log plans of cancelled queries

Pavel Stehule writes: > My propose is proposed for different dimensions and purpose - for > example - we have a limit 20 minutes for almost all queries, and after > this limit we killing queries. But we have to know little bit more > about these bad queries - and we hope, so execution plan can giv

[HACKERS] Re: logical changeset generation v3 - comparison to Postgres-R change set format

On 01/13/2013 10:49 AM, Hannu Krosing wrote: On 01/13/2013 12:28 AM, Noah Misch wrote: [Catching up on old threads.] On Sat, Nov 17, 2012 at 03:40:49PM +0100, Hannu Krosing wrote: On 11/17/2012 03:00 PM, Markus Wanner wrote: On 11/17/2012 02:30 PM, Hannu Krosing wrote: Is it possible to repli

[HACKERS] Re: logical changeset generation v3 - comparison to Postgres-R change set format

On 01/13/2013 12:28 AM, Noah Misch wrote: [Catching up on old threads.] On Sat, Nov 17, 2012 at 03:40:49PM +0100, Hannu Krosing wrote: On 11/17/2012 03:00 PM, Markus Wanner wrote: On 11/17/2012 02:30 PM, Hannu Krosing wrote: Is it possible to replicate UPDATEs and DELETEs without a primary ke

Re: [HACKERS] enhanced error fields

On 13 January 2013 06:13, Pavel Stehule wrote: >> Not sure, but I don't think it matters. You can blame the constraint >> implementation, but that doesn't change my feelings about what we need >> before we can accept a patch like this. Providing something which works >> only part of the time and

[HACKERS] erroneous restore into pg_catalog schema

If you dump a table with -t schema.table, and in the receiving database that schema does not exist, pg_restore-9.3devel will restore into the pg_catalog schema: HEAD $ cat test.sh #!/bin/sh db=backupbug; dropdb --echo $db; createdb --echo $db; echo "drop schema if exists s cascade;" | psql

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

2013-01-13 05:49 keltezéssel, Amit kapila írta: On Sunday, January 13, 2013 12:41 AM Tom Lane wrote: Boszormenyi Zoltan writes: No, I mean the reaper(SIGNAL_ARGS) function in src/backend/postmaster/postmaster.c where your patch has this: *** a/src/backend/postmaster/postmaster.c --- b/src/backe