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 primary based
>> on the server ve
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
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 in response to more recent review due to
>> other d
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 revie
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 doubt I'll be able to
>
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 com
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 s
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 committer
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
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
> (ProcArray->replication_slot_catalog_xmin,
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 alter FDW-level options often
> 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 t
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 rig
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
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 returned is of a different type than the
> > input no
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, Robert Haas wrote:
>> > So, in my
>> > implementation, a condition variable wait loop looks like this:
>> >
>> > for (;;)
>> > {
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 sense, and call it a day. Changing the data type
> >> name out
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 Ringer wrote:
>> > I'm still interested in hearing comments from experienced folks about
>> > whether it's sane to do this at
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:
> >>>
> >>> Automatic connection reset is a nice feature for server development,
>
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 point, enough
to get some useful feedback.
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 experienced folks about
> > whether it's sane to do this at all, rather than have similar
> > duplicate signal handling for t
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
> ConditionVariableSleep(). Once it comes out of
>
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 prin
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 present anywhere in plan tree. I think one
>>> simple way could be to
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 that it would be nice t
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
>> sentence will make a chance for use
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,
>>> IMO. Is it really useful for anything else is a good
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 share code in a given sit
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 loop looks like this:
> >
> > for (;;)
> > {
> > ConditionVariablePrepareToSleep(cv);
> > if (condition for
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 list (pgsql-hackers@postgresql.org)
To make changes
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 an obvious bug when reading the code this morning:
>> orphan_failures i
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 still behave like NULL
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 initialized:
My compiler noticed that, too. Will
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 value of waiting is tha
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 error while encoding in
> db_encoding_strdup.
> Unless yo
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 other locale than we w
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
--
Sent via pgsql-ha
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 reproduce it.
>
> as To
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 and
[ 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 feedback. So here we go.
>
> This looks interes
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
> table...
>
> Symptoms:
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.
--
Michael
--
Sent v
>
> 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
> like
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;
> ConditionVariableSleep();
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 anything in the internal pages.
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 *
>> FROM dblink('bob_srv
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 forced-removal behavior
is not des
"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 people to try?
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 seconds anyway, which is
> unexpected
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 clear what happens if you try t
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
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 a
[ 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 aren't going to alter FDW-level op
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 (pgsql
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 integer);
> psql:bug_example
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';
> CREATE ROLE
> CREATE SERVER b
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 especially for concealing and preserving
>>>
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 you
> forgive the additional ro
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 for the new feature as a
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 not helping anyone.
>
> +1. I do not think
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 secure place of storage
>>
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 found the entire querytree to be parallel-s
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
>> patches about GUC changes because I'm n
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 tlist,
>> and we're som
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 just for the sake of
>>> paranoia, but I don't think it is. Failures here won'
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
>>> wrote:
Attached is patch 0002 with pgindent applied over it
>>
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 (
> 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.
A
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 going to suggest some more
> things that need
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 transmit runtime param values to the worker,
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 definition:
>
> a : a hiding pla
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 especially for concealing
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 it
>>>
>>> I don't think there's any other formatting issue, but feel f
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 need to be passed into the parallel workers at
>>> runtime. Do we
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
> basically every core function
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 for that at all? If so where is it?
> No, th
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 0;
>
> That changes
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)
-> Nest
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.
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 with. I
> don't know wh
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 FROM l WHERE val = $1", 1, NU
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 generated
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 check *glob->subplans* instead of
>> top_plan->initPlan
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 0832f2d. The plan sports a
>> couple of InitPlan no
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 force_parallel_mode to 1;
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 any
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 ConditionVariableSignal()
>> would clear the flag befor
> 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 thes
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 main
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
It'
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
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.
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 suppose that's meant to be
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:
>
> regression=# \t
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 statistics in the two installa
>
> 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
>>>
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 t
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
>> > 4GB 5003
>> > 8GB 5062
>> >
>
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 of this issue is that
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) t
1 - 100 of 112 matches
Mail list logo