Re: [HACKERS] delta relations in AFTER triggers

2016-11-21 Thread Kevin Grittner
On Mon, Nov 21, 2016 at 11:29 AM, Alvaro Herrera wrote: >> When I used the word "cache" here, I was thinking more of this >> English language definition: >> >> a : a hiding place especially for concealing and preserving >>provisions or implements >> b : a

Re: [HACKERS] Patch: Implement failover on libpq connect level.

2016-11-21 Thread Robert Haas
On Sun, Nov 20, 2016 at 8:48 PM, Tsunakawa, Takayuki wrote: >> True, but raising the bar for this feature so that it doesn't get done is >> also bad. It can be improved in a later patch. > > I thought you are very strict about performance, so I hesitate to believe

Re: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG

2016-11-21 Thread Michael Meskes
> I wanted to say that in order to use the connection pointed  > by the DECLARE STATEMENT some functions like ECPGdo() would be > modified or > new function would be added under the directory ecpglib/. > > This modification or new function will be used to get the connection > by statement_name.

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

2016-11-21 Thread Masahiko Sawada
On Fri, Nov 18, 2016 at 6:54 AM, Claudio Freire wrote: > On Thu, Nov 17, 2016 at 6:34 PM, Robert Haas wrote: >> On Thu, Nov 17, 2016 at 1:42 PM, Claudio Freire >> wrote: >>> Attached is patch 0002 with pgindent applied over

Re: [HACKERS] delta relations in AFTER triggers

2016-11-21 Thread Alvaro Herrera
Kevin Grittner wrote: > On Mon, Nov 21, 2016 at 1:05 AM, Thomas Munro > wrote: > > Also, Tsrcache is strangely named: it's not exactly a cache, it's > > more of a registry. > > When I used the word "cache" here, I was thinking more of this > English language

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

2016-11-21 Thread Robert Haas
On Sun, Nov 20, 2016 at 10:42 PM, Michael Paquier wrote: > On Sat, Nov 19, 2016 at 2:16 PM, Michael Paquier > wrote: >> On Fri, Nov 18, 2016 at 1:11 PM, Robert Haas wrote: >>> That might sound adding unnecessary work

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

2016-11-21 Thread Claudio Freire
On Mon, Nov 21, 2016 at 2:15 PM, Masahiko Sawada wrote: > On Fri, Nov 18, 2016 at 6:54 AM, Claudio Freire > wrote: >> On Thu, Nov 17, 2016 at 6:34 PM, Robert Haas wrote: >>> On Thu, Nov 17, 2016 at 1:42 PM, Claudio Freire

Re: [HACKERS] Patch to implement pg_current_logfile() function

2016-11-21 Thread Robert Haas
On Sat, Nov 19, 2016 at 8:51 AM, Karl O. Pinc wrote: > On Sat, 19 Nov 2016 12:58:47 +0100 > Gilles Darold wrote: > >> All patches you've submitted on tha v13 patch have been applied and >> are present in attached v14 of the patch. I have not included the

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Tom Lane
Robert Haas writes: > On Mon, Nov 21, 2016 at 1:00 PM, Tom Lane wrote: >> Hah: not where I thought it was at all. The problem seems to be down to >> the optimization I put into is_parallel_safe() awhile back to skip testing >> anything if we previously

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Robert Haas
On Mon, Nov 21, 2016 at 12:00 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Nov 21, 2016 at 11:43 AM, Tom Lane wrote: >>> so what we've got is a case where a parameter computed by the FunctionScan >>> (in the master) would

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Tom Lane
Robert Haas writes: > On Mon, Nov 21, 2016 at 12:00 PM, Tom Lane wrote: >> It seems like maybe searching for individual Params is the wrong thing. >> Why are we allowing it to generate a parameterized Gather path at all? >> Given the lack of any way to

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

2016-11-21 Thread Claudio Freire
On Fri, Nov 18, 2016 at 11:09 PM, Peter Geoghegan wrote: > On Fri, Nov 18, 2016 at 5:27 PM, Claudio Freire > wrote: >> I've been changing the on-disk format considerably, to one that makes >> more sense. > > I can see how that would be necessary. I'm

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-21 Thread Robert Haas
On Sat, Nov 19, 2016 at 2:54 PM, Tom Lane wrote: > Stephen Frost writes: >> Let's create a new data type for this which supports old and new types, >> add what casts make sense, and call it a day. Changing the data type >> name out from under people is

Re: [HACKERS] delta relations in AFTER triggers

2016-11-21 Thread Thomas Munro
On Tue, Nov 22, 2016 at 7:29 AM, Kevin Grittner wrote: > On Mon, Nov 21, 2016 at 11:29 AM, Alvaro Herrera > wrote: > >>> When I used the word "cache" here, I was thinking more of this >>> English language definition: >>> >>> a : a hiding place

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Robert Haas
On Mon, Nov 21, 2016 at 1:00 PM, Tom Lane wrote: > I wrote: >> Actually, the Gather path *isn't* parameterized. The problem here is >> that we're planning an unflattened subquery, and the only thing that >> is parallel-unsafe is that there is an outer Param in its toplevel

Re: [HACKERS] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

2016-11-21 Thread Robert Haas
On Sun, Nov 20, 2016 at 7:37 PM, Corey Huinker wrote: > I ran into this today: > > select current_database() as current_db \gset > CREATE EXTENSION postgres_fdw; > CREATE EXTENSION > CREATE EXTENSION dblink; > CREATE EXTENSION > CREATE ROLE bob LOGIN PASSWORD 'bob'; >

Re: [HACKERS] delta relations in AFTER triggers

2016-11-21 Thread Robert Haas
On Mon, Nov 21, 2016 at 12:04 PM, Kevin Grittner wrote: >> Also, Tsrcache is strangely named: it's not exactly a cache, it's >> more of a registry. > > When I used the word "cache" here, I was thinking more of this > English language definition: > > a : a hiding place

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Tom Lane
I wrote: > Actually, the Gather path *isn't* parameterized. The problem here is > that we're planning an unflattened subquery, and the only thing that > is parallel-unsafe is that there is an outer Param in its toplevel tlist, > and we're somehow deciding that we can stick that unsafe tlist into

Re: [HACKERS] Patch to implement pg_current_logfile() function

2016-11-21 Thread Karl O. Pinc
On Mon, 21 Nov 2016 13:17:17 -0500 Robert Haas wrote: > > I've a couple of other patches that do > > a little cleanup on master that I'd also like to submit > > along with your patch. > It would really be much better to submit anything that's not > absolutely necessary

Re: [HACKERS] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

2016-11-21 Thread Tom Lane
Corey Huinker writes: > I ran into this today: > CREATE SERVER bob_srv FOREIGN DATA WRAPPER postgres_fdw OPTIONS ( host > 'localhost', dbname :'current_db' ); > ... > ALTER SERVER bob_srv OPTIONS (updatable 'true'); > SELECT * > FROM dblink('bob_srv','SELECT 1') as t(x

Re: [HACKERS] Postgres abort found in 9.3.11

2016-11-21 Thread K S, Sandhya (Nokia - IN/Bangalore)
Hello, As suggested by you, we upgraded the postgres to version 9.3.14. Also we removed all the patches we had applied before. But the issue is still observed in the latest version as well. The issue is seen during normal run and only observed in the standby node. This time as well, the same

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

2016-11-21 Thread Tom Lane
Robert Haas writes: > 1. Should we try to avoid having the stats collector write a stats > file during an immediate shutdown? The file will be removed anyway > during crash recovery, so writing it is pointless. The point I was trying to make is that I think the

Re: [HACKERS] condition variables

2016-11-21 Thread Robert Haas
On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas wrote: > So, in my > implementation, a condition variable wait loop looks like this: > > for (;;) > { > ConditionVariablePrepareToSleep(cv); > if (condition for which we are waiting is satisfied) > break; >

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

2016-11-21 Thread Robert Haas
On Sun, Nov 20, 2016 at 10:20 PM, Tsunakawa, Takayuki wrote: > The reasons why I proposed this patch are: > > * It happened in a highly mission-critical production system of a customer > who uses 9.2. > > * 9.4's solution is not perfect, because it wastes 5

Re: [HACKERS] patch: function xmltable

2016-11-21 Thread Tom Lane
Alvaro Herrera writes: > Something I just noticed is that transformTableExpr takes a TableExpr > node and returns another TableExpr node. That's unlike what we do in > other places, where the node returned is of a different type than the > input node. I'm not real

Re: [HACKERS] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

2016-11-21 Thread Corey Huinker
> > The dblink docs recommend using dblink_fdw as the FDW for this purpose, > which would only accept legal connstr options. However, I can see the > point of using a postgres_fdw server instead, and considering that > dblink isn't actually enforcing use of any particular FDW type, it seems >

Re: [HACKERS] patch: function xmltable

2016-11-21 Thread Alvaro Herrera
Something I just noticed is that transformTableExpr takes a TableExpr node and returns another TableExpr node. That's unlike what we do in other places, where the node returned is of a different type than the input node. I'm not real clear what happens if you try to re-transform a node that was

Re: [HACKERS] Postgres abort found in 9.3.11

2016-11-21 Thread Tom Lane
"K S, Sandhya (Nokia - IN/Bangalore)" writes: > As suggested by you, we upgraded the postgres to version 9.3.14. Also we > removed all the patches we had applied before. But the issue is still > observed in the latest version as well. Can you make a test case for other

Re: [HACKERS] Logical decoding on standby

2016-11-21 Thread Andres Freund
Hi, On 2016-11-21 16:17:58 +0800, Craig Ringer wrote: > I've prepared a working initial, somewhat raw implementation for > logical decoding on physical standbys. Please attach. Otherwise in a year or two it'll be impossible to look this up. Andres -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

2016-11-21 Thread Peter Geoghegan
On Mon, Nov 21, 2016 at 9:42 AM, Claudio Freire wrote: >> I realized today, quite suddenly, why I disliked your original patch: >> it didn't go far enough with embracing the idea of >> heap-item-pointer-as-key. In other words, I didn't like that you >> didn't change

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

2016-11-21 Thread Michael Paquier
On Tue, Nov 22, 2016 at 3:06 AM, Robert Haas wrote: > I don't think that you should skip it in the wraparound case, because > it might be one of the temp tables that is threatening wraparound. > > I've committed the patch after doing some work on the comments. OK, thanks.

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

2016-11-21 Thread Tom Lane
[ apologies for not responding sooner ] Etsuro Fujita writes: > On 2016/11/10 5:17, Tom Lane wrote: >> I think there's a very good argument that we should just treat any inval >> in pg_foreign_data_wrapper as a reason to blow away the whole plan cache. >> People

Re: [HACKERS] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

2016-11-21 Thread Joe Conway
On 11/21/2016 02:16 PM, Tom Lane wrote: > Corey Huinker writes: >> I ran into this today: >> CREATE SERVER bob_srv FOREIGN DATA WRAPPER postgres_fdw OPTIONS ( host >> 'localhost', dbname :'current_db' ); >> ... >> ALTER SERVER bob_srv OPTIONS (updatable 'true'); >> SELECT

Re: [HACKERS] Re: [COMMITTERS] pgsql: autovacuum: Drop orphan temp tables more quickly but with more c

2016-11-21 Thread Tom Lane
Michael Paquier writes: > On Mon, Nov 21, 2016 at 10:05 AM, Robert Haas wrote: >> autovacuum: Drop orphan temp tables more quickly but with more caution. > I have found an obvious bug when reading the code this morning: > orphan_failures is not

Re: [HACKERS] Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?

2016-11-21 Thread Robert Haas
On Mon, Nov 21, 2016 at 3:21 AM, Craig Ringer wrote: > I'm still interested in hearing comments from experienced folks about > whether it's sane to do this at all, rather than have similar > duplicate signal handling for the walsender. Well, I mean, if it's reasonable to

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Robert Haas
On Mon, Nov 21, 2016 at 5:14 PM, Andreas Seltenreich wrote: > Ashutosh Sharma writes: >>> the following query appears to reliably crash parallel workers on master >>> as of 0832f2d. > >> As suggested, I have tried to reproduce this issue on *0832f2d* commit but >> could not

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Tom Lane
Robert Haas writes: > Don't sweat it! Your sqlsmith fuzz testing has been extremely valuable. That might be the understatement of the year. I don't know how long it would have taken us to find these things in the field. Thanks! regards, tom lane

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

2016-11-21 Thread Claudio Freire
On Mon, Nov 21, 2016 at 5:42 PM, Peter Geoghegan wrote: >>> Or, you might want to make >>> sure that B-Tree tuple insertions still find that "first page" to >>> check, despite still generally treating heap item pointer as part of >>> the key proper (in unique indexes, it can

Re: [HACKERS] Contains and is contained by operators of inet datatypes

2016-11-21 Thread Robert Haas
On Mon, Nov 21, 2016 at 7:57 AM, Andreas Karlsson wrote: > I like the patch because it means less operators to remember for me as a > PostgreSQL user. And at least for me inet is a rarely used type compared to > hstore, json and range types which all use @> and <@. I agree

Re: [HACKERS] Improve OOM handling in pg_locale.c

2016-11-21 Thread Tom Lane
Mithun Cy writes: > On Thu, Oct 13, 2016 at 1:40 PM, Michael Paquier > wrote: >> I am attaching that to the next CF. > One thing which you might need to reconsider is removal of memory leak > comments. There is still a leak if there is an

Re: [HACKERS] Improve OOM handling in pg_locale.c

2016-11-21 Thread Michael Paquier
On Tue, Nov 22, 2016 at 8:28 AM, Tom Lane wrote: > I could have lived with leaving the leak there, but really this wasn't > fixing the worst problem with the code: if it did throw an error out of > the middle of that sequence, it would leave the process setlocale'd to > some

Re: [HACKERS] postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer

2016-11-21 Thread Kevin Grittner
On Mon, Nov 21, 2016 at 8:32 AM, Vladimir Svedov wrote: > I have this question. Looked for a help on http://dba.stackexchange.com/ > No success. A link to the actual question would be appreciated. > "FOREIGN_TABLE" created with postgres_fdw. LOCAL_TABLE is just a local >

Re: [HACKERS] WIP: multivariate statistics / proof of concept

2016-11-21 Thread Robert Haas
[ reviving an old multivariate statistics thread ] On Thu, Nov 13, 2014 at 6:31 AM, Simon Riggs wrote: > On 12 October 2014 23:00, Tomas Vondra wrote: > >> It however seems to be working sufficiently well at this point, enough >> to get some useful

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Andreas Seltenreich
Hi, Ashutosh Sharma writes: >> the following query appears to reliably crash parallel workers on master >> as of 0832f2d. > As suggested, I have tried to reproduce this issue on *0832f2d* commit but > could not reproduce it. as Tom pointed out earlier, I had secretly set parallel_setup_cost

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

2016-11-21 Thread Tsunakawa, Takayuki
From: Robert Haas [mailto:robertmh...@gmail.com] > So there are two questions here: > > 1. Should we try to avoid having the stats collector write a stats file > during an immediate shutdown? The file will be removed anyway during crash > recovery, so writing it is pointless. I think you are

Re: [HACKERS] [PATCH] pgpassfile connection option

2016-11-21 Thread Mithun Cy
> Independently of your patch, while testing I concluded that the multi-host feature and documentation should be improved: > - If a connection fails, it does not say for which host/port. Thanks I will re-test same. > In fact they are tried in turn if the network connection fails, but not > if

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

2016-11-21 Thread Etsuro Fujita
On 2016/11/22 4:49, Tom Lane wrote: Etsuro Fujita writes: On 2016/11/10 5:17, Tom Lane wrote: I think there's a very good argument that we should just treat any inval in pg_foreign_data_wrapper as a reason to blow away the whole plan cache. People aren't going to

Re: [HACKERS] Re: [COMMITTERS] pgsql: autovacuum: Drop orphan temp tables more quickly but with more c

2016-11-21 Thread Michael Paquier
On Mon, Nov 21, 2016 at 4:57 PM, Tom Lane wrote: > Michael Paquier writes: >> On Mon, Nov 21, 2016 at 10:05 AM, Robert Haas wrote: >>> autovacuum: Drop orphan temp tables more quickly but with more caution. > >> I have found

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

2016-11-21 Thread Amit Kapila
On Mon, Nov 21, 2016 at 9:30 PM, Tom Lane wrote: > Amit Kapila writes: >> On Mon, Nov 21, 2016 at 6:10 PM, Amit Kapila wrote: >>> Here instead of checking whether top_plan has initPlan, it should >>> check whether initPlan is

Re: [HACKERS] Danger of automatic connection reset in psql

2016-11-21 Thread Pavel Stehule
2016-11-22 3:46 GMT+01:00 Robert Haas : > On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin > wrote: > > On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby > wrote: > >> > >> On 11/14/16 5:41 AM, Oleksandr Shulgin wrote: >

Re: [HACKERS] Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?

2016-11-21 Thread Craig Ringer
On 22 November 2016 at 11:35, Kyotaro HORIGUCHI wrote: > Hello, > > At Mon, 21 Nov 2016 21:39:07 -0500, Robert Haas wrote > in >> On Mon, Nov 21, 2016 at 3:21 AM, Craig

Re: [HACKERS] condition variables

2016-11-21 Thread Thomas Munro
On Tue, Nov 22, 2016 at 3:05 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Mon, 21 Nov 2016 15:57:47 -0500, Robert Haas wrote > in >> On Thu, Aug 11, 2016 at 5:47 PM,

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-21 Thread Haribabu Kommi
On Tue, Nov 22, 2016 at 5:33 AM, Robert Haas wrote: > On Sat, Nov 19, 2016 at 2:54 PM, Tom Lane wrote: > > Stephen Frost writes: > >> Let's create a new data type for this which supports old and new types, > >> add what casts make

Re: [HACKERS] patch: function xmltable

2016-11-21 Thread Pavel Stehule
2016-11-21 21:16 GMT+01:00 Tom Lane : > Alvaro Herrera writes: > > Something I just noticed is that transformTableExpr takes a TableExpr > > node and returns another TableExpr node. That's unlike what we do in > > other places, where the node

Re: [HACKERS] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

2016-11-21 Thread Tsunakawa, Takayuki
From: Craig Ringer [mailto:cr...@2ndquadrant.com] > You meant CheckTokenMembership(). Yes, my typo in the mail. > The proposed patch does need to be checked with: I understood you meant by "refuse to run" that postgres.exe fails to start below. Yes, I checked it on Win10. I don't have access

[HACKERS] Re: [COMMITTERS] pgsql: autovacuum: Drop orphan temp tables more quickly but with more c

2016-11-21 Thread Michael Paquier
On Mon, Nov 21, 2016 at 10:05 AM, Robert Haas wrote: > autovacuum: Drop orphan temp tables more quickly but with more caution. > > Previously, we only dropped an orphan temp table when it became old > enough to threaten wraparound; instead, doing it immediately. The > only

Re: [HACKERS] regression tests fails

2016-11-21 Thread Tom Lane
Pavel Stehule writes: >> 2016-11-21 8:09 GMT+01:00 Craig Ringer : >>> Simple fix here is to append COLLATE "C" after the ORDER BY. > here is a patch Pushed, thanks. regards, tom lane -- Sent via pgsql-hackers mailing

Re: [HACKERS] condition variables

2016-11-21 Thread Kyotaro HORIGUCHI
Hello, At Mon, 21 Nov 2016 15:57:47 -0500, Robert Haas wrote in > On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas wrote: > > So, in my > > implementation, a condition variable wait

Re: [HACKERS] Danger of automatic connection reset in psql

2016-11-21 Thread Robert Haas
On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin wrote: > On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby wrote: >> >> On 11/14/16 5:41 AM, Oleksandr Shulgin wrote: >>> >>> Automatic connection reset is a nice feature for server development,

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

2016-11-21 Thread Robert Haas
On Fri, Nov 18, 2016 at 3:23 PM, Peter Eisentraut wrote: > On 11/17/16 12:30 AM, Tsunakawa, Takayuki wrote: >> No, I'm not recommending a higher value, but just removing the doubtful >> sentences of 512MB upper limit. The advantage is that eliminating this >>

Re: [HACKERS] Parallel bitmap heap scan

2016-11-21 Thread Dilip Kumar
On Fri, Nov 18, 2016 at 9:59 AM, Amit Khandekar wrote: Thanks for the review.. > In pbms_is_leader() , I didn't clearly understand the significance of > the for-loop. If it is a worker, it can call > ConditionVariablePrepareToSleep() followed by >

Re: [HACKERS] Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?

2016-11-21 Thread Kyotaro HORIGUCHI
Hello, At Mon, 21 Nov 2016 21:39:07 -0500, Robert Haas wrote in > On Mon, Nov 21, 2016 at 3:21 AM, Craig Ringer wrote: > > I'm still interested in hearing comments from

Re: [HACKERS] Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

2016-11-21 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > I have tried using attached script multiple times on latest 9.2 code, but > couldn't reproduce the issue. Please find the log attached with this mail. > Apart from log file, below

Re: [HACKERS] WIP: multivariate statistics / proof of concept

2016-11-21 Thread Tomas Vondra
On 11/21/2016 11:10 PM, Robert Haas wrote: [ reviving an old multivariate statistics thread ] On Thu, Nov 13, 2014 at 6:31 AM, Simon Riggs wrote: On 12 October 2014 23:00, Tomas Vondra wrote: It however seems to be working sufficiently well at this

Re: [HACKERS] Logical decoding on standby

2016-11-21 Thread Craig Ringer
On 22 November 2016 at 10:20, Craig Ringer wrote: > I'm currently looking at making detection of replay conflict with a > slot work by separating the current catalog_xmin into two effective > parts - the catalog_xmin currently needed by any known slots >

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

2016-11-21 Thread Tsunakawa, Takayuki
From: Tom Lane [mailto:t...@sss.pgh.pa.us] > The point I was trying to make is that I think the forced-removal behavior > is not desirable, and therefore committing a patch that makes it be graven > in stone is not desirable either. I totally agree that we should pursue the direction for escaping

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

2016-11-21 Thread Haribabu Kommi
Hi Vinayak, This is a gentle reminder. you assigned as reviewer to the current patch in the 11-2016 commitfest. If you have any more review comments / performance results regarding the approach of the patch, please share it. Otherwise, you can mark the patch as "Ready for committer" for

Re: [HACKERS] Push down more full joins in postgres_fdw

2016-11-21 Thread Etsuro Fujita
On 2016/11/21 22:02, Ashutosh Bapat wrote: You wrote: Instead we should calculate tlist, the first time we need it and then add it to the fpinfo. I wrote: Having said that, I agree on that point. I'd like to propose (1) adding a new member to fpinfo, to store a list of output Vars from the

Re: [HACKERS] PoC: Partial sort

2016-11-21 Thread Haribabu Kommi
Hi Peter, This is a gentle reminder. you assigned as reviewer to the current patch in the 11-2016 commitfest. But you haven't shared your review yet in this commitfest on the latest patch posted by the author. If you don't have any comments on the patch, please move the patch into "ready for

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

2016-11-21 Thread Haribabu Kommi
On Fri, Nov 18, 2016 at 7:18 PM, Craig Ringer wrote: > The latest is what's attached upthread and what's in the git repo also > referenced upthread. > > I haven't been able to update in response to more recent review due to > other development commitments. At this point I

Re: [HACKERS] Proposal : For Auto-Prewarm.

2016-11-21 Thread Haribabu Kommi
Hi Ashutosh, This is a gentle reminder. you assigned as reviewer to the current patch in the 11-2016 commitfest. But you haven't shared your review yet. Please share your views about the patch. This will help us in smoother operation of commitfest. Please Ignore if you already shared your

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

2016-11-21 Thread Craig Ringer
On 22 November 2016 at 15:14, Haribabu Kommi wrote: > > On Fri, Nov 18, 2016 at 7:18 PM, Craig Ringer wrote: >> >> The latest is what's attached upthread and what's in the git repo also >> referenced upthread. >> >> I haven't been able to update

Re: [HACKERS] Patch: Implement failover on libpq connect level.

2016-11-21 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > I am very strict about regressing the performance of things that we already > have, but I try not to make a policy that a new feature must be as fast > as it could ever be. That could

Re: [HACKERS] Patch: Implement failover on libpq connect level.

2016-11-21 Thread Craig Ringer
On 21 November 2016 at 00:08, Mithun Cy wrote: >> Please avoid adding another round trip by using a GUC_REPORTed variable >> (ParameterStatus entry). If you want to support this libpq failover with >> >pre-10 servers, you can switch the method of determining the

Re: [HACKERS] delta relations in AFTER triggers

2016-11-21 Thread Craig Ringer
On 21 November 2016 at 15:05, Thomas Munro wrote: > After going through that experience, I now agree with Kevin: an > interface where a new SPI interface lets PLs push a named tuplestore > into the SPI connection to make it available to SQL seems like the >

Re: [HACKERS] Danger of automatic connection reset in psql

2016-11-21 Thread Oleksandr Shulgin
On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby wrote: > On 11/14/16 5:41 AM, Oleksandr Shulgin wrote: > >> Automatic connection reset is a nice feature for server development, >> IMO. Is it really useful for anything else is a good question. >> > > I use it all the time

Re: [HACKERS] Mail thread references in commits

2016-11-21 Thread Magnus Hagander
On Sun, Nov 20, 2016 at 11:02 PM, Andrew Dunstan wrote: > > > On 11/20/2016 11:34 AM, Magnus Hagander wrote: > >> >> >> >> I'm prepared to go along with this if there's general agreement. >> However, maybe we should make it actually work first, because I >> get a

Re: [HACKERS] Parallel execution and prepared statements

2016-11-21 Thread Albe Laurenz
Robert Haas wrote: >>/* creates a parallel-enabled plan */ >>PQprepare(conn, "pstmt", "SELECT id FROM l WHERE val = $1", 1, NULL); >>/* blows up with "cannot insert tuples during a parallel operation" */ >>PQexec(conn, "CREATE TABLE bad(id) AS EXECUTE pstmt('abcd')"); > > Ouch. I

Re: [HACKERS] Mail thread references in commits

2016-11-21 Thread Heikki Linnakangas
On 11/19/2016 06:38 PM, Tom Lane wrote: Andrew Dunstan writes: Every proposal along these lines strikes me as making more unobvious hoops for people to jump through. We're just reinventing the wheel here because we don't like the color of the standard wheels that some

Re: [HACKERS] Push down more full joins in postgres_fdw

2016-11-21 Thread Etsuro Fujita
On 2016/11/19 0:16, Ashutosh Bapat wrote: Also another point I guess, this note doesn't add much value in the given context. Probably we should remove it. +* Note: the tlist would have one-to-one correspondence with the +* joining relation's reltarget->exprs because (1)

Re: [HACKERS] Improvements in psql hooks for variables

2016-11-21 Thread Stephen Frost
Daniel, * Daniel Verite (dan...@manitou-mail.org) wrote: > Tom Lane wrote: > > > Stephen Frost writes: > > > In reviewing this patch, I also noticed that it's set up to assume a > > > 'true' result when a variable can't be parsed by ParseVariableBool. > > > > I

Re: [HACKERS] Improvements in psql hooks for variables

2016-11-21 Thread Stephen Frost
Daniel, * Daniel Verite (dan...@manitou-mail.org) wrote: > "make check" seems OK with that, I hope it doesn't cause any regression > elsewhere. You can see what the code coverage of psql is in our current regression tests by going here: http://coverage.postgresql.org/src/bin/psql/index.html

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

2016-11-21 Thread Amit Kapila
On Sun, Nov 20, 2016 at 10:43 PM, Andreas Seltenreich wrote: > Hi, > > the query below triggers a parallel worker assertion for me when run on > the regression database of master as of 0832f2d. The plan sports a > couple of InitPlan nodes below Gather. > I think the reason

Re: [HACKERS] Contains and is contained by operators of inet datatypes

2016-11-21 Thread Andreas Karlsson
On 11/17/2016 11:14 PM, Tom Lane wrote: The original post proposed that we'd eventually get some benefit by being able to repurpose << and >> to mean something else, but the time scale over which that could happen is so long as to make it unlikely to ever happen. I think we'd need to deprecate

Re: [HACKERS] Improvements in psql hooks for variables

2016-11-21 Thread Daniel Verite
Stephen Frost wrote: > Just fyi, there seems to be some issues with this patch because setting > my PROMPT1 and PROMPT2 variables result in rather odd behavior. Good catch! The issue is that the patch broke the assumption of prompt hooks that their argument points to a long-lived buffer.

Re: [HACKERS] Improvements in psql hooks for variables

2016-11-21 Thread Daniel Verite
Stephen Frost wrote: > Are you working to make those changes? I'd rather we make the changes > to this code once rather than push what you have now only to turn around > and change it significantly again. If, as a maintainer, you prefer this together in one patch, I'm fine with that. So

Re: [HACKERS] Improvements in psql hooks for variables

2016-11-21 Thread Stephen Frost
Daniel, * Daniel Verite (dan...@manitou-mail.org) wrote: > Stephen Frost wrote: > > > Are you working to make those changes? I'd rather we make the changes > > to this code once rather than push what you have now only to turn around > > and change it significantly again. > > If, as a

Re: [HACKERS] condition variables

2016-11-21 Thread Thomas Munro
On Fri, Oct 28, 2016 at 9:38 AM, Robert Haas wrote: > On Tue, Oct 4, 2016 at 3:12 PM, Thomas Munro > wrote: >> On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro >> wrote: >>> Please find attached a -v2 of your

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Ashutosh Sharma
Hi, > the following query appears to reliably crash parallel workers on master > as of 0832f2d. > > --8<---cut here---start->8--- > set max_parallel_workers_per_gather to 2; > set force_parallel_mode to 1; > > select subq.context from pg_settings, > lateral

Re: [HACKERS] Push down more full joins in postgres_fdw

2016-11-21 Thread Ashutosh Bapat
> > Yeah, I modified the patch so, as I thought that would be consistent with > the aggregate pushdown patch. aggregate pushdown needs the tlist to judge the shippability of targetlist. For joins that's not required, so we should defer, if we can. > >>> Instead we should calculate tlist, the >>>

Re: [HACKERS] How to change order sort of table in HashJoin

2016-11-21 Thread Man
Thanks for reply, sir. On 11/21/2016 1:39 AM, Tom Lane wrote: Man writes: Additional information. In 9.6 the second table (lesser tuple) was choosen (the same testdata). There are something (cost estimation?) different in previous versions. I'd bet on different

Re: [HACKERS] Improvements in psql hooks for variables

2016-11-21 Thread Daniel Verite
Tom Lane wrote: > Stephen Frost writes: > > In reviewing this patch, I also noticed that it's set up to assume a > > 'true' result when a variable can't be parsed by ParseVariableBool. > > I suppose that's meant to be backwards-compatible with the current > behavior:

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

2016-11-21 Thread Amit Kapila
On Mon, Nov 21, 2016 at 7:46 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila >> > shared_buffers tps >> > 256MB 990 >> > 512MB 813 >> > 1GB 1189 >> > 2GB 2258 >>

Re: [HACKERS] Parallel execution and prepared statements

2016-11-21 Thread Tobias Bussmann
> True, but we also try to avoid it whenever possible, because it's > likely to lead to poor performance. This non-readonly case should be way less often hit compared to other uses of prepared statements. But sure, it depends on the individual use case and a likely performance regession in

Re: [HACKERS] condition variables

2016-11-21 Thread Robert Haas
On Mon, Nov 21, 2016 at 7:10 AM, Thomas Munro wrote: >> I wonder if we shouldn't try to create the invariant that when the CV >> mutex is not help, the state of cvSleeping has to be true if we're in >> the proclist and false if we're not. So

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

2016-11-21 Thread Amit Kapila
On Mon, Nov 21, 2016 at 6:10 PM, Amit Kapila wrote: > On Sun, Nov 20, 2016 at 10:43 PM, Andreas Seltenreich > wrote: >> Hi, >> >> the query below triggers a parallel worker assertion for me when run on >> the regression database of master as of

[HACKERS] Better handling of UPDATE multiple-assignment row expressions

2016-11-21 Thread Tom Lane
While fooling around trying to document the behavior of *-expansion, I got annoyed about the fact that it doesn't work in the context of UPDATE tab SET (c1,c2,c3) = (x,y,z) ... The righthand side of this is a row-expression according to the SQL standard, and "foo.*" would be expanded in

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

2016-11-21 Thread Robert Haas
On Sun, Nov 20, 2016 at 8:53 AM, Andreas Seltenreich wrote: > the following query appears to reliably crash parallel workers on master > as of 0832f2d. > > --8<---cut here---start->8--- > set max_parallel_workers_per_gather to 2; > set

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

2016-11-21 Thread Tom Lane
Amit Kapila writes: > On Mon, Nov 21, 2016 at 6:10 PM, Amit Kapila wrote: >> Here instead of checking whether top_plan has initPlan, it should >> check whether initPlan is present anywhere in plan tree. I think one >> simple way could be to

[HACKERS] postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer

2016-11-21 Thread Vladimir Svedov
Hi, I have this question. Looked for a help on http://dba.stackexchange.com/ No success. Maybe you can answer?.. Thank you in advance "FOREIGN_TABLE" created with postgres_fdw. LOCAL_TABLE is just a local table... Symptoms: 1. I run in psql query SELECT * from FOREIGN_TABLE. No log

  1   2   >