Re: [HACKERS] Dockerfile for testing with Perl 5.8.8

On 3 March 2016 at 13:08, Craig Ringer wrote: > On 3 March 2016 at 11:06, Craig Ringer wrote: > >> Hi all >> >> I've prepared a Dockerfile that produces a canned Perl 5.8.8 environment >> based on CentOS 5 on any host with Docker. It has ccache

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Mar 2, 2016 at 7:33 PM, Alvaro Herrera wrote: > Shulgin, Oleksandr wrote: > > > Alright. I'm attaching the latest version of this patch split in two > > parts: the first one is NULLs-related bugfix and the second is the > > "improvement" part, which applies on

Re: [HACKERS] Confusing with commit time usage in logical decoding

On 2016-03-01 18:31:42 +0100, Petr Jelinek wrote: > On 01/03/16 18:18, Andres Freund wrote: > >I'd rather just initialize commit_time to parsed->xact_time. > > > >This indeed is clearly a bug. I do wonder if anybody has a good idea > >about how to add regression tests for this? It's rather

Re: [HACKERS] Re: redo failed in physical streaming replication while stopping the master server

On Wed, Mar 2, 2016 at 4:25 PM, wcting wrote: > /* > * If at page start, we must skip over the page header. But > we can't > * do that until we've read in the page, since the header > size is > * variable. >

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 3 March 2016 at 13:23, Michael Paquier wrote: > On Thu, Mar 3, 2016 at 2:20 PM, Craig Ringer > wrote: > > On the Perl 5.8.8 test env I've set up now, per > > > > >

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Thu, Mar 3, 2016 at 3:34 PM, Michael Paquier wrote: > That's one of my concerns about this patch now: it is trying to do too > much. I think that there is definitely a need for both things: > applications may be fine to pay the lagging price when remote_apply is >

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Tue, Mar 1, 2016 at 11:53 AM, Thomas Munro wrote: > On Tue, Mar 1, 2016 at 2:46 PM, Amit Langote > wrote: >> >> Hi, >> >> On 2016/02/29 18:05, Thomas Munro wrote: >>> On Mon, Feb 29, 2016 at 9:05 PM, Amit Langote wrote: +

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Noah Misch writes: > I've modified buildfarm member mandrill to use force_parallel_mode=regress and > max_parallel_degree=5; a full run passes. We'll now see if it intermittently > fails the stats test, like Tom witnessed: >

Re: [HACKERS] Freeze avoidance of very large table.

At Wed, 2 Mar 2016 17:57:27 -0600, Jim Nasby wrote in <56d77de7.7080...@bluetreble.com> > On 3/2/16 5:41 PM, Tom Lane wrote: > > Jim Nasby writes: > >> On 3/2/16 4:21 PM, Peter Geoghegan wrote: > >>> I think you should commit this. The chances

Re: [HACKERS] SP-GiST support for inet datatypes

On Thu, Mar 3, 2016 at 8:51 AM, Oleg Bartunov wrote: > > > On Wed, Mar 2, 2016 at 11:56 PM, Emre Hasegeli wrote: > >> Attached patches add SP-GiST support to the inet datatypes. The >> operator class comes with a small change on the SP-GiST framework to

Re: [HACKERS] SP-GiST support for inet datatypes

On Wed, Mar 2, 2016 at 11:56 PM, Emre Hasegeli wrote: > Attached patches add SP-GiST support to the inet datatypes. The operator > class comes with a small change on the SP-GiST framework to allow fixed > number of child nodes. > > The index is like prefix tree except that it

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On Thu, Mar 3, 2016 at 2:20 PM, Craig Ringer wrote: > On the Perl 5.8.8 test env I've set up now, per > > http://www.postgresql.org/message-id/camsr+ygr6pu-guyp-ft98xwxasc9n6j-awzaqxvw_+p3rtc...@mail.gmail.com > > master currently fails with > >

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Fri, Feb 5, 2016 at 2:29 PM, Haribabu Kommi wrote: > >This patch needs to be applied on top discard_hba_and_ident_cxt patch >that is posted earlier. Here I attached a re-based patch to the latest head with inclusion of discard_hba_ident_cxt patch for easier review as

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 3 March 2016 at 05:26, Alvaro Herrera wrote: > > Pushed it with that fix. I also added a further "data_" prefix, so it's > "data_${name}_" now. Hopefully this is less problematic than > yesterday's ... > > On the Perl 5.8.8 test env I've set up now, per

Re: [HACKERS] Issue with NULLS LAST, with postgres_fdw sort pushdown

Ashutosh Bapat writes: > On Thu, Mar 3, 2016 at 7:27 AM, Michael Paquier > wrote: >> Per explain.c, this looks inconsistent to me. Shouldn't NULLS LAST be >> applied only if DESC is used in this ORDER BY clause? > ... In this case we

Re: [HACKERS] Dockerfile for testing with Perl 5.8.8

On 3 March 2016 at 11:06, Craig Ringer wrote: > Hi all > > I've prepared a Dockerfile that produces a canned Perl 5.8.8 environment > based on CentOS 5 on any host with Docker. It has ccache installed and > enabled, git installed, IPC::Run installed, all the mess required

Re: [HACKERS] On columnar storage (2)

On Mon, Feb 1, 2016 at 12:11 AM, Alvaro Herrera wrote: > So we discussed some of this stuff during the developer meeting in > Brussels and the main conclusion is that we're going to split this up in > multiple independently useful pieces, and write up the general roadmap

Re: [HACKERS] Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

Hi, On 02/03/2016 06:46 AM, Noah Misch wrote: On Mon, Feb 01, 2016 at 07:03:45PM +0100, Tomas Vondra wrote: On 12/22/2015 03:49 PM, Noah Misch wrote: On Mon, Feb 18, 2013 at 06:19:12PM -0300, Alvaro Herrera wrote: I have pushed it now. Further testing, of course, is always welcome. While

Re: [HACKERS] WIP: Upper planner pathification

David Rowley writes: > I agree that it would be good to get this in as soon as possible. I'm > currently very close to being done with writing Parallel Aggregate on > top of the upper planner changes. So far this version is much cleaner > as there's less cruft added

Re: [HACKERS] Issue with NULLS LAST, with postgres_fdw sort pushdown

On Thu, Mar 3, 2016 at 7:27 AM, Michael Paquier wrote: > On Wed, Mar 2, 2016 at 7:04 PM, Rajkumar Raghuwanshi > wrote: > > On Wed, Mar 2, 2016 at 2:35 PM, Ashutosh Bapat > > wrote: > >> > >>

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Mar 2, 2016 at 3:10 AM, Robert Haas wrote: > On Wed, Feb 17, 2016 at 3:22 AM, Fabien COELHO wrote: >> Indeed. My gcc 4.8.4 with --Wall does not show the warning, too bad. >> >> Attached is the fixed patch for the array method. > > Committed

Re: [HACKERS] WIP: Upper planner pathification

On 3 March 2016 at 04:29, Alvaro Herrera wrote: > Simon Riggs wrote: > >> ISTM that we are clearly "going for it"; everybody agrees we should apply >> the patch now. >> >> The longer we hold off on applying it, the longer we wait for dependent >> changes. > > Agreed --

Re: [HACKERS] psql completion for ids in multibyte string

On Thu, Mar 3, 2016 at 2:07 PM, Kyotaro HORIGUCHI wrote: > Hello, thank you for the comments. > > At Wed, 2 Mar 2016 10:10:55 +1300, Thomas Munro > wrote in >

Re: [HACKERS] The plan for FDW-based sharding

On Mar 3, 2016 4:47 AM, "Michael Paquier" wrote: > > On Wed, Mar 2, 2016 at 6:54 PM, Alexander Korotkov > wrote: > > If FDWs existed then Postgres XC/XL were being developed then I believe they > > would try to build full-featured prototype

[HACKERS] Dockerfile for testing with Perl 5.8.8

Hi all I've prepared a Dockerfile that produces a canned Perl 5.8.8 environment based on CentOS 5 on any host with Docker. It has ccache installed and enabled, git installed, IPC::Run installed, all the mess required to make CPAN work sensibly done, etc. Once you build the container once you can

Re: [HACKERS] GinPageIs* don't actually return a boolean

On 2/11/16 9:30 PM, Michael Paquier wrote: >> Well, Yury was saying upthread that some MSVC versions have a problem >> with the existing coding, which would be a reason to back-patch ... >> but I'd like to see a failing buildfarm member first. Don't particularly >> want to promise to support

Re: [HACKERS] The plan for FDW-based sharding

> On Wed, Mar 2, 2016 at 6:54 PM, Alexander Korotkov > wrote: >> If FDWs existed then Postgres XC/XL were being developed then I believe they >> would try to build full-featured prototype of FDW based sharding. If this >> prototype succeed then we could make a full

Re: [HACKERS] Issue with NULLS LAST, with postgres_fdw sort pushdown

On Wed, Mar 2, 2016 at 7:04 PM, Rajkumar Raghuwanshi wrote: > On Wed, Mar 2, 2016 at 2:35 PM, Ashutosh Bapat > wrote: >> >> Thanks Rajkumar for your report. Let me know if the attached patch fixes >> the issue. if

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Mar 2, 2016 at 6:54 PM, Alexander Korotkov wrote: > If FDWs existed then Postgres XC/XL were being developed then I believe they > would try to build full-featured prototype of FDW based sharding. If this > prototype succeed then we could make a full roadmap.

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

On Thu, Mar 3, 2016 at 12:47 AM, Alvaro Herrera wrote: > Well, the CopyData message has an Int32 field for the message length. > I don't know the FE/BE protocol very well but I suppose each row > corresponds to one CopyData message, or perhaps each column corresponds >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Sun, Feb 28, 2016 at 8:04 AM, Masahiko Sawada wrote: > Attached latest version patch. > > The changes from previous version are, > - Fix parser, lexer bugs. > - Add regression test patch based on patch Suraji submitted. > > Please review it. > >

Re: [HACKERS] psql completion for ids in multibyte string

Hello, thank you for the comments. At Wed, 2 Mar 2016 10:10:55 +1300, Thomas Munro wrote in

Re: [HACKERS] Fixing wrong comment on PQmblen and PQdsplen.

Hello, At Tue, 1 Mar 2016 13:33:02 -0500, Robert Haas wrote in > On Fri, Feb 26, 2016 at 12:33 AM, Kyotaro HORIGUCHI > wrote: > > I divided the last patch into one

Re: [HACKERS] jsonb array-style subscription

On 3/2/16 6:24 PM, Tom Lane wrote: If the patch were proposing a similar amount of new infrastructure to support some datatype-extensible concept of subscripting, I'd be much happier about it. +1 I believe there's been some handwaving in the past about extensible approaches to subscripting,

Re: [HACKERS] jsonb array-style subscription

Vitaly Burovoy writes: > I'd like to be a reviewer for the patch. It does not look big and very > invasive. > Is it a final decision or it has a chance? If something there hurts > committers, it can end up as "Rejected with feedback" (since the patch > is already in the

Re: [HACKERS] WIP: Upper planner pathification

Teodor Sigaev writes: > Yep, for now on my notebook (best from 5 tries): > % pgbench -i -s 3000 > % pgbench -s 3000 -c 4 -j 4 -P 1 -T 60 > HEAD569 tps > patched 542 tps > % pgbench -s 3000 -c 4 -j 4 -P 1 -T 60 -S > HEAD9500 tps > patched 9458 tps > Looks close to

Re: [HACKERS] Freeze avoidance of very large table.

On 3/2/16 5:41 PM, Tom Lane wrote: Jim Nasby writes: On 3/2/16 4:21 PM, Peter Geoghegan wrote: I think you should commit this. The chances of anyone other than you and Masahiko recalling that you developed this tool in 3 years is essentially nil. I think that the

Re: [HACKERS] Convert pltcl from strings to objects

Jim Nasby writes: > On 3/1/16 5:06 PM, Tom Lane wrote: >> If we don't do that, I'm at least going to put in a similar #error for >> Tcl 8.0; but I really think we ought to just say 8.4 is the minimum. > Just confirmed that should be completely reasonable. I'll take a

Re: [HACKERS] jsonb array-style subscription

On 1/19/16, Alvaro Herrera wrote: > Dmitry Dolgov wrote: > >> I've cleaned up the code, created a separate JsonbRef node (and there are >> a >> lot of small changes because of that), abandoned an idea of "deep >> nesting" >> of assignments (because it doesn't relate to

Re: [HACKERS] Publish autovacuum informations

On 3/2/16 10:48 AM, Julien Rouhaud wrote: Good point, I don't see a lot of information available with this hooks that a native system statistics couldn't offer. To have the same amount of information, I think we'd need a pg_stat_autovacuum view that shows a realtime insight of the workers, and

Re: [HACKERS] Freeze avoidance of very large table.

Jim Nasby writes: > On 3/2/16 4:21 PM, Peter Geoghegan wrote: >> I think you should commit this. The chances of anyone other than you >> and Masahiko recalling that you developed this tool in 3 years is >> essentially nil. I think that the cost of committing a

Re: [HACKERS] Convert pltcl from strings to objects

On 3/1/16 5:06 PM, Tom Lane wrote: If we don't do that, I'm at least going to put in a similar #error for Tcl 8.0; but I really think we ought to just say 8.4 is the minimum. Just confirmed that should be completely reasonable. I'll take a look at it in a few days if you don't beat me to it.

Re: [HACKERS] Convert pltcl from strings to objects

On 3/2/16 12:32 PM, Tom Lane wrote: Jim Nasby writes: [ pltcl_objects_2.patch ] I've pushed this with some minor fixes, as well as the followup work mentioned in this thread. Awesome, thanks! I've asked Karl's opinion on increasing the minimum TCL version, but I

Re: [HACKERS] Freeze avoidance of very large table.

On 3/2/16 4:21 PM, Peter Geoghegan wrote: I think you should commit this. The chances of anyone other than you and Masahiko recalling that you developed this tool in 3 years is essentially nil. I think that the cost of committing a developer-level debugging tool like this is very low. Modules

[HACKERS] WHERE clause not used when index is used (9.5)

Placing this specific message onto -bugs while keeping -hackers and removing -novice. Editing subject to include version and remove list identifiers. There is continuing discussion on -hackers though mostly about how to do this right in the future. The specific problem stems from an attempted

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 3/2/16 3:52 PM, Pavel Stehule wrote: Right, and it's arguably dubious that that doesn't already work. Unfortunately, these % things are just random plpgsql parser hacks, not real types. Maybe this should be done in the main PostgreSQL parser with parameter hooks, if we wanted

Re: [HACKERS] WIP: Upper planner pathification

Alvaro Herrera writes: > Agreed -- we need this in tree as soon as realistically possible. > There is a a bit a problem here, because this patch conflicts heavily > with at least one other patch that's been in the queue for a long time, > which is Kommi/Rowley's patch

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Mar 1, 2016 at 6:51 PM, Robert Haas wrote: > I removed the pgstat stuff. I'm not sure we want that stuff in that > form; it doesn't seem to fit with the rest of what's in that view, and > it wasn't reliable in my testing. I did however throw together a > little

Re: [HACKERS] pg_dump dump catalog ACLs

* Joe Conway (m...@joeconway.com) wrote: > On 03/02/2016 12:54 PM, Stephen Frost wrote: > > * Joe Conway (m...@joeconway.com) wrote: > >> On 03/01/2016 08:00 AM, Tom Lane wrote: > >>> Yes, we'd need some way to mark non-null ACLs as being "built-in > >>> defaults". I do not see the need to have

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2016-02-24 22:18 GMT+01:00 Peter Eisentraut : > On 1/18/16 4:21 PM, Robert Haas wrote: > > One idea that occurs to me is: If you can DECLARE BAR FOO%TYPE, but > > then you want to make BAR an array of that type rather than a scalar, > > why not write that as DECLARE BAR

Re: [HACKERS] pg_dump dump catalog ACLs

On Wed, Mar 2, 2016 at 2:44 PM, Joe Conway wrote: > On 03/02/2016 12:54 PM, Stephen Frost wrote: > > * Joe Conway (m...@joeconway.com) wrote: > >> On 03/01/2016 08:00 AM, Tom Lane wrote: > >>> Yes, we'd need some way to mark non-null ACLs as being "built-in > >>> defaults".

Re: [HACKERS] pg_dump dump catalog ACLs

On 03/02/2016 12:54 PM, Stephen Frost wrote: > * Joe Conway (m...@joeconway.com) wrote: >> On 03/01/2016 08:00 AM, Tom Lane wrote: >>> Yes, we'd need some way to mark non-null ACLs as being "built-in >>> defaults". I do not see the need to have SQL syntax supporting that >>> though. >> >> I was

Re: [HACKERS] Random inconsistencies in GiST support function declarations

Jeff Janes writes: > This work (9ff60273e35cad6e9) seems have broken pg_upgrade when > tsearch2 is installed. > On an empty 9.4 instance with nothing but tsearch2 installed, using > HEAD's pg_upgrade gives this error: > pg_restore: creating OPERATOR CLASS

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Craig Ringer wrote: > On 2 March 2016 at 07:07, Alvaro Herrera wrote: > > > Craig Ringer wrote: > > > > > diff --git a/src/test/perl/TestLib.pm b/src/test/perl/TestLib.pm > > > index 3d11cbb..8c13655 100644 > > > --- a/src/test/perl/TestLib.pm > > > +++

Re: [HACKERS] pg_dump dump catalog ACLs

* David G. Johnston (david.g.johns...@gmail.com) wrote: > On Wed, Mar 2, 2016 at 1:54 PM, Stephen Frost wrote: > > Rather than have two aclitem[] columns in every catalog, since this > > information is only used by pg_dump and not during normal operation, we > > could use the

Re: [HACKERS] pg_dump dump catalog ACLs

On Wed, Mar 2, 2016 at 1:54 PM, Stephen Frost wrote: > * Joe Conway (m...@joeconway.com) wrote: > > On 03/01/2016 08:00 AM, Tom Lane wrote: > > > Joe Conway writes: > > >> Would it be a terrible idea to add some attribute to ACLs which can be > > >> used

[HACKERS] SP-GiST support for inet datatypes

Attached patches add SP-GiST support to the inet datatypes. The operator class comes with a small change on the SP-GiST framework to allow fixed number of child nodes. The index is like prefix tree except that it doesn't bother to split the addresses into parts as text is split. It also doesn't

Re: [HACKERS] pg_dump dump catalog ACLs

* Joe Conway (m...@joeconway.com) wrote: > On 03/01/2016 08:00 AM, Tom Lane wrote: > > Joe Conway writes: > >> Would it be a terrible idea to add some attribute to ACLs which can be > >> used to indicate they should not be dumped (and supporting syntax)? > > > > Yes, we'd

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Mar 2, 2016 at 9:53 PM, Josh berkus wrote: > On 02/24/2016 01:22 AM, Konstantin Knizhnik wrote: > >> Sorry, but based on this plan it is possible to make a conclusion that >> there are only two possible cluster solutions for Postgres: >> XC/XL and FDW-based. From my

Re: [HACKERS] The plan for FDW-based sharding

On 02/24/2016 01:22 AM, Konstantin Knizhnik wrote: Sorry, but based on this plan it is possible to make a conclusion that there are only two possible cluster solutions for Postgres: XC/XL and FDW-based. From my point of view there are much more possible alternatives. Definitely. Currently

Re: [HACKERS] More stable query plans via more predictable column statistics

Shulgin, Oleksandr wrote: > Alright. I'm attaching the latest version of this patch split in two > parts: the first one is NULLs-related bugfix and the second is the > "improvement" part, which applies on top of the first one. So is this null-related bugfix supposed to be backpatched? (I

Re: [HACKERS] Convert pltcl from strings to objects

Jim Nasby writes: > [ pltcl_objects_2.patch ] I've pushed this with some minor fixes, as well as the followup work mentioned in this thread. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] create opclass documentation outdated

Tom Lane wrote: > In create_opclass.sgml, not only do we have the list of AMs supporting > STORAGE, but there is also a paragraph describing which AMs do what > for input datatypes of FUNCTION members (around line 175). I placed BRIN together with gist/gin/spgist here, namely that the optype

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Wed, Mar 2, 2016 at 5:41 AM, Magnus Hagander wrote: > Ok, I've pushed a code that does that. Thank you. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Mar 2, 2016 at 5:46 PM, David Steele wrote: > On 3/2/16 11:10 AM, Shulgin, Oleksandr wrote: > > On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra > > > > wrote: > > > > I think it'd be useful not to

Re: [HACKERS] Updated backup APIs for non-exclusive backups

Hi Magnus, I've finally found some time to take a look to the patch. It applies with some fuzziness on master, but the result looks correct. Unfortunately the OID of the new pg_stop_backup function conflicts with "pg_blocking_pids()" patch (52f5d578d6c29bf254e93c69043b817d4047ca67). After

Re: [HACKERS] Publish autovacuum informations

On 02/03/2016 07:30, Michael Paquier wrote: > On Tue, Mar 1, 2016 at 11:37 PM, Julien Rouhaud wrote: >> I'm not sure what are the fancy things that Michael had in mind with >> exposing the private structure. Michael, was it something like having >> the ability to change some of these data through

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Tomas Vondra wrote: > My guess is this is a problem at the protocol level - the 'd' message is > CopyData, and all the messages use int32 to define length. So if there's > a 2GB row, it's likely to overflow. Yes. Besides, the full message includes a negative length: > postgres=# \copy

Re: [HACKERS] multivariate statistics v10

Hi, On 03/02/2016 05:17 PM, Thom Brown wrote: ... Well, firstly, the patches all apply. But I have a question (which is coming really late, but I'll ask it anyway). Is it intended that CREATE STATISTICS will only be for multivariate statistics? Or do you think we could add support for

Re: [HACKERS] More stable query plans via more predictable column statistics

On 3/2/16 11:10 AM, Shulgin, Oleksandr wrote: > On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra > > wrote: > > I think it'd be useful not to have all the changes in one lump, but > structure this as a patch series with

Re: [HACKERS] multivariate statistics v10

On 2 March 2016 at 14:56, Tomas Vondra wrote: > > Hi, > > Attached is v10 of the patch series. There are 9 parts at the moment: > > 0001-teach-pull_-varno-varattno-_walker-about-RestrictInf.patch > 0002-shared-infrastructure-and-functional-dependencies.patch >

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra wrote: > Hi, > > On 02/08/2016 03:01 PM, Shulgin, Oleksandr wrote: > > > ... > >> >> I've incorporated this fix into the v2 of my patch, I think it is >> related closely enough. Also, added corresponding changes to >>

Re: [HACKERS] pl/pgsql exported functions

On 11/02/16 18:29, Magnus Hagander wrote: Most of the pl/pgsql functions and variables are prefixed plpgsql_, so they don't risk conflicting with other shared libraries loaded. There are a couple that are not prefixed. Attached patch fixes that. It's mostly a cleanup, but I think it's something

Re: [HACKERS] Addition of extra commit fest entry to park future patches

On Tue, Mar 1, 2016 at 7:47 PM, Michael Paquier wrote: > 2016-09 has been created then: > https://commitfest.postgresql.org/10/ > People, feel free to park future patches there. I think that should be in status "open" rather than "future". -- Kevin Grittner EDB:

[HACKERS] Re: redo failed in physical streaming replication while stopping the master server

/* * If at page start, we must skip over the page header. But we can't * do that until we've read in the page, since the header size is * variable. */ i don't know the meaning behind this comments, if ((RecPtr->xrecoff %

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

I wrote: > Can't use string ("Test::Builder") as a HASH ref while "strict refs" in use > at /usr/share/perl5/Test/Builder.pm line 1798. > The referenced line number is the end of the file, Oh, scratch that; I was looking at the wrong file. Actually, /usr/share/perl5/Test/Builder.pm has sub

Re: [HACKERS] create opclass documentation outdated

Tom Lane wrote: > I'm inclined to feel that the right answer is to fix all these > omissions, not to decide that we're not maintaining this documentation > anymore. Alvaro, I think this one's in your court. Will fix. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Daniel Verite wrote: > The cause of the crash turns out to be, in enlargeStringInfo(): > > needed += str->len + 1; /* total space required now */ > > needed is an int and str->len is an int64, so it overflows when the > size has to grow beyond 2^31 bytes, fails to enlarge the buffer and >

Re: [HACKERS] WIP: Upper planner pathification

Simon Riggs wrote: > ISTM that we are clearly "going for it"; everybody agrees we should apply > the patch now. > > The longer we hold off on applying it, the longer we wait for dependent > changes. Agreed -- we need this in tree as soon as realistically possible. There is a a bit a problem

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

On 03/02/2016 04:23 PM, Tom Lane wrote: Tomas Vondra writes: On 03/02/2016 03:18 PM, Daniel Verite wrote: However, getting it to the client with \copy big2 to 'file' still produces the error in psql: lost synchronization with server: got message type "d" and

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Tomas Vondra writes: > On 03/02/2016 03:18 PM, Daniel Verite wrote: >> However, getting it to the client with \copy big2 to 'file' >> still produces the error in psql: >> lost synchronization with server: got message type "d" >> and leaves an empty file, so there are

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Hi, On 03/02/2016 03:18 PM, Daniel Verite wrote: I wrote: postgres=# \copy big2 to /dev/null lost synchronization with server: got message type "d", length -1568669676 The backend aborts with the following backtrace: Program terminated with signal 6, Aborted. #0 0x7f82ee68e165

[HACKERS] 2016-03 Commitfest

The 2016-03 commitfest is officially in progress! There are currently a lot of patches waiting for review but with no reviewers: Needs review: 97 Needs *reviewer*: 58 Please check the "needs reviewer" list (https://commitfest.postgresql.org/9/?reviewer=-2) for patches to review. The committers

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

I wrote: > postgres=# \copy big2 to /dev/null > lost synchronization with server: got message type "d", length -1568669676 > > The backend aborts with the following backtrace: > > Program terminated with signal 6, Aborted. > #0 0x7f82ee68e165 in raise () from

Re: [HACKERS] WIP: Upper planner pathification

Robert Haas writes: > On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane wrote: >> I think the default pgbench queries are too simple to have any possible >> benefit from this patch. It does look like you're seeing some extra >> planning time, which I think is

Re: [HACKERS] WIP: Upper planner pathification

On 2 March 2016 at 13:47, Robert Haas wrote: > On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane wrote: > > Teodor Sigaev writes: > >>> I do not think the patch will make a lot of performance difference > as-is; > >>> its value is more in

Re: [HACKERS] WIP: Upper planner pathification

On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane wrote: > Teodor Sigaev writes: >>> I do not think the patch will make a lot of performance difference as-is; >>> its value is more in what it will let us do later. There are a couple of > >> Yep, for now on my

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Wed, Mar 2, 2016 at 7:34 AM, Michael Paquier wrote: > On Wed, Mar 2, 2016 at 9:19 PM, Magnus Hagander > wrote: > > Needs Review -> Needs Review > > Waiting on Author -> Refuse moving > > Ready for committer -> Ready for Committer > > Committed

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Wed, Mar 2, 2016 at 9:19 PM, Magnus Hagander wrote: > Needs Review -> Needs Review > Waiting on Author -> Refuse moving > Ready for committer -> Ready for Committer > Committed -> refuse moving > Moved to next cf -> refuse moving (if it's already set like this, it would >

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Tue, Mar 1, 2016 at 10:27 AM, Tom Lane wrote: > Alvaro Herrera writes: > > Magnus Hagander wrote: > >> That said, we can certainly reconsider that. Would we always copy the > value > >> over? Even if it was, say, rejected? (so it would be copied

Re: [HACKERS][REVIEW]: Password identifiers, protocol aging and SCRAM protocol

On Wed, Mar 2, 2016 at 5:43 PM, Valery Popov wrote: > >>> >>> db_user_namespace causes the client's and >>> server's user name representation to differ. >>> Authentication checks are always done with the server's user name >>> so

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

On 1 March 2016 at 20:03, Tom Lane wrote: > In any event, I am now of the opinion that this patch needs to be reverted > outright and returned to the authors for redesign. There are too many > things wrong with it and too little reason to think that we have to have > it in

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

On 1 March 2016 at 17:22, Jeff Janes wrote: > On Tue, Mar 1, 2016 at 7:40 AM, Tom Lane wrote: > > Tobias Florek writes: > >> When creating an index to use for an ORDER BY clause, a simple query > >> starts to return more results

Re: [HACKERS] The plan for FDW-based sharding

On 01.03.2016 22:02, Bruce Momjian wrote: On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote: Note that I am not saying that other discussed approaches are any better, I am saying that we should know approximately what we actually want and not just beat FDWs with a hammer and hope

Re: [HACKERS] Issue with NULLS LAST, with postgres_fdw sort pushdown

Thanks Ashutosh. Retested the issue after applying given patch,It is fine now. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation On Wed, Mar 2, 2016 at 2:35 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > Thanks Rajkumar for your report. Let me know if the

Re: [HACKERS] The plan for FDW-based sharding

On Tue, Mar 1, 2016 at 10:11 PM, Bruce Momjian wrote: > On Tue, Mar 1, 2016 at 02:02:44PM -0500, Bruce wrote: > > On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote: > > > Note that I am not saying that other discussed approaches are any > > > better, I am saying

Re: [HACKERS] The plan for FDW-based sharding

On Tue, Mar 1, 2016 at 7:03 PM, Robert Haas wrote: > On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian wrote: > > On Tue, Mar 1, 2016 at 10:19:45AM -0500, Robert Haas wrote: > >> > Two reasons: > >> > 1. There is no ideal implementation of DTM which will

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Mar 2, 2016 at 4:36 AM, Tomas Vondra wrote: Hi, > > On 03/01/2016 08:02 PM, Bruce Momjian wrote: > >> On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote: >> >>> Note that I am not saying that other discussed approaches are any >>> better, I am

Re: [HACKERS] The plan for FDW-based sharding

On Tue, Mar 1, 2016 at 7:03 PM, Robert Haas wrote: > On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian wrote: > > On Tue, Mar 1, 2016 at 10:19:45AM -0500, Robert Haas wrote: > >> > Two reasons: > >> > 1. There is no ideal implementation of DTM which will

Re: [HACKERS] Issue with NULLS LAST, with postgres_fdw sort pushdown

Thanks Rajkumar for your report. Let me know if the attached patch fixes the issue. The code did not add NULL LAST clause the case when pk_nulls_first is false in pathkey. PFA the fix for the same. I have also added few tests to postgres_fdw.sql for few combinations of asc/desc and nulls

  1   2   >