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

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] Patch: Implement failover on libpq connect level.

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: Batch/pipelining support for libpq

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] Proposal : For Auto-Prewarm.

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

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] PoC: Partial sort

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] Push down more full joins in postgres_fdw

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] New SQL counter statistics view (pg_stat_sql)

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] [RFC] Should we fix postmaster to avoid slow shutdown?

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] Logical decoding on standby

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] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

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] [PATCH] pgpassfile connection option

> 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] [RFC] Should we fix postmaster to avoid slow shutdown?

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] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

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

Re: [HACKERS] patch: function xmltable

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] condition variables

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

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] Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?

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] Danger of automatic connection reset in psql

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] WIP: multivariate statistics / proof of concept

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] Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?

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] Parallel bitmap heap scan

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: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

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] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

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] Contains and is contained by operators of inet datatypes

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] Remove the comment on the countereffectiveness of large shared_buffers on Windows

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] Danger of automatic connection reset in psql

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] Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?

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] condition variables

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] regression tests fails

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] Re: [COMMITTERS] pgsql: autovacuum: Drop orphan temp tables more quickly but with more c

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] [WIP] [B-Tree] Keep indexes sorted by heap physical location

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] Re: [COMMITTERS] pgsql: autovacuum: Drop orphan temp tables more quickly but with more c

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

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

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] Improve OOM handling in pg_locale.c

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

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] [sqlsmith] Parallel worker crash on seqscan

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] [sqlsmith] Parallel worker crash on seqscan

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

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] WIP: multivariate statistics / proof of concept

[ 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] postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer

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] Fun fact about autovacuum and orphan temp tables

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] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

> > 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] condition variables

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] [WIP] [B-Tree] Keep indexes sorted by heap physical location

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] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

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] [RFC] Should we fix postmaster to avoid slow shutdown?

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] Postgres abort found in 9.3.11

"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] [RFC] Should we fix postmaster to avoid slow shutdown?

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

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] Postgres abort found in 9.3.11

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] patch: function xmltable

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_fdw : altering foreign table not invalidating prepare statement execution plan.

[ 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] Logical decoding on standby

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] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

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] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

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

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] Patch: Implement failover on libpq connect level.

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] Patch to implement pg_current_logfile() function

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] macaddr 64 bit (EUI-64) datatype support

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

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] [sqlsmith] Parallel worker crash on seqscan

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] Patch to implement pg_current_logfile() function

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

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] Fun fact about autovacuum and orphan temp tables

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

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] [sqlsmith] Parallel worker crash on seqscan

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] DECLARE STATEMENT setting up a connection in ECPG

> 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] [WIP] [B-Tree] Keep indexes sorted by heap physical location

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] [sqlsmith] Parallel worker crash on seqscan

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] delta relations in AFTER triggers

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] delta relations in AFTER triggers

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] Vacuum: allow usage of more than 1GB of work mem

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] [sqlsmith] Parallel worker crash on seqscan

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] delta relations in AFTER triggers

Thanks for the review! Will respond further after reviewing your suggested patches; this is a quick response just to the contents of the email. On Mon, Nov 21, 2016 at 1:05 AM, Thomas Munro wrote: > Both ways have attracted criticism: the first involves touching

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

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 need to be passed into the parallel workers at >> runtime. Do we have code

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

On Mon, Nov 21, 2016 at 11:43 AM, Tom Lane wrote: > I wrote: >> Like Ashutosh, I can't reproduce the crash, so it's hard to speculate much >> further. > > Ah-hah: now I can. The recipe lacks these important steps: > > set parallel_setup_cost TO 0; > set parallel_tuple_cost TO

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

I wrote: > Like Ashutosh, I can't reproduce the crash, so it's hard to speculate much > further. Ah-hah: now I can. The recipe lacks these important steps: set parallel_setup_cost TO 0; set parallel_tuple_cost TO 0; That changes the plan to Limit (cost=0.00..0.06 rows=1 width=64) ->

Re: [HACKERS] Improvements in psql hooks for variables

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. So I went through the psql commands which don't fail on parse errors for booleans.

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

Robert Haas writes: > Then again, that might just be a coincidence. The other thing that's > weird here is that the Datum being passed is apparently a NULL > pointer, which neither MakeExpandedObjectReadOnly() nor > MakeExpandedObjectReadOnlyInternal() are prepared to deal

Re: [HACKERS] Parallel execution and prepared statements

Am 18.11.2016 um 14:21 schrieb Albe Laurenz : > But then the change to use CURSOR_OPT_PARALLEL_OK in tcop/postgres.c should > be reverted as well, because it breaks things just as bad: > > /* creates a parallel-enabled plan */ > PQprepare(conn, "pstmt", "SELECT id

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

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

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

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

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

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

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

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

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

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] condition variables

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] Parallel execution and prepared statements

> 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] Improvements in psql hooks for variables

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] Improvements in psql hooks for variables

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] Improvements in psql hooks for variables

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

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

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

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] How to change order sort of table in HashJoin

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] Push down more full joins in postgres_fdw

> > 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] Contains and is contained by operators of inet datatypes

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] Remove the comment on the countereffectiveness of large shared_buffers on Windows

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] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

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] Push down more full joins in postgres_fdw

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)

  1   2   >