Re: [HACKERS] unite recovery.conf and postgresql.conf

On 12/14/2011 08:56 PM, Josh Berkus wrote: So for streaming replication, will I need to have a standby.enabled file, or will there be a parameter in postgresql.conf (or included files) which controls whether or not that server is a standby, available? In the best of all possible worlds, I'd real

Re: [HACKERS] WIP: Collecting statistics on CSV file data

(2011/12/14 15:34), Shigeru Hanada wrote: > (2011/12/13 22:00), Etsuro Fujita wrote: >> Thank you for your effectiveness experiments and proposals for >> improvements. I updated the patch according to your proposals. >> Attached is the updated version of the patch. > > I think this patch could be

Re: [HACKERS] unite recovery.conf and postgresql.conf

Greg, > Put the stuff you used to insert into recovery.conf into postgresql.conf > instead. If you don't like that, use another file and include it with > one of the multiple options for that--same migration option I already > suggested. Run "pg_ctl recovery"; under the hood that's actually > cr

Re: [HACKERS] unite recovery.conf and postgresql.conf

On 12/14/2011 04:57 PM, Josh Berkus wrote: How will things work for PITR? Left that out mainly because I was already running too long there, but I do think there's a reasonable path. There is one additional wrinkle in there to consider that I've thought of so far, falling into the "what is

Re: [HACKERS] unite recovery.conf and postgresql.conf

On 12/14/2011 04:47 PM, Magnus Hagander wrote: You say "the server can just delete it". But how will this work if the file is *not* in the data directory? If you are on a Debian style system for example, where all these files go in /etc/postgresql - wouldn't that suddenly require the postgres use

Re: [HACKERS] Command Triggers

Robert Haas writes: >> I can get behind this argument: force all stuff through ProcessUtility >> for regularity, and not necessarily in the first patch for this feature. > > That seems like a pretty heavy dependency on an implementation detail > that we might want to change at some point. Given P

Re: [HACKERS] unite recovery.conf and postgresql.conf

On 12/14/11 1:16 PM, Greg Smith wrote: > > -Creating a standby.enabled file in the directory that houses the > postgresql.conf (same logic as "include" uses to locate things) puts the > system into recovery mode. That feature needs to save some state, and > making those decisions based on existen

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Wed, Dec 14, 2011 at 22:16, Greg Smith wrote: > I've submitted two patches for adding new include features to the > postgresql.conf file.  While not quite commit quality yet, I hope everyone > will agree their reviews this week suggest both are close enough that any > number of people could fin

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Wed, Dec 14, 2011 at 4:16 PM, Greg Smith wrote: > [ plan for deprecating recovery.conf ] +1. I'd be very happy with this plan. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) T

Re: [HACKERS] Command Triggers

On Wed, Dec 14, 2011 at 9:05 AM, Alvaro Herrera wrote: > Excerpts from Dimitri Fontaine's message of mié dic 14 07:22:21 -0300 2011: >> Again, that's a caveat of the first implementation, you can't have sub >> commands support without forcing them through ProcessUtility and that's >> a much more i

Re: [HACKERS] unite recovery.conf and postgresql.conf

I've submitted two patches for adding new include features to the postgresql.conf file. While not quite commit quality yet, I hope everyone will agree their reviews this week suggest both are close enough that any number of people could finish them off. Before re-opening this can of worms, I

Re: [HACKERS] review: CHECK FUNCTION statement

Hello so removed "quite" option and removed multiple check regression tests also - there is missing explicit order of function checking, so regress tests can fail :( Regards Pavel 2011/12/14 Albe Laurenz : > Pavel Stehule wrote: >> changes: >> >> * fixed warnings >> * support for options - act

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

On 12/14/2011 03:09 PM, Tom Lane wrote: Andrew Dunstan writes: + # Disable FP optimizations that cause isinf errors on gcc 4.5+ + PGAC_PROG_CC_CFLAGS_OPT([-fexcess-precision=standard]) Looks sane to me, except "isinf errors" is an awfully narrow reading of the problem. Maybe jus

Re: [HACKERS] SP-GiST versus index-only scans

Jesper Krogh writes: > On 2011-12-14 19:48, Tom Lane wrote: >> I think this is somewhat wishful thinking unfortunately. The difficulty >> is that if the index isn't capable of reconstructing the original value, >> then it's probably giving only an approximate (lossy) answer, which >> means we'll

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

Andrew Dunstan writes: > + # Disable FP optimizations that cause isinf errors on gcc 4.5+ > + PGAC_PROG_CC_CFLAGS_OPT([-fexcess-precision=standard]) Looks sane to me, except "isinf errors" is an awfully narrow reading of the problem. Maybe just say "assorted errors"? Also, do we know

Re: [HACKERS] SP-GiST versus index-only scans

On 2011-12-14 19:48, Tom Lane wrote: Jesper Krogh writes: On 2011-12-14 19:00, Tom Lane wrote: So the problem is that we have to either disallow such opclass designs, or support per-opclass rather than per-index-AM decisions about whether index-only scans are possible. Just a quick comment, f

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

On 12/14/2011 11:14 AM, Tom Lane wrote: -ffloat-store is a brute force solution, I think, and would affect old versions of gcc that don't exhibit any problems. I would suggest altering configure to see whether the compiler recognizes -fexcess-precision=standard and adding that to CFLAGS if so.

Re: [HACKERS] Race condition in HEAD, possibly due to PGPROC splitup

On Wed, Dec 14, 2011 at 3:20 PM, Tom Lane wrote: > Pavan Deolasee writes: >> Looking at CommitTransaction(), it seems quite clear to me that we >> call ProcArrayEndTransaction() before releasing the locks held by the >> transaction. So its quite possible that when >> GetRunningTransactionLocks go

Re: [HACKERS] SP-GiST versus index-only scans

Jesper Krogh writes: > On 2011-12-14 19:00, Tom Lane wrote: >> So the problem is that we have to either disallow such opclass designs, >> or support per-opclass rather than per-index-AM decisions about whether >> index-only scans are possible. > Just a quick comment, for some queries like the fam

Re: [HACKERS] SP-GiST versus index-only scans

On 2011-12-14 19:00, Tom Lane wrote: So the problem is that we have to either disallow such opclass designs, or support per-opclass rather than per-index-AM decisions about whether index-only scans are possible. Just a quick comment, for some queries like the famous select count(*) from table w

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

Robert Haas writes: > Uh, wow. That really is pretty insane. How is anyone supposed to > write sensible code around that non-API? Usability seems to be very low on the gcc project's list of goals these days. Personally I think this sort of thing might be fine if it were triggered by -ffast-mat

[HACKERS] SP-GiST versus index-only scans

It would not take very much at all to make the SP-GiST stuff support index-only scans, except for one thing: it's conceivable that an opclass might choose to store only a lossy version of the original indexed datum, in which case it'd not be able to reconstruct the datum on demand. I'm not sure ho

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

On Wed, Dec 14, 2011 at 12:36 PM, Tom Lane wrote: > AFAICS it's really impractical to do that.  The code Andrew is having > problems with is essentially > >        double a,b,c; >        ... >        a = b * c; >        if (isinf(a)) throw error; > > and the problem is that the multiplication resu

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

Robert Haas writes: > On Wed, Dec 14, 2011 at 11:14 AM, Tom Lane wrote: >> -ffloat-store is a brute force solution, I think, and would affect old >> versions of gcc that don't exhibit any problems. I would suggest >> altering configure to see whether the compiler recognizes >> -fexcess-precision

[HACKERS] VACUUM in SP-GiST

I started reading the spgist vacuum code last night, and didn't like it at all. I found a number of smaller issues, but it seems to me that the design is just fundamentally wrong. Unless I'm misunderstanding it, the approach is to recursively traverse the tree in sort of the same way that a full-

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

On Wed, Dec 14, 2011 at 11:14 AM, Tom Lane wrote: > -ffloat-store is a brute force solution, I think, and would affect old > versions of gcc that don't exhibit any problems.  I would suggest > altering configure to see whether the compiler recognizes > -fexcess-precision=standard and adding that t

Re: [HACKERS] pg_dump --exclude-table-data

On Dec 14, 2011, at 6:31 AM, Andrew Dunstan wrote: > Thanks. Committed with that changed, although we seem to be getting > altogether too obsessive about white space, IMNSHO. If that’s all there is to complain about, I think it’s a pretty good sign. ;-P David -- Sent via pgsql-hackers mailin

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

Andrew Dunstan writes: >>> Done and done (see >>> ). >>> >> Did you see Kai's update on the ticket? If this is the case, I know >> that we have seen similar bugs with PostGIS and the work-around has >> been

Re: [HACKERS] NOTIFY with tuples

On 14 December 2011 15:10, Merlin Moncure wrote: > As to the wider point I'm wondering why you can't layer your API on > top of existing facilities (tables, notifications, etc). PGQ (have you > seen that?) does this and it's an absolute marvel.  Meaning, I bet you > could do this with an 'all sql

Re: [HACKERS] [REVIEW] pg_last_xact_insert_timestamp

On Mon, Dec 12, 2011 at 12:17 PM, Simon Riggs wrote: > On Sat, Dec 10, 2011 at 12:29 PM, Greg Smith wrote: > >> "We can send regular special messages from WALSender to WALReceiver that do >> not form part of the WAL stream, so we don't bulk >> up WAL archives. (i.e. don't use "w" messages)." >> >

Re: [HACKERS] psql output locations

On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander wrote: >>> * There are a number of things that are always written to stdout, that >>> there is no way to redirect. In some cases it's interactive prompts - >>> makes sense - but also for example the output of \timing goes to >>> stdout always. Is th

Re: [HACKERS] foreign key locks, 2nd attempt

Noah Misch writes: > On Tue, Dec 13, 2011 at 06:36:21PM -0300, Alvaro Herrera wrote: >> Yeah, I've been wondering about this: do we have a problem already with >> exclusion constraints? I mean, if a concurrent inserter doesn't see the >> tuple that we've marked here as deleted while we toast it,

Re: [HACKERS] review: CHECK FUNCTION statement

Pavel Stehule wrote: > changes: > > * fixed warnings > * support for options - actually only two options are supported - > quite and fatal_errors > > these options are +/- useful - main reason for their existence is > testing of support of options - processing on CHECK ... stmt side and > proces

Re: [HACKERS] foreign key locks, 2nd attempt

On Tue, Dec 13, 2011 at 06:36:21PM -0300, Alvaro Herrera wrote: > Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011: > > > @@ -2725,11 +2884,20 @@ l2: > > > oldtup.t_data->t_infomask &= ~(HEAP_XMAX_COMMITTED | > > > HEAP_XMAX_INVA

Re: [HACKERS] Race condition in HEAD, possibly due to PGPROC splitup

Pavan Deolasee writes: > Looking at CommitTransaction(), it seems quite clear to me that we > call ProcArrayEndTransaction() before releasing the locks held by the > transaction. So its quite possible that when > GetRunningTransactionLocks goes through the list of currently held > locks, the pgxac

Re: [HACKERS] Race condition in HEAD, possibly due to PGPROC splitup

Pavan Deolasee writes: > BTW, on an unrelated note, I was looking at the way ShmemInitStruct() > is used. It internally uses ShmemAlloc to allocate from shared memory. > ShmemAlloc always MAXALIGN the requested size. But while calculating > the total shared memory requirement, we don't always MAXA

Re: [HACKERS] Patch to allow users to kill their own queries

Magnus Hagander writes: > On Tue, Dec 13, 2011 at 11:59, Greg Smith wrote: >> HINT: you can use pg_cancel_backend() on your own processes > That HINT sounds a bit weird to me. "you can cancel your own queries > using pg_cancel_backend() instead" or something like that? Doesn't follow message s

Re: [HACKERS] NOTIFY with tuples

On Tue, Dec 13, 2011 at 11:27 PM, Thomas Munro wrote: >> Actually, what I'd suggest is just some code to serialize and >> deserialize tuples and transmit 'em via the existing NOTIFY payload >> facility.  I agree that presenting it as some functions would be a lot >> less work than inventing bespok

Re: [HACKERS] LibreOffice driver 1: Building libpq with Mozilla LDAP instead of OpenLDAP

Pavel Golub writes: > You wrote: > TL> about OSX though. (You're aware that Apple ships a perfectly fine > TL> libpq.so in Lion, no?) > Is it true? Really? Where can we read about it? /Library/WebServer/Documents/postgresql/html ... I don't know where else Apple documents this, but there's a c

Re: [HACKERS] WIP: URI connection string support for libpq

Excerpts from Greg Smith's message of Wed Dec 14 02:54:14 +0200 2011: > > Initial quick review of your patch: you suggested this as the general form: > > psql -d postgresql://user@pw:host:port/dbname?param1=value1¶m2=value2... > > That's presumably supposed to be: > > psql -d postgresql://use

Re: [HACKERS] pg_dump --exclude-table-data

On 14 December 2011 14:31, Andrew Dunstan wrote: > Thanks. Committed with that changed, although we seem to be getting > altogether too obsessive about white space, IMNSHO. I agree, but I think it's important that we judge patches by a consistent standard. Right now, for better or worse, that st

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

On 14/12/11 13:59, Andrew Dunstan wrote: Hmm. Yeah, if I remove -O0 and instead set CFLAGS to -ffloat-store the error goes away. So, would we want to use that just for this file, or for the whole build? Well the latest documentation for gcc gives 2 options: -ffloat-store and -fexcess-precisi

Re: [HACKERS] pg_dump --exclude-table-data

On 12/14/2011 06:28 AM, Peter Geoghegan wrote: Not sure that I have a lot to add here, but I am officially listed as a reviewer, which is a responsibility that I don't want to shirk. In my opinion, this patch is obviously useful. I don't find the asymmetry that it will create with pg_restore t

Re: [HACKERS] Command Triggers

Excerpts from Dimitri Fontaine's message of mié dic 14 07:22:21 -0300 2011: > Again, that's a caveat of the first implementation, you can't have sub > commands support without forcing them through ProcessUtility and that's > a much more invasive patch. Maybe we will need that later. I can get b

Re: [HACKERS] COUNT(*) and index-only scans

On Wed, Dec 14, 2011 at 6:58 AM, Greg Stark wrote: > On Mon, Nov 21, 2011 at 6:43 PM, Robert Haas wrote: >> In buffer fill mode, we scan the index and add matching tuples and >> their CTIDs to the buffer.  When the buffer is full or the index AM >> reports that there are no more tuples in the sca

Re: [HACKERS] Patch to allow users to kill their own queries

On 12/14/2011 05:24 AM, Magnus Hagander wrote: How about passing a parameter to pg_signal_backend? Making pg_signal_backend(int pid, int sig, bool allow_samerole)? That sounds like it will result in less code, and make the API I was documenting be obvious from the parameters instead. I'll

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

On 12/14/2011 04:43 AM, Mark Cave-Ayland wrote: On 12/12/11 15:00, Andrew Dunstan wrote: Yeah, fair enough. I'll work on that. If we're talking about adding support for a previously-unsupported Definitely do this (and then file a bug report with the project). I've worked with both Kai and N

Re: [HACKERS] [REVIEW] Patch for cursor calling with named parameters

On 14.12.2011 12:31, Yeb Havinga wrote: On 2011-12-13 18:34, Tom Lane wrote: Heikki Linnakangas writes: Attached is a patch with those changes. I also I removed a few of the syntax error regression tests, that seemed excessive, plus some general naming and comment fiddling. I'll apply this tomo

Re: [HACKERS] Race condition in HEAD, possibly due to PGPROC splitup

On Wed, Dec 14, 2011 at 12:20 PM, Pavan Deolasee wrote: > On Wed, Dec 14, 2011 at 4:15 AM, Tom Lane wrote: > >> >> Without the added assert, you'd only notice this if you were running a >> standby slave --- the zero xid results in an assert failure in WAL >> replay on the slave end, which is how

Re: [HACKERS] Race condition in HEAD, possibly due to PGPROC splitup

On Wed, Dec 14, 2011 at 4:15 AM, Tom Lane wrote: > > Without the added assert, you'd only notice this if you were running a > standby slave --- the zero xid results in an assert failure in WAL > replay on the slave end, which is how I found out about this to start > with.  But since we've not hea

Re: [HACKERS] COUNT(*) and index-only scans

On Mon, Nov 21, 2011 at 6:43 PM, Robert Haas wrote: > In buffer fill mode, we scan the index and add matching tuples and > their CTIDs to the buffer.  When the buffer is full or the index AM > reports that there are no more tuples in the scan, we switch to buffer > drain mode. Instead you could d

Re: [HACKERS] pg_dump --exclude-table-data

Not sure that I have a lot to add here, but I am officially listed as a reviewer, which is a responsibility that I don't want to shirk. In my opinion, this patch is obviously useful. I don't find the asymmetry that it will create with pg_restore to be troubling, so I'd favour committing it as-is.

Re: [HACKERS] Command Triggers

Jan Wieck writes: > I agree. While it is one of the most "asked for" features among the trigger > based replication systems, I fear that an incomplete solution will cause > more problems than it solves. It is far easier to tell people "DDL doesn't > propagate automatically, do this instead ..." th

Re: [HACKERS] Command Triggers

Christopher Browne writes: > - What I'd much rather have is a form of the query that is replete > with Full Qualification, so that "create table foo (id serial primary > key, data text not null unique default 'better replace this', dns_data > dnsrr not null);" may be transformed into a safer form

Re: [HACKERS] [REVIEW] Patch for cursor calling with named parameters

On 2011-12-13 18:34, Tom Lane wrote: Heikki Linnakangas writes: Attached is a patch with those changes. I also I removed a few of the syntax error regression tests, that seemed excessive, plus some general naming and comment fiddling. I'll apply this tomorrow, if it still looks good to me after

Re: [HACKERS] Patch to allow users to kill their own queries

On Tue, Dec 13, 2011 at 11:59, Greg Smith wrote: > The submission from Edward Muller I'm replying to is quite similar to what > the other raging discussion here decided was the right level to target. >  There was one last year from Josh Kupershmidt with similar goals: >  http://archives.postgresql

Re: [HACKERS] Command Triggers

Robert Haas writes: > it. Dimitri says that he wants it so that we can add support for > CREATE TABLE, ALTER TABLE, and DROP TABLE to Slony, Bucardo, and > Londiste. My fear is that it won't turn out to be adequate to that > task, because there won't actually be enough information in the CREATE

Re: [HACKERS] psql output locations

On Mon, Dec 12, 2011 at 21:04, Peter Eisentraut wrote: > On mån, 2011-12-12 at 14:47 +0100, Magnus Hagander wrote: >> We're either pretty inconsistent with our output in psql, or I'm not >> completely understanding it.. I was trying to implement a switch that >> would let me put all the output in

Re: [HACKERS] WIP: URI connection string support for libpq

On Tue, Dec 13, 2011 at 07:54:14PM -0500, Greg Smith wrote: > After this bit of tinkering with the code, it feels to me like this > really wants a split() function to break out the two sides of a > string across a delimiter, eating it in the process. Adding the > level of paranoia I'd like around

Re: [HACKERS] NOTIFY with tuples

On Dec 13, 2011, at 8:21 PM, Tom Lane wrote: >> I'm not sure whether we'd want something like this in core, so for a >> first go-around, you might want to consider building it as an >> extension. ... I'm not sure you >> need NOTIFY for anything anywhere in here. > > Actually, what I'd suggest is