Re: [HACKERS] SIGSEGV in BRIN autosummarize

2017-10-14 Thread Justin Pryzby
On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: > > Also notice the vacuum process was interrupted, same as yesterday (think > > goodness for full logs). Our INSERT script is using python > > multiprocessing.pool() with "maxtasksperchild=1", which I think means we > > load > > one

Re: [HACKERS] pg_regress help output

2017-10-14 Thread Joe Conway
On 10/14/2017 02:04 PM, Peter Eisentraut wrote: > On 10/10/17 22:31, Joe Conway wrote: >>> Also, why is the patch apparently changing whitespace in all the help >>> lines? Seems like that will create a lot of make-work for translators. >> I debated with myself about that. > > Well, there are no

Re: [HACKERS] SIGSEGV in BRIN autosummarize

2017-10-14 Thread Tomas Vondra
Hi, On 10/15/2017 12:42 AM, Justin Pryzby wrote: > On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: >> I don't have any reason to believe there's memory issue on the server, So I >> suppose this is just a "heads up" to early adopters until/in case it happens >> again and I can at

Re: [HACKERS] SIGSEGV in BRIN autosummarize

2017-10-14 Thread Justin Pryzby
On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: > I don't have any reason to believe there's memory issue on the server, So I > suppose this is just a "heads up" to early adopters until/in case it happens > again and I can at least provide a stack trace. I'm back; find stacktrace

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

2017-10-14 Thread Peter Geoghegan
On Sat, Oct 14, 2017 at 10:58 AM, Robert Haas wrote: > I think it's perfectly sensible to view those 2 bits as making up a > 2-bit field with 4 states rather than displaying each bit > individually, but you obviously disagree. Fair enough. I guess it is that simple. > I

Re: [HACKERS] Extended statistics is not working on Vars hidden under a RelabelType

2017-10-14 Thread Tomas Vondra
On 10/14/2017 07:49 PM, Robert Haas wrote: > On Fri, Oct 13, 2017 at 4:49 PM, David Rowley > wrote: >> tps = 8282.481310 (including connections establishing) >> tps = 8282.750821 (excluding connections establishing) > > vs. > >> tps = 8520.822410 (including

Re: [HACKERS] pg_regress help output

2017-10-14 Thread Peter Eisentraut
On 10/10/17 22:31, Joe Conway wrote: >> Also, why is the patch apparently changing whitespace in all the help >> lines? Seems like that will create a lot of make-work for translators. > I debated with myself about that. Well, there are no translations of pg_regress, so please change the

Re: [HACKERS] show precise repos version for dev builds?

2017-10-14 Thread Fabien COELHO
The make dependencies ensure that the header file is regenerated on each build with a phony target, and the C file is thus recompiled and linked into the executables on each build. It means that all executables are linked on each rebuild, even if not necessary, though. That'd be quite

Re: [HACKERS] Turn off transitive joins

2017-10-14 Thread Gourav Kumar
I don't think there is any need to add any such capability in postgresql, but I need it for my work. I need the join qualifiers. On 15-Oct-2017 1:37 AM, "Tom Lane" wrote: > Gourav Kumar writes: > > Is there some way by which I can tell postgresql to

Re: [HACKERS] Turn off transitive joins

2017-10-14 Thread Tom Lane
Gourav Kumar writes: > Is there some way by which I can tell postgresql to not to consider > transitive joins while considering join pairs. No ... and you have presented no reason whatever why we should consider adding such a capability. Maybe you should be trying to

[HACKERS] Turn off transitive joins

2017-10-14 Thread Gourav Kumar
Hi all, Is there some way by which I can tell postgresql to not to consider transitive joins while considering join pairs. I.e. Let's say a query has two join predicates one between A & B relations and the other between B and C relations. While constructing the DP to find the best join order,

[HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

2017-10-14 Thread Tomas Vondra
Hi, One of the existing limitations of parallel query is that cursors generally do not benefit from it [1]. Commit 61c2e1a95f [2] improved the situation for cursors from procedural languages, but unfortunately for user-defined cursors parallelism is still disabled. For many use cases that is

Re: [HACKERS] pg_control_recovery() return value when not in recovery

2017-10-14 Thread Tom Lane
Robert Haas writes: > On Fri, Oct 13, 2017 at 7:31 PM, Joe Conway wrote: >> Sorry for the slow response, but thinking back on this now, the idea of >> these functions, in my mind at least, was to provide as close to the >> same output as possible to

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

2017-10-14 Thread Robert Haas
On Fri, Oct 13, 2017 at 4:36 PM, Peter Geoghegan wrote: > No, I'm arguing that they're just bits. Show the bits, rather than > interpreting what is displayed. Document that there are other logical > states that are represented as composites of contradictory/mutually > exclusive

Re: [HACKERS] Extended statistics is not working on Vars hidden under a RelabelType

2017-10-14 Thread Robert Haas
On Fri, Oct 13, 2017 at 4:49 PM, David Rowley wrote: > tps = 8282.481310 (including connections establishing) > tps = 8282.750821 (excluding connections establishing) vs. > tps = 8520.822410 (including connections establishing) > tps = 8521.132784 (excluding

Re: [HACKERS] Extended statistics is not working on Vars hidden under a RelabelType

2017-10-14 Thread Robert Haas
On Fri, Oct 13, 2017 at 4:44 PM, Tomas Vondra wrote: > On 10/13/2017 10:04 PM, Robert Haas wrote: >> On Mon, Oct 9, 2017 at 11:03 PM, David Rowley >> wrote: >>> -- Unpatched >>> Planning time: 0.184 ms >>> Execution time: 105.878 ms

Re: [HACKERS] pg_control_recovery() return value when not in recovery

2017-10-14 Thread Robert Haas
On Fri, Oct 13, 2017 at 7:31 PM, Joe Conway wrote: > Sorry for the slow response, but thinking back on this now, the idea of > these functions, in my mind at least, was to provide as close to the > same output as possible to what pg_controldata outputs. I think that's a good

Re: [HACKERS] fresh regression - regproc result contains unwanted schema

2017-10-14 Thread Pavel Stehule
2017-10-14 17:26 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > When function is overwritten, then regproc result contains schema, > although > > it is on search_path > > There's no "fresh regression" here, it's done that more or less since > we

Re: [HACKERS] fresh regression - regproc result contains unwanted schema

2017-10-14 Thread Tom Lane
Pavel Stehule writes: > When function is overwritten, then regproc result contains schema, although > it is on search_path There's no "fresh regression" here, it's done that more or less since we invented schemas. See regprocout: * Would this proc be found

[HACKERS] fresh regression - regproc result contains unwanted schema

2017-10-14 Thread Pavel Stehule
Hi when I fixed old bug of plpgsql_check I found new regression of regproc output. set check_function_bodies TO off; postgres=# create or replace function f1() returns int as $$ begin end $$ language plpgsql; CREATE FUNCTION postgres=# select 'f1()'::regprocedure::oid::regproc; regproc

Re: [HACKERS] pg_control_recovery() return value when not in recovery

2017-10-14 Thread Michael Paquier
On Sat, Oct 14, 2017 at 8:31 AM, Joe Conway wrote: > Sorry for the slow response, but thinking back on this now, the idea of > these functions, in my mind at least, was to provide as close to the > same output as possible to what pg_controldata outputs. So: > > #

Re: [HACKERS] Continuous integration on Windows?

2017-10-14 Thread legrand legrand
Oups what a silly boy, I didn't saw that pg10 was released ;o( That's all I need soon (to test Declarative partitioning). Thanks for taking time to answer me in a so detailled and interesting manner. Regards PAscal -- Sent from: