On Sat, Oct 17, 2015 at 4:54 PM, Robert Haas wrote:
>
> On Sat, Oct 17, 2015 at 2:44 AM, Amit Kapila
wrote:
> > I am not denying from that fact, the point I wanted to convey here is
that
> > the logic guarded by "params != estate->paramLI" in plpgsql_param_fetch
> > is only needed if cursors are
On 10/17/2015 06:17 PM, Robert Haas wrote:
However, I'm pretty sure that we don't want to switch the *entire*
buildfarm to using lots of unnecessary parallelism. What we might be
able to do is have some critters that people spin up for this precise
purpose. Just like we currently have CLOBB
* Noah Misch (n...@leadboat.com) wrote:
> On Sat, Oct 17, 2015 at 06:17:37PM -0400, Robert Haas wrote:
> > people are willing to run critters in that mode, I will be happy -
> > more than happy, really - to put the test code into committable form,
> > guarded by a #define, and away we go.
>
> I wo
On Sat, Oct 17, 2015 at 06:17:37PM -0400, Robert Haas wrote:
> One idea that I think would provide
> *excellent* test coverage is to take the test code included on this
> thread and run it on the buildfarm. The idea of the code is to
> basically run the regression test suite with every parallel-el
On Sat, Oct 17, 2015 at 9:16 AM, Simon Riggs wrote:
> From reading this my understanding is that there isn't a test suite included
> with this commit?
Right. The patches on the thread contain code that can be used for
testing, but the committed code does not itself include test coverage.
I welco
On Sat, Oct 17, 2015 at 12:26 PM, Andrew Dunstan wrote:
> I have done this and everything seems to be working. In the RedisFDW case,
> it does process certain quals (those in the form "key" = ), but it
> has been doing the same thing in redisGetForeignPlan as filefdw does in
> fileGetForeignPlan,
On 2015-10-02 22:02, Robert Haas wrote:
On Fri, Oct 2, 2015 at 2:59 PM, Alvaro Herrera wrote:
Robert Haas wrote:
The standby can have the feature enabled even though the master has it
disabled? That seems like it can only lead to heartache.
Can you elaborate?
Sort of. Our rule up until n
Andres Freund wrote:
> On 2015-10-14 17:33:01 +0900, Kyotaro HORIGUCHI wrote:
> > If I recall correctly, he concerned about killing the backends
> > running transactions which could be saved. I have a sympathy with
> > the opinion.
>
> I still don't. Leaving backends alive after postmaster has die
On Oct 17, 2015, at 10:57 AM, Andres Freund wrote:
>> Rough patch for the extensible, backpatchable, non-invasive proposal
>> attached.
>
> This just doesn't make any sense. This way npgsql setting that flag can't be
> released before a new set of backbranch releases are in widespread use.
> Ot
On 07/30/2015 09:51 AM, Tom Lane wrote:
> Joe Conway writes:
>> What about just TYPE then?
>
>> SELECT x::TYPE(some_expression) FROM ...
>> SELECT CAST (x AS TYPE(some_expression)) FROM ...
> The main limitation of this patch is that it won't work for call sites
> that pass pstate == NUL
but the implementation is pretty ugly :( - I didn't write C extensions for
> Python before, and the extending exception class with some methods isn't
> well supported and well documented.
>
here is new patch
cleaned, all unwanted artefacts removed. I am not sure if used way for
method registratio
2015-10-17 18:42 GMT+02:00 Jim Nasby :
> On 10/15/15 11:51 PM, Pavel Stehule wrote:
>
>> I don't think so ignoring NULL in RAISE statement is good idea (it is
>> not safe). We can replace NULL by some string (like "NULL") by default.
>> I am thinking about other possibilities.
>>
>
> What I was tr
On 10/15/15 11:51 PM, Pavel Stehule wrote:
I don't think so ignoring NULL in RAISE statement is good idea (it is
not safe). We can replace NULL by some string (like "NULL") by default.
I am thinking about other possibilities.
What I was trying to say is that if the argument to a USING option is
On 10/16/15 10:04 AM, Robert Haas wrote:
On Thu, Oct 15, 2015 at 8:28 PM, Jim Nasby wrote:
It's just how the authors of pg_repack decided to handle it. It seems pretty
reasonable, since you probably don't want an errant DDL statement to cause
the rollback of hours or days of pg_repack work.
Ul
On 10/16/2015 02:19 PM, Andrew Dunstan wrote:
On 10/16/2015 11:13 AM, Robert Haas wrote:
Andrew,
The FileTextArrayFDW-build failure on crake, and the RedisFDW-build
failure on sittella, are expected results of my commit
5043193b78919a1bd144563aadc2f7f726549913. If those FDWs do not push
qu
On 10/16/2015 10:03 PM, Tom Lane wrote:
I wrote:
This seems like a very Rube-Goldbergian way of setting up a local
namespace for the user-defined code. I think perhaps what we should do
is:
1. Compile the user-supplied code directly into a code object, without
wrapping it in a "def". (Hence,
On 10/16/15 12:51 PM, Andres Freund wrote:
>Hmmm, do you mean essentially skip the "GRANT postgres to joe" and use a
>SECURITY DEFINER C function that does the set role to postgres under the
>covers with "GRANT EXECUTE on FUNCTION elevate_user() to joe"?
Yes.
>Being able to use something like
On October 17, 2015 4:18:50 PM GMT+02:00, Simon Riggs
wrote:
>On 17 October 2015 at 14:39, Tom Lane wrote:
>
>> Andres Freund writes:
>> > Having to backpatch a new parameter to all supported versions seems
>far
>> > more invasive than adding a guc that can only be set to one value.
>>
>> Indee
On Sat, Oct 17, 2015 at 4:45 AM, Robert Haas wrote:
> On Fri, Oct 16, 2015 at 2:52 PM, Peter Eisentraut wrote:
> > The release notes say that checkpoint_segments has been replaced by
> > max_wal_size and min_wal_size, but there is no indication on how to
> > convert between the old and new setti
On 17 October 2015 at 14:39, Tom Lane wrote:
> Andres Freund writes:
> > Having to backpatch a new parameter to all supported versions seems far
> > more invasive than adding a guc that can only be set to one value.
>
> Indeed. It is completely stupid to do this in any other way except
> by rei
On Friday, October 16, 2015, Tom Lane wrote:
>
> Anyway, I'm not planning to do much more work on this right now, but
> I thought I'd throw it out there just to let people know that this seems
> within reach. I'm curious to know how many people care, and how much.
>
>
+1
It's hard to quantify h
Amit Kapila writes:
> On Sat, Oct 17, 2015 at 12:07 AM, Robert Haas wrote:
>> Maybe we need to be using PostmasterRandom() rather than random() for
>> the control segment name.
> +1. Though I think it is better to investigate the actual cause before
> doing this.
BackendRun() deliberately prev
Simon Riggs writes:
> On 16 October 2015 at 20:17, Robert Haas wrote:
- DDL deparsing testing module should have detected that transforms
were not supported, but it failed to notice that. There's no thread
linked to this one either, but the description of the issue seems
clea
Andres Freund writes:
> Having to backpatch a new parameter to all supported versions seems far
> more invasive than adding a guc that can only be set to one value.
Indeed. It is completely stupid to do this in any other way except
by reinstating ssl_renegotiation_limit as an ordinary GUC variab
On 12 October 2015 at 18:04, Robert Haas wrote:
> My recent commit of the Gather executor node has made it relatively
> simple to write code that does an end-to-end test of all of the
> parallelism-relate commits which have thus far gone into the tree.
>
I've been wanting to help here for a whi
On 17 October 2015 at 13:27, Andres Freund wrote:
> On 2015-10-17 12:49:17 +0100, Simon Riggs wrote:
> > Agreed, but I don't like the idea of hardcoding something so horribly
> > specific into the server.
>
> What's that specific about accepting the value for 'disabled' for a
> feature that's not
On 2015-10-17 12:49:17 +0100, Simon Riggs wrote:
> Agreed, but I don't like the idea of hardcoding something so horribly
> specific into the server.
What's that specific about accepting the value for 'disabled' for a
feature that's not supported anymore?
> I'd rather the driver added "driver=npgs
On 16 October 2015 at 20:17, Robert Haas wrote:
>> - DDL deparsing testing module should have detected that transforms
> >> were not supported, but it failed to notice that. There's no thread
> >> linked to this one either, but the description of the issue seems
> >> clear enough. Alvaro, any c
On 16 October 2015 at 14:41, Shay Rojansky wrote:
>
>> If not, the only solution I can see is for PostgreSQL to not protest if
>> it sees the
>> parameter in the startup packet.
>>
>
> Yeah, that's the ideal solution here as far as I'm concerned.
>
Agreed, but I don't like the idea of hardcoding
On Sat, Oct 17, 2015 at 2:15 AM, Amit Kapila wrote:
> Agreed and on looking at code, I think in below code, if we pass
> parallelOK as true for the cases where Portal is non-null, such a
> problem could happen.
>
> and one such case is
>
> exec_stmt_return_query()
> {
> ..
>
> if (stmt->query != N
On Sat, Oct 17, 2015 at 2:44 AM, Amit Kapila wrote:
> I am not denying from that fact, the point I wanted to convey here is that
> the logic guarded by "params != estate->paramLI" in plpgsql_param_fetch
> is only needed if cursors are in use otherwise we won't need them even
> for parallel query.
On Sat, Oct 17, 2015 at 12:07 AM, Robert Haas wrote:
>
> On Thu, Oct 15, 2015 at 11:32 PM, Amit Kapila
wrote:
> > Another some what related point is currently we are using random()
> > function to ensure a unique name for dsm and it seems to me that
> > it is always going to generate same number
On Oct 17, 2015 12:53 AM, "Tom Lane" wrote:
>
> I've occasionally heard complaints that our regex engine only has
> lookahead constraints not lookbehind constraints, while Perl's for example
> does have those. While I was fooling around with the other issues in that
> code, I learned enough to re
33 matches
Mail list logo
