Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

2017-07-25 Thread Rafia Sabih
On Wed, Jul 26, 2017 at 11:06 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Jul 26, 2017 at 11:00 AM, Rafia Sabih > wrote: > > > > > > On Wed, Jul 26, 2017 at 10:58 AM, Ashutosh Bapat > > wrote: > >> > >> On

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

2017-07-25 Thread Ashutosh Bapat
On Wed, Jul 26, 2017 at 11:00 AM, Rafia Sabih wrote: > > > On Wed, Jul 26, 2017 at 10:58 AM, Ashutosh Bapat > wrote: >> >> On Tue, Jul 25, 2017 at 11:01 AM, Rafia Sabih >> wrote: >> >> > Query plans for

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

2017-07-25 Thread Rafia Sabih
On Wed, Jul 26, 2017 at 10:58 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Tue, Jul 25, 2017 at 11:01 AM, Rafia Sabih > wrote: > > > Query plans for the above mentioned queries is attached. > > > > Can you please share plans for all the queries,

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

2017-07-25 Thread Ashutosh Bapat
On Tue, Jul 25, 2017 at 11:01 AM, Rafia Sabih wrote: > Query plans for the above mentioned queries is attached. > Can you please share plans for all the queries, even if they haven't chosen partition-wise join when run on partitioned tables with

[HACKERS] proposal: psql: check env variable PSQL_PAGER

2017-07-25 Thread Pavel Stehule
Hi I wrote a special pager for psql. Surely, this pager is not good for paging of man pages. So is not good to set it as global pager. We can introduce new env variable PSQL_PAGER for this purpose. It can work similar like PSQL_EDITOR variable. Notes, comments? Regards Pavel

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

2017-07-25 Thread Ashutosh Bapat
On Tue, Jul 25, 2017 at 9:39 PM, Dilip Kumar wrote: > On Tue, Jul 25, 2017 at 8:59 PM, Robert Haas wrote: >> On Tue, Jul 25, 2017 at 1:31 AM, Rafia Sabih >> wrote: >>> - other queries show a good 20-30% improvement in

Re: [HACKERS] Inadequate infrastructure for NextValueExpr

2017-07-25 Thread Thomas Munro
On Wed, Jul 26, 2017 at 4:04 PM, Thomas Munro wrote: > On Wed, Jul 26, 2017 at 6:35 AM, Robert Haas wrote: >> That's pretty cool. Per long-standing precedent, anything we use in a >> build needs to be in Perl, not Python, but I think it

Re: [HACKERS] Inadequate infrastructure for NextValueExpr

2017-07-25 Thread Thomas Munro
On Wed, Jul 26, 2017 at 6:35 AM, Robert Haas wrote: > That's pretty cool. Per long-standing precedent, anything we use in a > build needs to be in Perl, not Python, but I think it would be great > to fix all of these (or the script) and then add this to our standard >

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Tom Lane
Robert Haas writes: > Based on discussion downthread, it seems like what we actually need to > do is update perl.m4 to extract CCFLAGS. Turns out somebody proposed > a patch for that back in 2002: >

Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page (Was: [HACKERS] [WIP] Zipfian distribution in pgbench)

2017-07-25 Thread Peter Geoghegan
On Tue, Jul 25, 2017 at 8:02 PM, Peter Geoghegan wrote: > Setup: > > Initialize pgbench (any scale factor). > create index on pgbench_accounts (aid); That "create index" was meant to be on "abalance", to make the UPDATE queries always HOT-unsafe. (You'll want to *also* create this

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 10:23 AM, Robert Haas wrote: > While I'm not sure of the details, I suspect that we need to use one > of those methods to get the CCFLAGS used to build perl, and include > those when SPI.o, Util.o, and plperl.o in src/pl/plperl. Or at least > the -D

Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page (Was: [HACKERS] [WIP] Zipfian distribution in pgbench)

2017-07-25 Thread Peter Geoghegan
On Tue, Jul 25, 2017 at 3:02 PM, Peter Geoghegan wrote: > I've been thinking about this a lot, because this really does look > like a pathological case to me. I think that this workload is very > sensitive to how effective kill_prior_tuples/LP_DEAD hinting is. Or at > least, I can

Re: [HACKERS] Mishandling of WCO constraints in direct foreign table modification

2017-07-25 Thread Etsuro Fujita
On 2017/07/25 5:35, Robert Haas wrote: On Fri, Jul 21, 2017 at 6:21 AM, Etsuro Fujita wrote: I mean constraints derived from WITH CHECK OPTIONs specified for parent views. We use the words "WITH CHECK OPTION constraints" in comments in nodeModifyTable.c, so the

Re: [HACKERS] Change in "policy" on dump ordering?

2017-07-25 Thread Tom Lane
I wrote: > The main problem with Kevin's fix, after thinking about it more, is that > it shoves matview refresh commands into the same final processing phase > where ACLs are done, which means that in a parallel restore they will not > be done in parallel. That seems like a pretty serious

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

2017-07-25 Thread Tom Lane
Stephen Frost writes: > On Tue, Jul 25, 2017 at 20:29 Thom Brown wrote: >> I should point out that this commit was made during the 9.6 cycle, and >> I get the same issue with 9.6. > Interesting that Tom didn't. Still, that does make more sense to me. Yeah,

Re: [HACKERS] [PATCH] Make ExplainBeginGroup()/ExplainEndGroup() public.

2017-07-25 Thread Kyotaro HORIGUCHI
At Fri, 21 Jul 2017 10:09:25 -0400, Hadi Moshayedi wrote in > Hello, > > The attached patch moves declarations of > ExplainBeginGroup()/ExplainEndGroup() from explain.c to explain.h. > > This can be useful

Re: [HACKERS] segfault in HEAD when too many nested functions call

2017-07-25 Thread Andres Freund
Hi, On 2017-07-24 13:27:58 -0400, Tom Lane wrote: > Andres Freund writes: > >> * I think the comments need more work. Am willing to make a pass over > >> that if you want. > > > That'd be good, but let's wait till we have something more final. > > Agreed, I'll wait till

[HACKERS] Log LDAP "diagnostic messages"?

2017-07-25 Thread Thomas Munro
Hi hackers, Some LDAP error codes are a bit vague. For example: LDAP_CONNECT_ERROR Indicates a connection problem. LDAP_PROTOCOL_ERROR A protocol violation was detected. To learn more, you have to call ldap_get_option(LDAP_OPT_DIAGNOSTIC_MESSAGE). Should we do that? For

Re: [HACKERS] Syncing sql extension versions with shared library versions

2017-07-25 Thread Craig Ringer
(Re-added hackers to Cc as this doesn't seem private, just accidentally didn't reply-all?) On 24 July 2017 at 23:50, Mat Arye wrote: > > > >> Issue 1: Preloading the right shared library. >> When preloading libraries (either via local_preload_libraries, or >>

Re: [HACKERS] TAP: allow overriding PostgresNode in get_new_node

2017-07-25 Thread Craig Ringer
On 26 July 2017 at 07:12, Alvaro Herrera wrote: > Chapman Flack wrote: > > > Any takers if I propose this amendment in the form of a patch? > > > > Relying on the perl idiom instead of a $node->isa() test shortens > > the patch; does that ameliorate at all the concern

Re: [HACKERS] WIP: Failover Slots

2017-07-25 Thread Craig Ringer
On 26 July 2017 at 00:16, Thom Brown wrote: > On 8 April 2016 at 07:13, Craig Ringer wrote: > > On 6 April 2016 at 22:17, Andres Freund wrote: > > > >> > >> Quickly skimming 0001 in [4] there appear to be a number of issues: > >> *

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

2017-07-25 Thread Stephen Frost
Thom, On Tue, Jul 25, 2017 at 20:29 Thom Brown wrote: > On 26 July 2017 at 00:52, Stephen Frost wrote: > > Thom, > > > > * Thom Brown (t...@linux.com) wrote: > >> This is the culprit: > >> > >> commit 23f34fa4ba358671adab16773e79c17c92cbc870 > >> Author:

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

2017-07-25 Thread Thom Brown
On 26 July 2017 at 00:52, Stephen Frost wrote: > Thom, > > * Thom Brown (t...@linux.com) wrote: >> This is the culprit: >> >> commit 23f34fa4ba358671adab16773e79c17c92cbc870 >> Author: Stephen Frost >> Date: Wed Apr 6 21:45:32 2016 -0400 > > Thanks!

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

2017-07-25 Thread Stephen Frost
Thom, * Thom Brown (t...@linux.com) wrote: > This is the culprit: > > commit 23f34fa4ba358671adab16773e79c17c92cbc870 > Author: Stephen Frost > Date: Wed Apr 6 21:45:32 2016 -0400 Thanks! I'll take a look tomorrow. Stephen signature.asc Description: Digital signature

Re: [HACKERS] TAP: allow overriding PostgresNode in get_new_node

2017-07-25 Thread Alvaro Herrera
Chapman Flack wrote: > Any takers if I propose this amendment in the form of a patch? > > Relying on the perl idiom instead of a $node->isa() test shortens > the patch; does that ameliorate at all the concern about complicating > core for the benefit of modules? Yeah, I like this (I also got

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

2017-07-25 Thread Thom Brown
On 25 July 2017 at 21:47, Stephen Frost wrote: > Tom, > > On Tue, Jul 25, 2017 at 16:43 Tom Lane wrote: >> >> AFAICT, pg_dump has no notion that it needs to be careful about the order >> in which permissions are granted. I did >> >> regression=# create

LP_DEAD hinting and not holding on to a buffer pin on leaf page (Was: [HACKERS] [WIP] Zipfian distribution in pgbench)

2017-07-25 Thread Peter Geoghegan
On Fri, Jul 14, 2017 at 5:06 PM, Peter Geoghegan wrote: > I think that what this probably comes down to, more than anything > else, is that you have leftmost hot/bloated leaf pages like this: > > > idx | level | l_item | blkno | btpo_prev | > btpo_next |

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

2017-07-25 Thread Alvaro Herrera
Kunshchikov Vladimir wrote: > Errors should be like this: > pg_restore: [compress_io] could not read from input file: d3/2811.dat.gz: > invalid distance too far back > > Attached small fix for this issue. After looking at this patch, I don't like it very much. In particular, I don't like the

Re: [HACKERS] UPDATE of partition key

2017-07-25 Thread Robert Haas
On Thu, Jul 13, 2017 at 1:09 PM, Amit Khandekar wrote: > Attached is a WIP patch (make_resultrels_ordered.patch) that generates > the result rels in canonical order. This patch is kept separate from > the update-partition-key patch, and can be applied on master branch.

Re: [HACKERS] PostgreSQL 10 (latest beta) and older ICU

2017-07-25 Thread Tom Lane
Victor Wagner writes: > PostgreSQL 10 when build with --with-icu requires ICU 4.6 and above. > (because it searches for libicu using pkgconfig, and pgkconfig support > significantly changed in ICU version 4.6) > However, there are some reasons to build PostgreSQL with older

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

2017-07-25 Thread Stephen Frost
Tom, On Tue, Jul 25, 2017 at 16:43 Tom Lane wrote: > AFAICT, pg_dump has no notion that it needs to be careful about the order > in which permissions are granted. I did > > regression=# create user joe; > CREATE ROLE > regression=# create user bob; > CREATE ROLE >

[HACKERS] pg_dump does not handle indirectly-granted permissions properly

2017-07-25 Thread Tom Lane
AFAICT, pg_dump has no notion that it needs to be careful about the order in which permissions are granted. I did regression=# create user joe; CREATE ROLE regression=# create user bob; CREATE ROLE regression=# create user alice; CREATE ROLE regression=# \c - joe You are now connected to

[HACKERS] expand_dbname in postgres_fdw

2017-07-25 Thread Arseny Sher
Hi, Is there any particular reason why postgres_fdw forbids usage of connection strings by passing expand_dbname = false to PQconnectdbParams? Attached patch shows where this happens. >From 6bf3741976b833379f5bb370aa41f73a51b99afd Mon Sep 17 00:00:00 2001 From: Arseny Sher

[HACKERS] PostgreSQL 10 (latest beta) and older ICU

2017-07-25 Thread Victor Wagner
Collegues, PostgreSQL 10 when build with --with-icu requires ICU 4.6 and above. (because it searches for libicu using pkgconfig, and pgkconfig support significantly changed in ICU version 4.6) However, there are some reasons to build PostgreSQL with older versions of ICU. For instance such

Re: [HACKERS] Testlib.pm vs msys

2017-07-25 Thread Andrew Dunstan
On 07/25/2017 01:41 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 07/25/2017 11:25 AM, Tom Lane wrote: >>> Oh. So when was the last time it worked? And why do the buildfarm >>> archives contain apparently-successful log_stage entries for pg_ctl-check >>>

Re: [HACKERS] Inadequate infrastructure for NextValueExpr

2017-07-25 Thread Robert Haas
On Thu, Jul 13, 2017 at 9:46 PM, Thomas Munro wrote: > I wrote a script to cross-check various node handling functions and it told > me: > > T_NextValueExpr not handled in outfuncs.c > T_ObjectWithArgs not handled in outfuncs.c > T_AccessPriv not handled in

Re: [HACKERS] More race conditions in logical replication

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 5:47 AM, Petr Jelinek wrote: > As a side note, the ConditionVariablePrepareToSleep()'s comment could be > improved because currently it says the only advantage is that we skip > double-test in the beginning of ConditionVariableSleep(). But

Re: [HACKERS] More race conditions in logical replication

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 1:42 PM, Alvaro Herrera wrote: > As I see it, we need to backpatch at least parts of this patch. I've > received reports that in earlier branches pglogical and BDR can > sometimes leave slots behind when removing nodes, and I have a hunch > that

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 1:50 PM, Tom Lane wrote: > Andres Freund writes: >> I'm not sure what you're arguing for here. > > Robert wants perfection, of course ;-). As do we all. But there are > only so many hours in the day, and rejiggering pg_dump's

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Tom Lane
"Joshua D. Drake" writes: > Isn't the simplest solution just to actually document this? Given that it's behaved this way since 8.1 (maybe earlier, I'm not sure), and nobody has complained before, I'm not sure it's worth documenting. There are lots of undocumented

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Tom Lane
Andres Freund writes: > I'm not sure what you're arguing for here. Robert wants perfection, of course ;-). As do we all. But there are only so many hours in the day, and rejiggering pg_dump's rules about how to dump PLs is just way down the to-do list. I'm going to go do

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Joshua D. Drake
On 07/25/2017 10:24 AM, Andres Freund wrote: On 2017-07-25 13:18:25 -0400, Robert Haas wrote: On Tue, Jul 25, 2017 at 1:13 PM, Andres Freund wrote: On 2017-07-25 13:10:11 -0400, Robert Haas wrote: On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote: Is

Re: [HACKERS] More race conditions in logical replication

2017-07-25 Thread Alvaro Herrera
Petr Jelinek wrote: > On 25/07/17 01:33, Alvaro Herrera wrote: > > Alvaro Herrera wrote: > >> I'm back at looking into this again, after a rather exhausting week. I > >> think I have a better grasp of what is going on in this code now, > > > > Here's an updated patch, which I intend to push

Re: [HACKERS] Testlib.pm vs msys

2017-07-25 Thread Tom Lane
Andrew Dunstan writes: > On 07/25/2017 11:25 AM, Tom Lane wrote: >> Oh. So when was the last time it worked? And why do the buildfarm >> archives contain apparently-successful log_stage entries for pg_ctl-check >> on jacana, up through yesterday when I looked? >

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Andres Freund
On 2017-07-25 13:18:25 -0400, Robert Haas wrote: > On Tue, Jul 25, 2017 at 1:13 PM, Andres Freund wrote: > > On 2017-07-25 13:10:11 -0400, Robert Haas wrote: > >> On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote: > >> >> Is this assumption, like, documented

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 1:13 PM, Andres Freund wrote: > On 2017-07-25 13:10:11 -0400, Robert Haas wrote: >> On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote: >> >> Is this assumption, like, documented someplace? >> > >> > Uh, right there? >> >> I don't

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Andres Freund
On 2017-07-25 13:10:11 -0400, Robert Haas wrote: > On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote: > >> Is this assumption, like, documented someplace? > > > > Uh, right there? > > I don't think we can expect end-users to read the code comments to > determine whether their

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote: >> Is this assumption, like, documented someplace? > > Uh, right there? I don't think we can expect end-users to read the code comments to determine whether their apparently-legal SQL is fully supported. -- Robert Haas

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Tom Lane
Robert Haas writes: > On Tue, Jul 25, 2017 at 10:31 AM, Tom Lane wrote: >> pg_dump doesn't really support that scenario, and I don't feel any >> great need to make it do so. Per the comment in dumpProcLang: > Is this assumption, like, documented

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

2017-07-25 Thread Tomas Vondra
On 7/25/17 5:04 PM, Tom Lane wrote: Tomas Vondra writes: On 7/25/17 12:55 AM, Tom Lane wrote: I think the planner basically assumes that reltuples is the live tuple count, so maybe we'd better change VACUUM to get in step. Attached is a patch that (I think)

Re: [HACKERS] [PATCH] Pageinspect - add functions on GIN and GiST indexes from gevel

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 5:57 AM, Teodor Sigaev wrote: >> It's not clear from the web site in question that the relevant code is >> released under the PostgreSQL license. > > As author I allow to use this code in PostgreSQL and under its license. Great. As long as all authors

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 10:31 AM, Tom Lane wrote: > tushar writes: >> postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler; >> CREATE LANGUAGE > > pg_dump doesn't really support that scenario, and I don't feel any > great need to

Re: [HACKERS] WIP: Failover Slots

2017-07-25 Thread Thom Brown
On 8 April 2016 at 07:13, Craig Ringer wrote: > On 6 April 2016 at 22:17, Andres Freund wrote: > >> >> Quickly skimming 0001 in [4] there appear to be a number of issues: >> * LWLockHeldByMe() is only for debugging, not functional differences >> *

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

2017-07-25 Thread Dilip Kumar
On Tue, Jul 25, 2017 at 8:59 PM, Robert Haas wrote: > On Tue, Jul 25, 2017 at 1:31 AM, Rafia Sabih > wrote: >> - other queries show a good 20-30% improvement in performance. Performance >> numbers are as follows, >> >> Query| un_part_head

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Andrew Dunstan
On 07/25/2017 11:32 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote: >>> Hm, I had the idea that we were already asking ExtUtils::Embed for that, >>> but now I see we only inquire about LDFLAGS not

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 11:32 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote: >>> Hm, I had the idea that we were already asking ExtUtils::Embed for that, >>> but now I see we only

Re: [HACKERS] Testlib.pm vs msys

2017-07-25 Thread Andrew Dunstan
On 07/25/2017 11:25 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 07/25/2017 11:11 AM, Tom Lane wrote: >>> What I'm on about is that jacana still succeeds entirely, more than half >>> the time. If this is a handle-duplication problem, how could it ever >>>

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Tom Lane
Robert Haas writes: > On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote: >> Hm, I had the idea that we were already asking ExtUtils::Embed for that, >> but now I see we only inquire about LDFLAGS not CCFLAGS. Yes, this sounds >> like a promising avenue

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 1:31 AM, Rafia Sabih wrote: > - other queries show a good 20-30% improvement in performance. Performance > numbers are as follows, > > Query| un_part_head (seconds) | part_head (seconds) | part_patch (seconds) | > 3 | 76 |127 | 88 | > 4 |17 |

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Robert Haas
On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote: > Hm, I had the idea that we were already asking ExtUtils::Embed for that, > but now I see we only inquire about LDFLAGS not CCFLAGS. Yes, this sounds > like a promising avenue to pursue. > > It would be useful to see the

Re: [HACKERS] Testlib.pm vs msys

2017-07-25 Thread Tom Lane
Andrew Dunstan writes: > On 07/25/2017 11:11 AM, Tom Lane wrote: >> What I'm on about is that jacana still succeeds entirely, more than half >> the time. If this is a handle-duplication problem, how could it ever >> succeed? > No, it hangs 100% of the time. The

Re: [HACKERS] Testlib.pm vs msys

2017-07-25 Thread Andrew Dunstan
On 07/25/2017 11:11 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 07/24/2017 09:33 PM, Tom Lane wrote: >>> Seems like the TAP test should fail every time, if this is a full >>> description. But maybe it's part of the answer, so it seems worth >>>

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Andrew Dunstan
On 07/25/2017 11:00 AM, Tom Lane wrote: > Robert Haas writes: >> Perl also has a mechanism for flags added to Configure to be passed >> along when building loadable modules; if it didn't, not just plperl >> but every Perl module written in C would have this issue if any

Re: [HACKERS] Testlib.pm vs msys

2017-07-25 Thread Tom Lane
Andrew Dunstan writes: > On 07/24/2017 09:33 PM, Tom Lane wrote: >> Seems like the TAP test should fail every time, if this is a full >> description. But maybe it's part of the answer, so it seems worth >> experimenting in this direction. > The test that hangs is

[HACKERS] Re: [SQL] Postgresql “alter column type” creates an event which contains “temp_table_xxx”

2017-07-25 Thread Craig Ringer
On 25 July 2017 at 22:18, Tom Lane wrote: > =?UTF-8?B?WmVocmEgR8O8bCDDh2FidWs=?= writes: > > => ALTER TABLE test ALTER COLUMN x TYPE integer USING > > (trim(x)::integer);ALTER TABLE > > Last command I've executed to alter column data type creates an

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

2017-07-25 Thread Tom Lane
Tomas Vondra writes: > On 7/25/17 12:55 AM, Tom Lane wrote: >> I think the planner basically assumes that reltuples is the live >> tuple count, so maybe we'd better change VACUUM to get in step. > Attached is a patch that (I think) does just that. The disagreement

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Tom Lane
Robert Haas writes: > Perl also has a mechanism for flags added to Configure to be passed > along when building loadable modules; if it didn't, not just plperl > but every Perl module written in C would have this issue if any such > flags where used. > ... > While I'm not

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Tom Lane
Andrew Dunstan writes: > No amount of checking with the Perl community is likely to resolve this > quickly w.r.t. existing releases of Perl. Yes, but if they are shipping broken perl builds that cannot support building of extension modules, they need to be made

Re: [HACKERS] Testlib.pm vs msys

2017-07-25 Thread Andrew Dunstan
On 07/24/2017 09:33 PM, Tom Lane wrote: > > [good theory about why pg_ctl hangs in TAP test] > > Now, this theory still has a Mack-truck-sized hole in it, which is > if that's the failure mechanism then why isn't it 100% effective? > Seems like the TAP test should fail every time, if this is a

Re: [HACKERS] estimation for join results cardinality is sometimes more than the product of the downstream nodes'

2017-07-25 Thread Tom Lane
Alexey Bashtanov writes: > Is there a reason that join cardinality estimates are not limited by the > product of the joined parts cardinalities like in the > join-card-est.patch attached? Because that would be giving an unfair advantage to some paths over others based on

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Tom Lane
Amit Kapila writes: > I think the real question is where do we go from here. Ashutosh has > proposed a patch up-thread based on a suggestion from Andrew, but it > is not clear if we want to go there as that seems to be bypassing > handshake mechanism. That definitely

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Andrew Dunstan
On 07/25/2017 08:58 AM, Amit Kapila wrote: > > I think the real question is where do we go from here. Ashutosh has > proposed a patch up-thread based on a suggestion from Andrew, but it > is not clear if we want to go there as that seems to be bypassing > handshake mechanism. The other tests

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Tom Lane
tushar writes: > postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler; > CREATE LANGUAGE pg_dump doesn't really support that scenario, and I don't feel any great need to make it do so. Per the comment in dumpProcLang: * Try to find the

Re: Fwd: [HACKERS] Syncing sql extension versions with shared library versions

2017-07-25 Thread Mat Arye
On Mon, Jul 24, 2017 at 6:16 PM, Tom Lane wrote: > Mat Arye writes: > > On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane wrote: > >> I'm not really sure why planner hooks would have anything to do with > your > >> exposed SQL API? > > >

[HACKERS] [PATCH] Make ExplainOpenGroup()/ExplainCloseGroup() available for extensions.

2017-07-25 Thread Hadi Moshayedi
Hello Hackers, The attached patch moves declarations of ExplainOpenGroup()/ExplainCloseGroup() from explain.c to explain.h. This can be useful for extensions that need explain groups in their custom-scan explain output. For example, Citus uses groups in its custom explain outputs [1]. But it

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Robert Haas
On Wed, Jul 19, 2017 at 5:01 PM, Tom Lane wrote: > I am really suspicious that this means your libperl was built in an unsafe > fashion, that is, by injecting configuration choices as random -D switches > in the build process rather than making sure the choices were recorded

Re: [HACKERS] [SQL] Postgresql “alter column type” creates an event which contains “temp_table_xxx”

2017-07-25 Thread Tom Lane
=?UTF-8?B?WmVocmEgR8O8bCDDh2FidWs=?= writes: > => ALTER TABLE test ALTER COLUMN x TYPE integer USING > (trim(x)::integer);ALTER TABLE > Last command I've executed to alter column data type creates an event like > this: > BEGIN 500913table public.pg_temp_1077668: INSERT:

Re: [HACKERS] cache lookup failed error for partition key with custom opclass

2017-07-25 Thread Tom Lane
Rushabh Lathia writes: > On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane wrote: >> Some looking around says that this *isn't* the only place that just >> blithely assumes that it will find an opfamily entry. But I agree >> that not checking for that isn't

[HACKERS] estimation for join results cardinality is sometimes more than the product of the downstream nodes'

2017-07-25 Thread Alexey Bashtanov
Hello, Postgres can produce a plan with a nested loop node having rows estimate much more than the product of underlying nodes' estimates, relying only on outer relation size: alexey=# explain SELECT oid, relname FROM ( SELECT m.oid, m.relname FROM pg_class m UNION ALL

Re: [HACKERS] pl/perl extension fails on Windows

2017-07-25 Thread Amit Kapila
On Mon, Jul 24, 2017 at 11:58 AM, Noah Misch wrote: > On Wed, Jul 19, 2017 at 05:01:31PM -0400, Tom Lane wrote: >> Ashutosh Sharma writes: >> > Here are the list of macros and variables from 'intrpvar.h' file that >> > are just defined in perl module but

Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread Thom Brown
On 25 July 2017 at 12:09, tushar wrote: > v9.6 > > postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler; > CREATE LANGUAGE > postgres=# \q > > v10 , run pg_upgrade - failing with this error - > > pg_restore: creating pg_largeobject_metadata

Re: [HACKERS] UPDATE of partition key

2017-07-25 Thread Rajkumar Raghuwanshi
On Tue, Jul 25, 2017 at 3:54 PM, Amit Khandekar wrote: > On 25 July 2017 at 15:02, Rajkumar Raghuwanshi > wrote: > > On Mon, Jul 24, 2017 at 11:23 AM, Amit Khandekar > > > wrote: > >> > >> > >> Attached

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

2017-07-25 Thread Tomas Vondra
On 7/25/17 12:55 AM, Tom Lane wrote: Tomas Vondra writes: It seems to me that VACUUM and ANALYZE somewhat disagree on what exactly reltuples means. VACUUM seems to be thinking that reltuples = live + dead while ANALYZE apparently believes that reltuples = live

[HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

2017-07-25 Thread tushar
v9.6 postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler; CREATE LANGUAGE postgres=# \q v10 , run pg_upgrade - failing with this error - pg_restore: creating pg_largeobject_metadata "pg_largeobject_metadata" pg_restore: creating COMMENT "postgres" pg_restore: creating SCHEMA

Re: [HACKERS] UPDATE of partition key

2017-07-25 Thread Amit Khandekar
On 25 July 2017 at 15:02, Rajkumar Raghuwanshi wrote: > On Mon, Jul 24, 2017 at 11:23 AM, Amit Khandekar > wrote: >> >> >> Attached update-partition-key_v13.patch now contains this >> make_resultrels_ordered.patch changes. >> > > I

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

2017-07-25 Thread Masahiko Sawada
On Tue, Jul 25, 2017 at 4:43 AM, Michael Paquier wrote: > On Mon, Jul 24, 2017 at 6:45 PM, Stephen Frost wrote: >> What the change would do is make the pg_stop_backup() caller block until >> the last WAL is archvied, and perhaps that ends up taking

Re: [HACKERS] POC: Sharing record typmods between backends

2017-07-25 Thread Andres Freund
On 2017-07-10 21:39:09 +1200, Thomas Munro wrote: > Here's a new version that introduces a per-session DSM segment to hold > the shared record typmod registry (and maybe more things later). You like to switch it up. *.patchset.tgz??? ;) It does concern me that we're growing yet another somewhat

Re: [HACKERS] [PATCH] Pageinspect - add functions on GIN and GiST indexes from gevel

2017-07-25 Thread Teodor Sigaev
It's not clear from the web site in question that the relevant code is released under the PostgreSQL license. As author I allow to use this code in PostgreSQL and under its license. -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: [HACKERS] More race conditions in logical replication

2017-07-25 Thread Petr Jelinek
On 25/07/17 01:33, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> I'm back at looking into this again, after a rather exhausting week. I >> think I have a better grasp of what is going on in this code now, > > Here's an updated patch, which I intend to push tomorrow. > I think the

Re: [HACKERS] UPDATE of partition key

2017-07-25 Thread Rajkumar Raghuwanshi
On Mon, Jul 24, 2017 at 11:23 AM, Amit Khandekar wrote: > > Attached update-partition-key_v13.patch now contains this > make_resultrels_ordered.patch changes. > > I have applied attach patch and got below observation. Observation : if join producing multiple output rows

Re: [HACKERS] asynchronous execution

2017-07-25 Thread Kyotaro HORIGUCHI
Hello, 8bf58c0d9bd33686 badly conflicts with this patch, so I'll rebase this and added a patch to refactor the function that Anotonin pointed. This would be merged into 0002 patch. At Tue, 18 Jul 2017 16:24:52 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI

Re: [HACKERS] [PATCH] Pageinspect - add functions on GIN and GiST indexes from gevel

2017-07-25 Thread Oleg Bartunov
On Mon, Jul 24, 2017 at 11:38 PM, Robert Haas wrote: > On Fri, Jul 21, 2017 at 8:05 AM, Alexey Chernyshov > wrote: >> the following patch transfers functionality from gevel module >> (http://www.sai.msu.su/~megera/wiki/Gevel) which provides

Re: [HACKERS] pg_dump issues

2017-07-25 Thread Victor Drobny
We can't create any schema dump with another (user defined) name. E.g. we dump schema test and we want to save it's dump with test2 name in any format. Those refers to databases dump. Hello, Do you expect to have some flag like '--rename=test->test2'? Will dump with test replaced by test2(of

Re: [HACKERS] PgFDW connection invalidation by ALTER SERVER/ALTER USER MAPPING

2017-07-25 Thread Kyotaro HORIGUCHI
At Mon, 24 Jul 2017 10:23:07 +0530, Ashutosh Bapat wrote in > On Fri, Jul 21, 2017 at 10:39 PM, Tom Lane wrote: > > Ashutosh Bapat writes: