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

On 01/13/2013 08:06 PM, Dimitri Fontaine wrote: 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. What i

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

On 01/13/2013 09:04 PM, Hannu Krosing wrote: > I'd just start with what send() and recv() on each type produces > now using GCC on 64bit Intel and move towards adjusting others > to match. For a period anything else would still be allowed, but > be "non-standard" Intel being little endian seems li

[HACKERS] Thinking about WITH CHECK OPTION for views

I've been thinking about WITH CHECK OPTION for auto-updatable views. Given the timing I doubt if this will be ready for 9.3, since I only get occasional evenings and weekends to hack on postgres, but I think it's probably worth kicking off a discussion, starting with a description of what the featu

Re: [HACKERS] pg_retainxlog for inclusion in 9.3?

On Sat, Jan 5, 2013 at 3:11 PM, Magnus Hagander wrote: > On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut wrote: >> On 1/3/13 12:30 PM, Robert Haas wrote: >>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander >>> wrote: Any particular reason? It goes pretty tightly together with pg_rec

[HACKERS] common fe/be library (was Re: [PATCH] binary heap implementation)

At 2012-11-15 12:08:12 -0500, robertmh...@gmail.com wrote: > > Still, maybe we could have a src/framework directory that uses the > same trick to produce a libpgframework that frontend code can use, > and a lib pgframework_srv that can be linked into the backend. > That's might not actually be that

[HACKERS] pg_ctl idempotent option

Here is a patch to add an option -I/--idempotent to pg_ctl, the result of which is that pg_ctl doesn't error on start or stop if the server is already running or already stopped. The previous discussion was at . dif

[HACKERS] find libxml2 using pkg-config

In multi-arch OS installations, using a single foo-config script to find libraries is problematic, because you don't know which architecture it will point to, and you can't choose which one you want. Using pkg-config is better in that situation, because you can use its environment variables to poi

[HACKERS] passing diff options to pg_regress

I sometimes find it useful to view a regression test difference using other diff options, such as -u -w or more context. There is currently no easy way to accomplish that. I suggest allowing to override the diff options using an environment variable, such as PG_REGRESS_DIFF_OPTS. The patch is ve

Re: [HACKERS] Bug: Windows installer modifies ACLs on the whole volume

Alex, how much of your D:\ is occupied or what is the total size of the files and folders in D:\ ? Can you just try the following command manually to see if it returns quick? icacls D:\ /grant "UserName":RX On Fri, Jan 11, 2013 at 9:28 AM, Craig Ringer wrote: > On 01/09/2013 05:10 PM, emergen

Re: [HACKERS] passing diff options to pg_regress

On 2013-01-14 06:57:52 -0500, Peter Eisentraut wrote: > I sometimes find it useful to view a regression test difference using > other diff options, such as -u -w or more context. There is currently > no easy way to accomplish that. > > I suggest allowing to override the diff options using an envi

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

On Mon, Jan 14, 2013 at 12:46 AM, 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 unconvinced that

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

On Mon, Jan 14, 2013 at 02:21:00PM +0200, Marko Kreen wrote: > Note: reading from /dev/urandom does not affect /dev/random. Reading from /dev/urandom drains the pool that serves /dev/random: $ cat /proc/sys/kernel/random/entropy_avail 3596 $ dd iflag=nonblock bs=100 count=1 if=/dev/random of=/de

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

2013-01-14 07:47 keltezéssel, Amit kapila írta: 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/backe

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

On Mon, Jan 14, 2013 at 3:00 PM, Noah Misch wrote: > On Mon, Jan 14, 2013 at 02:21:00PM +0200, Marko Kreen wrote: >> Note: reading from /dev/urandom does not affect /dev/random. > > Reading from /dev/urandom drains the pool that serves /dev/random: > > $ cat /proc/sys/kernel/random/entropy_avail >

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

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > 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 > >

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

On 14 January 2013 13:43, Stephen Frost wrote: > Tom, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> 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 out

Re: [HACKERS] common fe/be library (was Re: [PATCH] binary heap implementation)

On Mon, Jan 14, 2013 at 4:55 AM, Abhijit Menon-Sen wrote: > At 2012-11-15 12:08:12 -0500, robertmh...@gmail.com wrote: >> >> Still, maybe we could have a src/framework directory that uses the >> same trick to produce a libpgframework that frontend code can use, >> and a lib pgframework_srv that ca

Re: [HACKERS] pg_ctl idempotent option

Peter Eisentraut writes: > Here is a patch to add an option -I/--idempotent to pg_ctl, the result > of which is that pg_ctl doesn't error on start or stop if the server is > already running or already stopped. Idempotent is a ten-dollar word. Can we find something that average people wouldn't ne

Re: [HACKERS] find libxml2 using pkg-config

Peter Eisentraut writes: > The attached patch looks for pkg-config first, and finds libxml2 using > that if available. Otherwise it falls back to using xml2-config. What happens if pkg-config is installed but doesn't know anything about xml2? I'd expect the code to fall back to the old method,

Re: [HACKERS] pg_ctl idempotent option

Tom Lane wrote: > Peter Eisentraut writes: > > Here is a patch to add an option -I/--idempotent to pg_ctl, the result > > of which is that pg_ctl doesn't error on start or stop if the server is > > already running or already stopped. > > Idempotent is a ten-dollar word. Can we find something tha

Re: [HACKERS] erroneous restore into pg_catalog schema

Tom Lane escribió: > I will bet that this is more breakage from the DDL-code refactoring that > has been going on. I am getting closer and closer to wanting that > reverted. KaiGai-san seems to have been throwing out lots of special > cases that were there for good reasons. I will have a look.

Re: [HACKERS] pg_ctl idempotent option

Alvaro Herrera writes: > Tom Lane wrote: >> Peter Eisentraut writes: >>> Here is a patch to add an option -I/--idempotent to pg_ctl, the result >>> of which is that pg_ctl doesn't error on start or stop if the server is >>> already running or already stopped. >> Idempotent is a ten-dollar word.

Re: [HACKERS] pg_ctl idempotent option

On 14 January 2013 15:29, Alvaro Herrera wrote: > Tom Lane wrote: > > Peter Eisentraut writes: > > > Here is a patch to add an option -I/--idempotent to pg_ctl, the result > > > of which is that pg_ctl doesn't error on start or stop if the server is > > > already running or already stopped. > >

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

* Simon Riggs (si...@2ndquadrant.com) wrote: > There is a new option being added to pre/post process data, so it > seems like the best way to add new features - in general. That structure appears to have no option for passing compressed data to or from a client connection. Instead, it actually ov

Re: [HACKERS] erroneous restore into pg_catalog schema

Tom Lane escribió: > "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 ]

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

On Mon, Jan 14, 2013 at 1:01 PM, Stephen Frost wrote: > I do like the idea of a generalized answer which just runs a > user-provided command on the server but that's always going to require > superuser privileges. Unless it's one of a set of superuser-authorized compression tools. -- Sent via

Re: [HACKERS] erroneous restore into pg_catalog schema

Alvaro Herrera writes: > Tom Lane escribió: >> I will bet that this is more breakage from the DDL-code refactoring that >> has been going on. I am getting closer and closer to wanting that >> reverted. KaiGai-san seems to have been throwing out lots of special >> cases that were there for good r

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

Stephen Frost writes: > I do like the idea of a generalized answer which just runs a > user-provided command on the server but that's always going to require > superuser privileges. The design that was being kicked around allowed pipes to be used on the client side too, ie \copy foo to '| gzip ..

Re: [HACKERS] Timing events WIP v1

I decided to take a look at this. On 15 November 2012 09:56, Greg Smith wrote: > -I modeled the hook here on the logging one that went into 9.2. It's > defined in its own include file and it gets initialized by the logging > system. No strong justification for putting it there, it was just simi

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

* Claudio Freire (klaussfre...@gmail.com) wrote: > On Mon, Jan 14, 2013 at 1:01 PM, Stephen Frost wrote: > > I do like the idea of a generalized answer which just runs a > > user-provided command on the server but that's always going to require > > superuser privileges. > > Unless it's one of a s

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

On Monday, January 14, 2013 6:48 PM Boszormenyi Zoltan wrote: 2013-01-14 07:47 keltezéssel, Amit kapila írta: > 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 Zolt

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I do like the idea of a generalized answer which just runs a > > user-provided command on the server but that's always going to require > > superuser privileges. > > The design that was being kicked around allowed pipes to be used

Re: [HACKERS] json api WIP patch

On Thu, Jan 10, 2013 at 6:42 PM, Andrew Dunstan wrote: >> Udated patch that contains most of the functionality I'm after. One piece >> left is populate_recordset (populate a set of records from a single json >> datum which is an array of objects, in one pass). That requires a bit of >> thought. >>

Re: [HACKERS] [PERFORM] Slow query: bitmap scan troubles

On Thu, Jan 10, 2013 at 8:07 PM, Tom Lane wrote: > Comments? I'm not sure I have anything intelligent to add to this conversation - does that make me the wisest of all the Greeks? - but I do think it worth mentioning that I have heard occasional reports within EDB of the query planner refusing to

Re: [HACKERS] Get current query in a trigger function

On Fri, Jan 11, 2013 at 4:47 AM, Vlad Arkhipov wrote: > Is there any simple way of getting a query for which a trigger was executed? > debug_query_string and ActivePortal->sourceText return the top query when > there are nested triggers. I believe - only if the trigger is written in C. -- Rober

Re: [HACKERS] pg_ctl idempotent option

2013-01-14 16:22 keltezéssel, Tom Lane írta: Peter Eisentraut writes: Here is a patch to add an option -I/--idempotent to pg_ctl, the result of which is that pg_ctl doesn't error on start or stop if the server is already running or already stopped. Idempotent is a ten-dollar word. Can we find

Re: [HACKERS] GIN over array of ENUMs

On Thu, Jan 10, 2013 at 12:08 PM, Rod Taylor wrote: > I wish to create this data structure but GIN does not currently support an > array of ENUM. Is intarray() a good place to look into adding ENUM support > or is there already an operator class for working supports enums that I > simply don't see

Re: [HACKERS] erroneous restore into pg_catalog schema

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane escribi�: > >> I will bet that this is more breakage from the DDL-code refactoring that > >> has been going on. I am getting closer and closer to wanting that > >> reverted. KaiGai-san seems to have been throwing out lots of special > >> case

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

Pavel Stehule writes: > this is very simple patch - it enables hidden_queries for commands > \sf and \ef to be consistent with other describing commands. So far as I can tell, get_create_function_cmd (and lookup_function_oid too) were intentionally designed to not show their queries, and for th

Re: [HACKERS] pg_retainxlog for inclusion in 9.3?

On Fri, Jan 4, 2013 at 4:55 PM, Dimitri Fontaine wrote: > Robert Haas writes: >> Mostly that it seems like a hack, and I suspect we may come up with a >> better way to do this in the future. > > Do you have the specs of such better way? Would it be a problem to have > both pg_retainxlog and the n

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

2013/1/14 Tom Lane : > Pavel Stehule writes: >> this is very simple patch - it enables hidden_queries for commands >> \sf and \ef to be consistent with other describing commands. > > So far as I can tell, get_create_function_cmd (and lookup_function_oid > too) were intentionally designed to not

Re: [HACKERS] PL/perl should fail on configure, not make

pgbuildf...@jdrake.com writes: > On Thu, 10 Jan 2013, Andrew Dunstan wrote: >> Without access to the machine it's pretty hard to know, so I was just >> speculating fairly wildly. If Jeremy can find out what the problem is that >> would be good, or if he can give us access to the machine it shouldn'

Re: [HACKERS] [PERFORM] Slow query: bitmap scan troubles

Robert Haas writes: > I'm not sure I have anything intelligent to add to this conversation - > does that make me the wisest of all the Greeks? - but I do think it > worth mentioning that I have heard occasional reports within EDB of > the query planner refusing to use extremely large indexes no ma

Re: [HACKERS] erroneous restore into pg_catalog schema

Alvaro Herrera writes: > The attached patch seems to work: > alvherre=# create table pg_catalog.foo (a int); > ERROR: permission denied for schema pg_catalog > I notice that contrib/adminpack now fails, though (why doesn't this > module have a regression test?): > alvherre=# create extension a

Re: [HACKERS] erroneous restore into pg_catalog schema

Tom Lane writes: > Um. I knew that that module's desire to shove stuff into pg_catalog > would bite us someday. But now that I think about it, I'm pretty sure > I recall discussions to the effect that there are other third-party > modules doing similar things. Yes, and some more have been start

[HACKERS] Re: Privileges for INFORMATION_SCHEMA.SCHEMATA (was Re: [DOCS] Small clarification in "34.41. schemata")

On Wed, Jan 9, 2013 at 8:56 PM, Tom Lane wrote: > However, it seems to me that this behavior is actually wrong for our > purposes, as it represents a too-literal reading of the spec. The SQL > standard has no concept of privileges on schemas, only ownership. > We do have privileges on schemas, s

Re: [HACKERS] [PERFORM] Slow query: bitmap scan troubles

On Mon, Jan 14, 2013 at 12:23 PM, Tom Lane wrote: > Robert Haas writes: >> I'm not sure I have anything intelligent to add to this conversation - >> does that make me the wisest of all the Greeks? - but I do think it >> worth mentioning that I have heard occasional reports within EDB of >> the qu

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

On Mon, Jan 14, 2013 at 11:56 AM, Tom Lane wrote: > So far as I can tell, get_create_function_cmd (and lookup_function_oid > too) were intentionally designed to not show their queries, and for that > matter they go out of their way to produce terse error output if they > fail. I'm not sure why we

Re: [HACKERS] json api WIP patch

On 01/14/2013 11:32 AM, Robert Haas wrote: So, how much performance does this lose on json_in() on a large cstring, as compared with master? That's a good question. I'll try to devise a test. I can't shake the feeling that this is adding a LOT of unnecessary data copying. For one thing, i

Re: [HACKERS] [PERFORM] Slow query: bitmap scan troubles

Robert Haas writes: > On Mon, Jan 14, 2013 at 12:23 PM, Tom Lane wrote: >> The old code definitely had an unreasonably large charge for indexes >> exceeding 1e8 or so tuples. This wouldn't matter that much for simple >> single-table lookup queries, but I could easily see it putting the >> kibosh

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

Robert Haas writes: > On Mon, Jan 14, 2013 at 11:56 AM, Tom Lane wrote: >> So far as I can tell, get_create_function_cmd (and lookup_function_oid >> too) were intentionally designed to not show their queries, and for that >> matter they go out of their way to produce terse error output if they >>

Re: [HACKERS] Re: Privileges for INFORMATION_SCHEMA.SCHEMATA (was Re: [DOCS] Small clarification in "34.41. schemata")

Casey Allen Shobe writes: > On Wed, Jan 9, 2013 at 8:56 PM, Tom Lane wrote: >> However, it seems to me that this behavior is actually wrong for our >> purposes, as it represents a too-literal reading of the spec. The SQL >> standard has no concept of privileges on schemas, only ownership. >> We

Re: [HACKERS] erroneous restore into pg_catalog schema

Tom Lane escribió: > Alvaro Herrera writes: > > alvherre=# create extension adminpack; > > ERROR: permission denied for schema pg_catalog > > Um. I knew that that module's desire to shove stuff into pg_catalog > would bite us someday. But now that I think about it, I'm pretty sure > I recall

Re: [HACKERS] Hash twice

On Sat, Jan 12, 2013 at 11:39 AM, Simon Riggs wrote: > Lock code says it calculates "hash value once and then pass around as needed". > > But it actually calculates it twice for new locks. > > Trivial patch attached to make it follow the comments in > LockTagHashCode and save a few cycles. Hmm.

Re: [HACKERS] Hash twice

On 14 January 2013 19:12, Robert Haas wrote: > On Sat, Jan 12, 2013 at 11:39 AM, Simon Riggs wrote: >> Lock code says it calculates "hash value once and then pass around as >> needed". >> >> But it actually calculates it twice for new locks. >> >> Trivial patch attached to make it follow the com

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

Tom Lane-2 wrote > Gurjeet Singh < > singh.gurjeet@ > > 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

Re: [HACKERS] Validation in to_date()

Hitoshi Harada writes: > to_date() doesn't check the date range, which results in unreadable > data like this. > foo=# create table t as select to_date('-12-10 BC', '-MM-DD > BC')::timestamp; > SELECT 1 > foo=# table t; > ERROR: timestamp out of range > Attached is to add IS_VALID_JULIA

Re: [HACKERS] Timing events WIP v1

On 1/14/13 11:19 AM, Peter Geoghegan wrote: I noticed that when !log_checkpoints, control never reaches the site where the hook is called, and thus the checkpoint info is not stored. Is that the intended behaviour of the patch? I was aware and considered it a defensible situation--that turning

Re: [HACKERS] fix SQL example syntax in file comment

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: > Here's a trivial patch that fixes a comment in execProcNode.c Applied, thanks. > For archeological interest, that comment dates back to when it was > written in POSTQUEL... The cleanup in > a9b1ff4c1d699c8aa615397d47bb3071275c64ef changed RETRIEVE to

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

Andrew Dunstan wrote: >> For Linux, perhaps some form of lsof with the +D option? > This actually won't help. In most cases the relevant data directory has > long disappeared out from under the rogue postmaster as part of > buildfarm cleanup. Also, lsof is not universally available. We try to

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

David Johnston writes: > Tom Lane-2 wrote >> For that to return zero, it would also be necessary for "SELECT 2+2" >> to return zero rows. Which would be consistent with some views of the >> universe, but not particularly useful. > Given that: > SELECT *; > Results in: > SQL Error: ERROR: SELE

[HACKERS] Curious buildfarm failures

Since commit 2065dd2834e832eb820f1fbcd16746d6af1f6037, there have been a few buildfarm failures along the lines of -- Commit table drop COMMIT PREPARED 'regress-two'; ! PANIC: failed to re-find shared proclock object ! PANIC: failed to re-find shared proclock object ! connection to server

Re: [HACKERS] Curious buildfarm failures

On 2013-01-14 16:35:48 -0500, Tom Lane wrote: > Since commit 2065dd2834e832eb820f1fbcd16746d6af1f6037, there have been > a few buildfarm failures along the lines of > > -- Commit table drop > COMMIT PREPARED 'regress-two'; > ! PANIC: failed to re-find shared proclock object > ! PANIC: fail

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

On 1/14/13 11:28 AM, Stephen Frost wrote: > While there is no option currently for having the server do the > compression before sending the data over the wire. OpenSSL? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgr

Re: [HACKERS] Curious buildfarm failures

On 2013-01-14 22:50:16 +0100, Andres Freund wrote: > On 2013-01-14 16:35:48 -0500, Tom Lane wrote: > > Since commit 2065dd2834e832eb820f1fbcd16746d6af1f6037, there have been > > a few buildfarm failures along the lines of > > > > -- Commit table drop > > COMMIT PREPARED 'regress-two'; > > ! PAN

Re: [HACKERS] Curious buildfarm failures

On 14.01.2013 23:35, Tom Lane wrote: Since commit 2065dd2834e832eb820f1fbcd16746d6af1f6037, there have been a few buildfarm failures along the lines of -- Commit table drop COMMIT PREPARED 'regress-two'; ! PANIC: failed to re-find shared proclock object ! PANIC: failed to re-find shared

[HACKERS] s/size_t/off_t/ in sendTimeLineHistory

Hi, When looking at the report of probable fallout from the elog stuff I noticed this warning: walsender.c(366): warning #186: pointless comparison of unsigned integer with zero Which is accurate, the rather unlikely problem of a seek error could not be noticed atm and would probably send stran

Re: [HACKERS] recent ALTER whatever .. SET SCHEMA refactoring

Kohei KaiGai escribió: > I'm probably saying same idea. It just adds invocation of external > functions to check naming conflicts of functions or collation; that > takes additional 4-lines for special case handling > in AlterObjectNamespace_internal(). Okay, I can agree with this implementation p

Re: [HACKERS] Curious buildfarm failures

On 15.01.2013 00:14, Heikki Linnakangas wrote: On 14.01.2013 23:35, Tom Lane wrote: Since commit 2065dd2834e832eb820f1fbcd16746d6af1f6037, there have been a few buildfarm failures along the lines of -- Commit table drop COMMIT PREPARED 'regress-two'; ! PANIC: failed to re-find shared proclock o

Re: [HACKERS] s/size_t/off_t/ in sendTimeLineHistory

On 15.01.2013 00:27, Andres Freund wrote: When looking at the report of probable fallout from the elog stuff I noticed this warning: walsender.c(366): warning #186: pointless comparison of unsigned integer with zero Which is accurate, the rather unlikely problem of a seek error could not be no

[HACKERS] [PATCH] Compile without warning with gcc's -Wtype-limits, -Wempty-body

Hi, the attached trivial patch allows to compile with -Wtype-limits -Wempty-body (or -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers). As the two fixes seem harmless, that seems to be a good idea. And the recent "bug" (its not really that, but ...) in walsender.c s

Re: [HACKERS] json api WIP patch

On Thu, Jan 10, 2013 at 5:42 PM, Andrew Dunstan wrote: > > On 01/04/2013 03:23 PM, Andrew Dunstan wrote: >> >> >> On 01/02/2013 05:51 PM, Andrew Dunstan wrote: >>> >>> >>> On 01/02/2013 04:45 PM, Robert Haas wrote: On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan wrote: > >

Re: [HACKERS] json api WIP patch

On 01/14/2013 07:36 PM, Merlin Moncure wrote: While testing this I noticed that integer based 'get' routines are zero based -- was this intentional? Virtually all other aspects of SQL are 1 based: postgres=# select json_get('[1,2,3]', 1); json_get -- 2 (1 row) postgres=# select js

Re: [HACKERS] [PATCH] Compile without warning with gcc's -Wtype-limits, -Wempty-body

On Tue, 2013-01-15 at 00:29 +0100, Andres Freund wrote: > Independently from this patch, should we add -Wtype-limits to the > default parameters? I think we have had a discussion along this line before. I am against fixing warnings from this option, because those changes would hide errors if a va

Re: [HACKERS] [PATCH] Compile without warning with gcc's -Wtype-limits, -Wempty-body

On 2013-01-14 20:39:05 -0500, Peter Eisentraut wrote: > On Tue, 2013-01-15 at 00:29 +0100, Andres Freund wrote: > > Independently from this patch, should we add -Wtype-limits to the > > default parameters? > > I think we have had a discussion along this line before. I am against > fixing warnings

Re: [HACKERS] logical changeset generation v4

Andreas, Is there a git fork for logical replication somewhere? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical changeset generation v4

Josh Berkus schrieb: >Andreas, > >Is there a git fork for logical replication somewhere? Check the bottom of the email ;) --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] logical changeset generation v4

At 2013-01-14 18:15:39 -0800, j...@agliodbs.com wrote: > > Is there a git fork for logical replication somewhere? git://git.postgresql.org/git/users/andresfreund/postgres.git, branch xlog-decoding-rebasing-cf4 (and xlogreader_v4). -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hacker

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

* Peter Eisentraut (pete...@gmx.net) wrote: > On 1/14/13 11:28 AM, Stephen Frost wrote: > > While there is no option currently for having the server do the > > compression before sending the data over the wire. > > OpenSSL? To be honest, I expected that to come up earlier in this discussion. It'd

Re: [HACKERS] Get current query in a trigger function

On 01/15/2013 01:45 AM, Robert Haas wrote: On Fri, Jan 11, 2013 at 4:47 AM, Vlad Arkhipov wrote: Is there any simple way of getting a query for which a trigger was executed? debug_query_string and ActivePortal->sourceText return the top query when there are nested triggers. I believe - only if

Re: [HACKERS] Curious buildfarm failures

Heikki Linnakangas writes: > The problem seems to be when the the old and the key hash to the same > bucket. In that case, hash_update_hash_key() tries to link the entry to > itself. The attached patch fixes it for me. Doh! I had a feeling that that needed a special case, but didn't think hard

Re: [HACKERS] logical changeset generation v4

At 2013-01-15 02:38:45 +0100, and...@2ndquadrant.com wrote: > > 2) Currently the logical replication infrastructure assigns a > 'slot-id' when a new replica is setup. That slot id isn't really > nice (e.g. "id-321578-3"). It also requires that [18] keeps state > in a global variable to make writing

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

On Mon, Jan 14, 2013 at 3:09 PM, David Johnston wrote: > What does "SELECT * FROM dual" in Oracle yield? > AFAICR, 'dual' table has one column named 'DUMMY' and one row with value, single character X. -- Gurjeet Singh http://gurjeet.singh.im/

Re: [HACKERS] [PATCH] Compile without warning with gcc's -Wtype-limits, -Wempty-body

Andres Freund writes: > On 2013-01-14 20:39:05 -0500, Peter Eisentraut wrote: >> On Tue, 2013-01-15 at 00:29 +0100, Andres Freund wrote: >>> Independently from this patch, should we add -Wtype-limits to the >>> default parameters? >> I think we have had a discussion along this line before. I am

Re: [HACKERS] Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

Gurjeet Singh writes: > Please find attached two patches, implementing two different approaches to > fix the issue of COMMIT truncating empty TEMP tables that have the ON > COMMIT DELETE ROWS attribute. > v2.patch: This approach introduces a boolean 'rd_rows_inserted' in > RelationData struct, an

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

On Mon, Jan 14, 2013 at 4:15 PM, Tom Lane wrote: > David Johnston writes: > > Tom Lane-2 wrote > >> For that to return zero, it would also be necessary for "SELECT 2+2" > >> to return zero rows. Which would be consistent with some views of the > >> universe, but not particularly useful. > > > G

Re: [HACKERS] logical changeset generation v4

Andres Freund wrote: I've been giving a couple of these parts a look. In particular > [03] Split out xlog reading into its own module called xlogreader Cleaned this one up a bit last week. I will polish it some more, publish for some final comments, and commit. > [08] wal_decoding: Introduce

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

Gurjeet Singh escribió: > Interesting to note that SELECT * FROM table_with_zero_cols does not > complain of anything. > > postgres=# select * from test1; > -- > (0 rows) > > This I believe result of the fact that we allow user to drop all columns of > a table. > > On a side note, Postgres allo

Re: [HACKERS] Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane wrote: > Gurjeet Singh writes: > > Please find attached two patches, implementing two different approaches > to > > fix the issue of COMMIT truncating empty TEMP tables that have the ON > > COMMIT DELETE ROWS attribute. > > > v2.patch: This approach int

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

On Mon, Jan 14, 2013 at 11:03 PM, Alvaro Herrera wrote: > Gurjeet Singh escribió: > > > Interesting to note that SELECT * FROM table_with_zero_cols does not > > complain of anything. > > > > postgres=# select * from test1; > > -- > > (0 rows) > > > > This I believe result of the fact that we allow

Re: [HACKERS] logical changeset generation v4

On 15/01/13 14:38, Andres Freund wrote: Hi everyone, Here is the newest version of logical changeset generation. I'm quite interested in this feature - so tried applying the 19 patches to the latest 9.3 checkout. Patch and compile are good. However portals seem busted: bench=# BEGIN; B

Re: [HACKERS] logical changeset generation v4

On 15/01/13 17:37, Mark Kirkwood wrote: On 15/01/13 14:38, Andres Freund wrote: Hi everyone, Here is the newest version of logical changeset generation. I'm quite interested in this feature - so tried applying the 19 patches to the latest 9.3 checkout. Patch and compile are good. Howev

Re: [HACKERS] unlogged tables vs. GIST

Hi Robert / Tom I think to support GiST with unlogged table we need to do three things: 1. Teach the buffer manager that the LSN of a page not marked BM_PERMANENT can be ignored 2. Teach GetXLogRecPtrForTemp() to allocate fake LSNs for GiST buffers using a 64-bit, counter that is persisted acros

Re: [HACKERS] pg_retainxlog for inclusion in 9.3?

On Mon, Jan 14, 2013 at 5:56 PM, Robert Haas wrote: > On Fri, Jan 4, 2013 at 4:55 PM, Dimitri Fontaine > wrote: >> Robert Haas writes: >>> Mostly that it seems like a hack, and I suspect we may come up with a >>> better way to do this in the future. >> >> Do you have the specs of such better wa