Re: [HACKERS] POLA violation with \c service=

David Fetter wrote: > I've noticed that psql's \c function handles service= requests in a > way that I can only characterize as broken. > > This came up in the context of connecting to a cloud hosting service > named after warriors or a river or something, whose default hostnames > are long, conf

Re: [HACKERS] Logical Decoding follows timelines

On 16 December 2014 at 21:17, Simon Riggs wrote: >>> This patch is a WIP version of doing that, but only currently attempts >> With the patch, XLogSendLogical uses the same logic to calculate SendRqstPtr >> that XLogSendPhysical does. It would be good to refactor that into a common >> function,

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 15 December 2014 at 20:26, Jeff Janes wrote: > I still get the compiler error in contrib: > > pgstattuple.c: In function 'pgstat_heap': > pgstattuple.c:279: error: too few arguments to function > 'heap_beginscan_strat' > > Should it pass false for the always_prune? Yes. New version attached.

Re: [HACKERS] POLA violation with \c service=

On 12/17/2014 10:03 AM, Albe Laurenz wrote: David Fetter wrote: I've noticed that psql's \c function handles service= requests in a way that I can only characterize as broken. This came up in the context of connecting to a cloud hosting service named after warriors or a river or something, who

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 16 December 2014 at 21:45, Stephen Frost wrote: > * Simon Riggs (si...@2ndquadrant.com) wrote: >> On 16 December 2014 at 18:28, Stephen Frost wrote: >> >> > For the sake of the archives, the idea I had been trying to propose is >> > to use a role's permissions as a mechanism to define what sho

[HACKERS] Combining Aggregates

KaiGai, David Rowley and myself have all made mention of various ways we could optimize aggregates. Following WIP patch adds an extra function called a "combining function", that is intended to allow the user to specify a semantically correct way of breaking down an aggregate into multiple steps.

Re: [HACKERS] Combining Aggregates

On Wed, Dec 17, 2014 at 3:23 PM, Simon Riggs wrote: > > KaiGai, David Rowley and myself have all made mention of various ways > we could optimize aggregates. > > Following WIP patch adds an extra function called a "combining > function", that is intended to allow the user to specify a > semantical

Re: [HACKERS] Combining Aggregates

On 17/12/14 11:02, Atri Sharma wrote: On Wed, Dec 17, 2014 at 3:23 PM, Simon Riggs mailto:si...@2ndquadrant.com>> wrote: KaiGai, David Rowley and myself have all made mention of various ways we could optimize aggregates. Following WIP patch adds an extra function called a "combini

Re: [HACKERS] Some modes of vcregress not mentioned in MSVC scripts

Applied, thanks. Also backpatched to 9.4 so the docs changes go into the /current/ docs (or what will be current later this week). //Magnus On Tue, Dec 16, 2014 at 7:10 AM, Michael Paquier wrote: > > Hi all, > > While looking at the Windows docs and the MSVC scripts, I noticed that > the follow

Re: [HACKERS] Combining Aggregates

On 17 December 2014 at 10:02, Atri Sharma wrote: > > > On Wed, Dec 17, 2014 at 3:23 PM, Simon Riggs wrote: >> >> KaiGai, David Rowley and myself have all made mention of various ways >> we could optimize aggregates. >> >> Following WIP patch adds an extra function called a "combining >> function"

Re: [HACKERS] Combining Aggregates

On 17 December 2014 at 22:53, Simon Riggs wrote: > > KaiGai, David Rowley and myself have all made mention of various ways > we could optimize aggregates. > > Following WIP patch adds an extra function called a "combining > function", that is intended to allow the user to specify a > semantically

Re: [HACKERS] analyze_new_cluster.bat and delete_old_cluster.bat not ignored with vcregress upgradecheck

On Tue, Dec 16, 2014 at 7:25 AM, Michael Paquier wrote: > > Hi all, > > As mentioned in $subject, I noticed that those automatically-generated > files are not ignored in the tree when running vcregress on Windows, > we do ignore their .sh version though. I think that it would be good > to back-pat

Re: [HACKERS] WALWriter active during recovery

Hi, On Tue, Dec 16, 2014 at 6:07 PM, Simon Riggs wrote: > On 16 December 2014 at 14:12, Heikki Linnakangas > wrote: >> On 12/15/2014 08:51 PM, Simon Riggs wrote: >>> >>> Currently, WALReceiver writes and fsyncs data it receives. Clearly, >>> while we are waiting for an fsync we aren't doing any

Re: [HACKERS] speedup tidbitmap patch: cache page

On 17 December 2014 at 05:25, Teodor Sigaev wrote: > > I've been having a look at this and I'm wondering about a certain scenario: >> >> In tbm_add_tuples, if tbm_page_is_lossy() returns true for a given block, >> and on >> the next iteration of the loop we have the same block again, have you >> b

Re: [HACKERS] Combining Aggregates

On 17 December 2014 at 10:20, David Rowley wrote: > On 17 December 2014 at 22:53, Simon Riggs wrote: >> >> KaiGai, David Rowley and myself have all made mention of various ways >> we could optimize aggregates. >> >> Following WIP patch adds an extra function called a "combining >> function", that

Re: [HACKERS] Combining Aggregates

Simon, Its concept is good to me. I think, the new combined function should be responsible to take a state data type as argument and update state object of the aggregate function. In other words, combined function performs like transition function but can update state object according to the summa

Re: [HACKERS] speedup tidbitmap patch: hash BlockNumber

-hash_ctl.hash = oid_hash; /* a bit more efficient than tag_hash */ +hash_ctl.hash = tag_hash; /* a bit more efficient than tag_hash */ I think the comment may need removed here. Thank you, fixed -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: [HACKERS] WALWriter active during recovery

On 17 December 2014 at 11:27, didier wrote: > If there's a fsync in progress WALReceiver will: > 1- slow the fsync because its writes to the same file are grabbed by the fsync > 2- stall until the end of fsync. PostgreSQL already fsyncs files while they are being written to. Are you saying we sh

Re: [alvhe...@2ndquadrant.com: Re: [HACKERS] no test programs in contrib]

Michael Paquier wrote: > On Wed, Dec 17, 2014 at 6:02 AM, Alvaro Herrera > wrote: > > > > Andrew Dunstan wrote: > > > Any brave buildfarm owners on *nix can try it by replacing their copy of > > > run_build.pl with the bleeding edge version. We can't put it in a client > > > release until we fix

[HACKERS] postgres messages error

Hi there, I was doing some translation on postgres.po and found a string which looks mistaken. #: libpq/auth.c:1593 #, fuzzy, c-format msgid "could not to look up local user ID %ld: %s" It looks like there is an extra *to* there , so the string should be: "could not look up local user ID %ld: %

Re: [HACKERS] POLA violation with \c service=

On 12/17/2014 04:11 AM, Heikki Linnakangas wrote: On 12/17/2014 10:03 AM, Albe Laurenz wrote: David Fetter wrote: I've noticed that psql's \c function handles service= requests in a way that I can only characterize as broken. This came up in the context of connecting to a cloud hosting servi

Re: [HACKERS] Combining Aggregates

On Wed, Dec 17, 2014 at 6:05 PM, Kouhei Kaigai wrote: > > Simon, > > Its concept is good to me. I think, the new combined function should be > responsible to take a state data type as argument and update state object > of the aggregate function. In other words, combined function performs like > tr

Re: [HACKERS] WALWriter active during recovery

didier wrote: > On many Linux systems it may not do that much (2.6.32 and 3.2 are bad, > 3.13 is better but still it slows the fsync). > > If there's a fsync in progress WALReceiver will: > 1- slow the fsync because its writes to the same file are grabbed by the fsync > 2- stall until the end of

[HACKERS] exitArchiveRecovery woes

At the end of archive recovery, we copy the last segment from the old timeline, to initialize the first segment on the new timeline. For example, if the timeline switch happens in the middle of WAL segment 00010005, the whole 00010005 segment is copied to become

Re: [HACKERS] Combining Aggregates

On 17 December 2014 at 12:35, Kouhei Kaigai wrote: > Its concept is good to me. I think, the new combined function should be > responsible to take a state data type as argument and update state object > of the aggregate function. In other words, combined function performs like > transition functi

Re: [HACKERS] GiST kNN search queue (Re: KNN-GiST with recheck)

On 12/15/2014 03:14 PM, Andres Freund wrote: If we add another heap implementation we probably should at least hint at the different advantages somewhere. How about adding a src/backend/lib/README for that, per attached? - Heikki diff --git a/src/backend/lib/Makefile b/src/backend/lib/Makefil

Re: [HACKERS] Combining Aggregates

On Wed, Dec 17, 2014 at 7:18 PM, Simon Riggs wrote: > > On 17 December 2014 at 12:35, Kouhei Kaigai wrote: > > > Its concept is good to me. I think, the new combined function should be > > responsible to take a state data type as argument and update state object > > of the aggregate function. In

Re: [HACKERS] parallel mode and parallel contexts

On 12 December 2014 at 22:52, Robert Haas wrote: > I would be remiss if I failed to mention that this patch includes work > by my colleagues Amit Kapila, Rushabh Lathia, and Jeevan Chalke, as > well as my former colleague Noah Misch; and that it would not have > been possible without the patient

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

Alvaro Herrera writes: > >> Even with the current approach of checking the stats after every >> isolated case it's sometimes takes quite a little more than a glance >> to verify correctness due to side-effects of rollback (ins/upd/del >> counters are still updated), and the way stats are affecting

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

Hello, >Patches as well as results are attached. I had a look at code. I have few minor points, + bkpb.fork_flags |= BKPBLOCK_HAS_IMAGE; + + if (is_compressed) { - rdt_datas_last->data = page; - rdt_datas_last->len = BLCKSZ; +

Re: [HACKERS] Reducing lock strength of adding foreign keys

On 25 October 2014 19:00, Noah Misch wrote: >> So I tentatively propose (and with due regard for the possibility >> others may see dangers that I've missed) that a reasonable goal would >> be to lower the lock strength required for both CREATE TRIGGER and ADD >> FOREIGN KEY from AccessExclusiveLo

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

Alex Shulgin wrote: > OK, I think I have now all bases covered, though the updated patch is > not that "pretty". > > The problem is that we don't know in advance if the (sub)transaction is > going to succeed or abort, and in case of aborted truncate we need to > use the stats gathered prior to tr

Re: [alvhe...@2ndquadrant.com: Re: [HACKERS] no test programs in contrib]

Andrew Dunstan writes: > On 12/16/2014 04:44 PM, Tom Lane wrote: >> I've put this in dromedary as well (though the HEAD build that's running >> right this moment is still using the 4.13 script). I take it I don't need >> to adjust the configuration file? > Nope, no config changes required. As s

Re: [HACKERS] POLA violation with \c service=

On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote: > > On 12/17/2014 04:11 AM, Heikki Linnakangas wrote: > >On 12/17/2014 10:03 AM, Albe Laurenz wrote: > >>David Fetter wrote: > >>>I've noticed that psql's \c function handles service= requests in a > >>>way that I can only characteri

Re: [HACKERS] [PATCH] explain sortorder

On 12/15/2014 06:49 PM, Mike Blackwell wrote: QUERY PLAN Sort Output: n1, n2, ((n1)::character(1)) Sort Key: sortordertest.n1, sortordertest.n2 Sort Order: ASC NULLS LAST, ASC NULLS LAST -> Seq Scan on publi

Re: [HACKERS] [PATCH] explain sortorder

Heikki Linnakangas writes: > I would suggest just adding the information to the Sort Key line. As > long as you don't print the modifiers when they are defaults (ASC and > NULLS LAST), we could print the information even in non-VERBOSE mode. +1. I had assumed without looking that that was what

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

Alvaro Herrera writes: > Alex Shulgin wrote: > >> OK, I think I have now all bases covered, though the updated patch is >> not that "pretty". >> >> The problem is that we don't know in advance if the (sub)transaction is >> going to succeed or abort, and in case of aborted truncate we need to >>

Re: [HACKERS] WALWriter active during recovery

Hi On Wed, Dec 17, 2014 at 2:39 PM, Alvaro Herrera wrote: > didier wrote: > >> On many Linux systems it may not do that much (2.6.32 and 3.2 are bad, >> 3.13 is better but still it slows the fsync). >> >> If there's a fsync in progress WALReceiver will: >> 1- slow the fsync because its writes to

Re: [HACKERS] speedup tidbitmap patch: cache page

You could well be right, but it would be good to compare the numbers just so we know this for sure. I wasn't right :( # set work_mem='64kB'; # set enable_seqscan = off; Patched: 1194.094 ms Master: 1765.338 ms > Are you seeing the same? Fixed too, the mistake was in supposition that current p

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 12/01/2014 08:55 PM, Jim Nasby wrote: On 12/1/14, 11:57 AM, Andres Freund wrote: On 2014-11-30 20:46:51 -0600, Jim Nasby wrote: On 11/10/14, 7:52 PM, Tom Lane wrote: On the whole, I'm +1 for just logging the events and seeing what we learn that way. That seems like an appropriate amount of

Re: [alvhe...@2ndquadrant.com: Re: [HACKERS] no test programs in contrib]

On 12/17/2014 10:23 AM, Tom Lane wrote: Andrew Dunstan writes: On 12/16/2014 04:44 PM, Tom Lane wrote: I've put this in dromedary as well (though the HEAD build that's running right this moment is still using the 4.13 script). I take it I don't need to adjust the configuration file? Nope, n

Re: [HACKERS] DROP PRIVILEGES OWNED BY

On 12/15/2014 02:43 AM, Marko Tiikkaja wrote: This week I had a problem where I wanted to drop only the privileges a certain role had in the system, while keeping all the objects. I couldn't figure out a reasonable way to do that, so I've attached a patch for this to this email. Please consider

Re: [HACKERS] DROP PRIVILEGES OWNED BY

On 12/17/14 5:37 PM, Heikki Linnakangas wrote: On 12/15/2014 02:43 AM, Marko Tiikkaja wrote: The syntax is: DROP PRIVILEGES OWNED BY role [, ...] DROP seems like the wrong verb here. DROP is used for deleting objects, while REVOKE is used for removing permissions from them. REVOKE alread

Re: [alvhe...@2ndquadrant.com: Re: [HACKERS] no test programs in contrib]

On 12/17/2014 11:34 AM, Andrew Dunstan wrote: On 12/17/2014 10:23 AM, Tom Lane wrote: Andrew Dunstan writes: On 12/16/2014 04:44 PM, Tom Lane wrote: I've put this in dromedary as well (though the HEAD build that's running right this moment is still using the 4.13 script). I take it I don'

Re: [HACKERS] postgres messages error

Martin, #: libpq/auth.c:1593 > #, fuzzy, c-format > msgid "could not to look up local user ID %ld: %s" > > It looks like there is an extra *to* there , so the string should be: > > "could not look up local user ID %ld: %s" > I think you are right. FWIW, I have attached a patch that fixes it for

hash_create API changes (was Re: [HACKERS] speedup tidbitmap patch: hash BlockNumber)

Teodor Sigaev writes: >> -hash_ctl.hash = oid_hash; /* a bit more efficient than tag_hash */ >> +hash_ctl.hash = tag_hash; /* a bit more efficient than tag_hash */ >> >> I think the comment may need removed here. > Thank you, fixed I looked at this patch. It's not right at all here: +

Re: [alvhe...@2ndquadrant.com: Re: [HACKERS] no test programs in contrib]

Andrew Dunstan writes: > On 12/17/2014 11:34 AM, Andrew Dunstan wrote: >> Oh, darn, I thought we had a version check. Will fix. > OK, I have committed a fix. Revised script is at >

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 12/17/14, 10:20 AM, Heikki Linnakangas wrote: * Change the new bit in the errdetail. "could not acquire cleanup lock" sounds too much like an error to me. "skipped %u pinned pages" maybe? Seems reasonable. Well, that's not always true either; when freezing, it doesn't skip the pinned

Re: [HACKERS] postgres messages error

Adam Brightwell writes: > Martin, > #: libpq/auth.c:1593 >> #, fuzzy, c-format >> msgid "could not to look up local user ID %ld: %s" >> >> It looks like there is an extra *to* there , so the string should be: >> >> "could not look up local user ID %ld: %s" > I think you are right. FWIW, I have

Re: [HACKERS] postgres messages error

Tom Lane wrote: > Adam Brightwell writes: > > Martin, > > #: libpq/auth.c:1593 > >> #, fuzzy, c-format > >> msgid "could not to look up local user ID %ld: %s" > >> > >> It looks like there is an extra *to* there , so the string should be: > >> > >> "could not look up local user ID %ld: %s" > >

Re: [HACKERS] postgres messages error

Alvaro Herrera writes: > A quick grep reveals also > initdb.po:msgid "%s: could not to allocate SIDs: error code %lu\n" Good catch, I'll get that one too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your su

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 12/17/2014 08:02 PM, Jim Nasby wrote: BTW, what is it about a dynamic message that makes it untranslatable? Doesn't the translation happen down-stream, so that at most we'd just need two translation messages? I'm not sure what you mean by down-stream. There is some explanation on this in th

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

Jim Nasby wrote: > On 12/17/14, 10:20 AM, Heikki Linnakangas wrote: > >> > >>>* Change the new bit in the errdetail. "could not acquire cleanup lock" > >>>sounds too much like an error to me. "skipped %u pinned pages" maybe? > >> > >>Seems reasonable. > > > >Well, that's not always true either;

Re: [HACKERS] On partitioning

On 12/16/2014 07:35 PM, Robert Haas wrote: > On Tue, Dec 16, 2014 at 9:01 PM, Josh Berkus wrote: >> Anyway, what I'm saying is that I personally regard the inability to >> handle even moderately complex expressions a major failing of our >> existing partitioning scheme (possibly its worst single f

Re: [HACKERS] Combining Aggregates

On 18 December 2014 at 01:31, Simon Riggs wrote: > > On 17 December 2014 at 10:20, David Rowley wrote: > > On 17 December 2014 at 22:53, Simon Riggs wrote: > >> > >> KaiGai, David Rowley and myself have all made mention of various ways > >> we could optimize aggregates. > >> > >> Following WIP p

Re: [HACKERS] Commitfest problems

* Jaime Casanova (ja...@2ndquadrant.com) wrote: > On Tue, Dec 16, 2014 at 11:32 AM, Robert Haas wrote: > > > > It has been proposed that we do a general list of people at the bottom > > of the release notes who helped review during that cycle. That would > > be less intrusive and possibly a good

Re: [alvhe...@2ndquadrant.com: Re: [HACKERS] no test programs in contrib]

On 12/17/2014 01:02 PM, Tom Lane wrote: Andrew Dunstan writes: On 12/17/2014 11:34 AM, Andrew Dunstan wrote: Oh, darn, I thought we had a version check. Will fix. OK, I have committed a fix. Revised script is at

Re: [HACKERS] Combining Aggregates

On 18 December 2014 at 02:48, Simon Riggs wrote: > > On 17 December 2014 at 12:35, Kouhei Kaigai wrote: > > > Its concept is good to me. I think, the new combined function should be > > responsible to take a state data type as argument and update state object > > of the aggregate function. In oth

Re: [HACKERS] btree_gin and ranges

On 10/22/2014 01:55 PM, Teodor Sigaev wrote: Suggested patch adds GIN support contains operator for ranges over scalar column. It allows more effective GIN scan. Currently, queries like SELECT * FROM test_int4 WHERE i <= 1 and i >= 1 will be excuted by GIN with two scans: one is from mines infi

Re: [HACKERS] TABLESAMPLE patch

I noticed that this makes REPEATABLE a reserved keyword, which is currently an unreserved one. Can we avoid that? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-ha

Re: [HACKERS] moving from contrib to bin

I know this is how it currently works, but it looks way too messy to me: + my $pgarchivecleanup = AddSimpleFrontend('pg_archivecleanup'); + my $pgstandby = AddSimpleFrontend('pg_standby'); + my $pgtestfsync = AddSimpleFrontend('pg_test_fsync'); + my $pgtesttiming = AddSimpl

Re: [HACKERS] On partitioning

On 12/17/2014 08:53 PM, Josh Berkus wrote: Last week, I wrote a longish email listing out the common problems users have with our current partitioning as a way of benchmarking the plan for new partitioning. While some people responded to that post, absolutely nobody discussed the list of issues

Re: [HACKERS] On partitioning

On 12/17/2014 11:19 AM, Heikki Linnakangas wrote: > On 12/17/2014 08:53 PM, Josh Berkus wrote: >> Last week, I wrote a longish email listing out the common problems users >> have with our current partitioning as a way of benchmarking the plan for >> new partitioning. While some people responded to

Re: [HACKERS] On partitioning

On Wed, Dec 17, 2014 at 1:53 PM, Josh Berkus wrote: > On 12/16/2014 07:35 PM, Robert Haas wrote: >> On Tue, Dec 16, 2014 at 9:01 PM, Josh Berkus wrote: >>> Anyway, what I'm saying is that I personally regard the inability to >>> handle even moderately complex expressions a major failing of our >>

Re: [HACKERS] parallel mode and parallel contexts

On Wed, Dec 17, 2014 at 9:16 AM, Simon Riggs wrote: > On 12 December 2014 at 22:52, Robert Haas wrote: > >> I would be remiss if I failed to mention that this patch includes work >> by my colleagues Amit Kapila, Rushabh Lathia, and Jeevan Chalke, as >> well as my former colleague Noah Misch; and

Re: [HACKERS] Compiling C++ extensions on MSVC using scripts in src/tools

On 11/27/2014 06:39 AM, Michael Paquier wrote: On Thu, Nov 27, 2014 at 1:40 AM, Tom Lane wrote: Andrew Dunstan writes: This doesn't seem to me to be terribly well expressed (I know it's not your fault, quite possibly it's mine.) Perhaps we should replace [r]?[cyl](pp)? with (c|cpp|

Re: [HACKERS] SSL information view

On 11/19/2014 02:36 PM, Magnus Hagander wrote: + /* Create or attach to the shared SSL status buffers */ + size = mul_size(NAMEDATALEN, MaxBackends); + BackendSslVersionBuffer = (char *) + ShmemInitStruct("Backend SSL Version Buffer", size, &found); + + if (!

Re: [HACKERS] Combining Aggregates

On 17 December 2014 at 19:06, David Rowley wrote: > Standalone calls to the combine/merge functions I don't think would be > testing anything new. Guess its a simple enough API, doesn't really need a specific test. > That's the reason I thought it wasn't really acceptable until we have a use >

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

It looks like we are close to reaching consensus on the syntax. Phew! Thanks for maintaining the wiki pages and the documentation. All of the below is based on those, I haven't looked at the patch itself yet. The one thing that I still feel uneasy about is the Unique Index Inference thing. Per

Re: [HACKERS] inherit support for foreign tables

Etsuro Fujita writes: > Attached are updated patches. Patch fdw-inh-5.patch has been created on > top of patch fdw-chk-5.patch. Patch fdw-chk-5.patch is basically the > same as the previous one fdw-chk-4.patch, but I slightly modified that > one. The changes are the following. > * added to f

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 12/17/2014 01:12 PM, Heikki Linnakangas wrote: > 3. Why is the specification required with ON CONFLICT UPDATE, but not > with ON CONFLICT IGNORE? Well, UPDATE has to know which row to lock, no? IGNORE does not. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Wed, Dec 17, 2014 at 1:12 PM, Heikki Linnakangas wrote: > It looks like we are close to reaching consensus on the syntax. Phew! Thanks > for maintaining the wiki pages and the documentation. All of the below is > based on those, I haven't looked at the patch itself yet. Great, thanks! Yes, I

Re: [HACKERS] moving from contrib to bin

On Thu, Dec 18, 2014 at 4:02 AM, Alvaro Herrera wrote: > > I know this is how it currently works, but it looks way too messy to me: > > + my $pgarchivecleanup = AddSimpleFrontend('pg_archivecleanup'); > + my $pgstandby = AddSimpleFrontend('pg_standby'); > + my $pgtestfsync = AddS

Re: [HACKERS] Compiling C++ extensions on MSVC using scripts in src/tools

On Thu, Dec 18, 2014 at 4:55 AM, Heikki Linnakangas wrote: > If .lp and .ypp files are supposed to be Bison and Flex files with C++ code > in them, it wouldn't work anyway, because the rules elsewhere in the MSVC > scripts just check for /\.y$/) to decide whether to run bison on it. > > I committe

Re: [HACKERS] inherit support for foreign tables

(2014/12/18 7:04), Tom Lane wrote: > Etsuro Fujita writes: >> Attached are updated patches. Patch fdw-inh-5.patch has been created on >> top of patch fdw-chk-5.patch. Patch fdw-chk-5.patch is basically the >> same as the previous one fdw-chk-4.patch, but I slightly modified that >> one. The cha

Re: [HACKERS] no test programs in contrib

On Sat, Nov 29, 2014 at 5:54 AM, Alvaro Herrera wrote: > > I also attach some changes for the MSVC build stuff. I tested it and it > builds fine AFAICT, but it doesn't install because Install.pm wants to > install contrib modules from contrib/ (which seems reasonable) but my > hack adds the src/t

Re: [HACKERS] Combining Aggregates

Hi Atri, > So are you proposing not calling transfuncs at all and just use combined > functions? > No. It is discretion of software component that distribute an aggregate into multiple partial-aggregates. > That sounds counterintuitive to me. I am not able to see why you would want > to avoid tr

[HACKERS] Minor improvement to explain.c

Hi, The attached patch just removes one bad-looking blank line in the comments at the top of a function in explain.c. Thanks, Best regards, Etsuro Fujita diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c index 332f04a..064f880 100644 --- a/src/backend/commands/explain.

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Wed, Dec 17, 2014 at 1:34 AM, Michael Paquier wrote: > > > On Wed, Dec 17, 2014 at 12:00 AM, Michael Paquier > wrote: >> >> Actually, the original length of the compressed block in saved in >> PGLZ_Header, so if we are fine to not check the size of the block >> decompressed when decoding WAL w

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Thu, Dec 18, 2014 at 1:05 PM, Fujii Masao wrote: > On Wed, Dec 17, 2014 at 1:34 AM, Michael Paquier > wrote: > I think that neither pg_control nor xl_parameter_change need to have the info > about WAL compression because each backup block has that entry. > > Will review the remaining part late

Re: [HACKERS] NUMERIC private methods?

> "Tom" == Tom Lane writes: >> Hmm. You'd want to make add_var, mul_var etc. non-static? Tom> -1 for that. possibly with more meaningful names. Tom> If you're concerned about arithmetic performance, there is a Tom> very obvious fix here: use double. Independently of this specific exam

Re: [HACKERS] TABLESAMPLE patch

On 17/12/14 19:55, Alvaro Herrera wrote: I noticed that this makes REPEATABLE a reserved keyword, which is currently an unreserved one. Can we avoid that? I added it because I did not find any other way to fix the shift/reduce conflicts that bison complained about. I am no bison expert thoug

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Wed, Dec 17, 2014 at 11:33 PM, Rahila Syed wrote: > I had a look at code. I have few minor points, > Thanks! + bkpb.fork_flags |= BKPBLOCK_HAS_IMAGE; > + > + if (is_compressed) > { > - rdt_datas_last->data = page; > - rdt_datas_last-

Re: [HACKERS] Async execution of postgres_fdw.

Hi Horiguchi-san, Here are my comments for the patches together Sanity 1. The patch applies cleanly but has trailing white spaces. [ashutosh@ubuntu coderoot]git apply /mnt/hgfs/tmp/0001-Async-exec-of-postgres_fdw.patch /mnt/hgfs/tmp/0001-Async-exec-of-postgres_fdw.patch:41: trailing whitespace.

Re: [HACKERS] pg_regress writes into source tree

Hi, On 2014-12-11 22:02:26 -0500, Peter Eisentraut wrote: > When using a vpath build pg_regress writes the processed input/*.source > files into the *source* tree, which isn't supposed to happen. > > This appears to be a thinko introduced in this patch: > e3fc4a97bc8ee82a78605b5ffe79bd4cf3c6213b