On Wed, Sep 23, 2015 at 7:29 PM, Tom Lane wrote:
> Removing that entirely would be quite incorrect, because then you'd be
> lying to the parent node about what collation your node outputs.
>
Yes. I too thought so and thus wanted to fix that code block by
considering the default collation.
>
>
> And email integration for Jira is nonexistant.
That is not true. We do have an email integration where customers can create
issues by sending an email to a specific "Jira Email" address. And as far as
I know this is a standard module from Atlassian. I _think_ it can also be
configured that you
On 23 September 2015 at 17:11, David Rowley
wrote:
> find_foreign_key_clauses() should look for the longest match and return a
> Bitmap set of the list indexes to the caller.
> It might be possible to fool the longest match logic by duplicating
> clauses, e.g. a1 = b1 AND a1 = b1 and a1 = b1 AND
On 22 September 2015 at 23:52, Rahul Goel wrote:
> Hi
>
> I am facing the below issue in setting up BDR:
Hi.
Please direct questions about using and setting up BDR to
pgsql-general, not pgsql-hackers.
Thanks.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Developme
On Thu, Sep 24, 2015 at 1:31 PM, Joe Conway wrote:
> On 09/23/2015 05:21 PM, Thomas Munro wrote:
>> Do you think it would make any sense to consider evolving what we have
>> already? At the moment, we have a bug form, and when you submit it it
>> does this (if I'm looking at the right thing, plea
Josh Berkus wrote:
> When we discussed this 8 years ago, Debian said debbugs wasn't ready for
> anyone else to use. Has that changed?
Emacs uses debbugs now, so there's at least one non-Debian user.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppo
On Thu, Sep 3, 2015 at 6:21 AM, Amit Kapila wrote:
> [ new patches ]
Still more review comments:
+ /* Allow space for terminating zero-byte */
+ size = add_size(size, 1);
This is pointless. The length is already stored separately, and
> Sent: Thursday, September 24, 2015 at 3:11 AM
>
> From: "Tom Lane"
> Robert Haas writes:
> > Well, I think that if we create our own mini-language, it may well be
> > possible to make the configuration for this compact enough to fit on
> > one line. If we use JSON, I think there's zap chance o
On 09/23/2015 05:21 PM, Thomas Munro wrote:
> Do you think it would make any sense to consider evolving what we have
> already? At the moment, we have a bug form, and when you submit it it
> does this (if I'm looking at the right thing, please correct me if I'm
> not):
>
> http://git.postgresql.o
On Thu, Sep 24, 2015 at 11:33 AM, Josh Berkus wrote:
> On 09/23/2015 03:05 PM, Jim Nasby wrote:
>> On 9/23/15 3:12 PM, Thomas Kellerer wrote:
>>> They also support Postgres as their backend (and you do find hints
>>> here and
>>> there
>>> that it is the recommended open source DBMS for them - but
Robert Haas writes:
> Well, I think that if we create our own mini-language, it may well be
> possible to make the configuration for this compact enough to fit on
> one line. If we use JSON, I think there's zap chance of that. But...
> that's just what *I* think.
Well, that depends on what you
On Wed, Sep 23, 2015 at 12:11 AM, Amir Rohan wrote:
> It seems like:
> 1) There's a need to support structured data in configuration for future
> needs as well, it isn't specific to this feature.
> 2) There should/must be a better way to validate configuration then
> to restarting the server in se
On 09/23/2015 03:05 PM, Jim Nasby wrote:
> On 9/23/15 3:12 PM, Thomas Kellerer wrote:
>> They also support Postgres as their backend (and you do find hints
>> here and
>> there
>> that it is the recommended open source DBMS for them - but they don't
>> explicitly state it like that). We are using J
I wrote:
> However, in the case at hand, the complaint basically is why aren't we
> treating the boolean function expression like a boolean variable, and
> looking to see if there are stats available for it, like this other
> bit in clause_selectivity:
> /*
> * A Var at th
Robert Haas writes:
> On Wed, Sep 23, 2015 at 5:39 PM, Tom Lane wrote:
>> Yeah, though I think of that as a longer-term issue, ie we could clean it
>> up sometime later.
> So, you're thinking of something as simple as the attached?
Right. I'll make a mental to-do to see about getting rid of se
On Wed, Sep 23, 2015 at 5:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> But if we're sure we don't want to support that, changing the behavior
>> of the read routines would be fine with me, too. It would even save a
>> few cycles. Would you also want to rip out the stuff that fixes up
>> opfu
Alvaro Herrera writes:
> Tom Lane wrote:
>> Personally I think Alvaro's position is unduly conservative: to the extent
>> that plans change it'd likely be for the better. But I'm not excited
>> enough to fight hard about it.
> I don't really care enough. We have received some complaints about
>
On 9/23/15 3:29 PM, Alvaro Herrera wrote:
Joshua D. Drake wrote:
Until that happens asking anyone to put resources into this idea is just not
worth it.
I wonder if you still have this conversation archived:
Date: Thu, 10 May 2007 11:30:55 -0400
From: Andrew Dunstan
To: "Joshua D. Drake", Ma
>> Personally I'd also change sending patches in emails to github pull
>> requests :).
>
> That won't happen, at least not this decade.
FWIW, a year ago I might have agreed that a github pull-request would
be preferable. However, since, I have grown to really like the patch
via email approach. I
On 9/23/15 3:12 PM, Thomas Kellerer wrote:
They also support Postgres as their backend (and you do find hints here and
there
that it is the recommended open source DBMS for them - but they don't
explicitly state it like that). We are using Jira at the company I work for
and
all Jira installations
Szymon,
* Szymon Lipiński (mabew...@gmail.com) wrote:
> a couple of days ago I was reading through the tickets in the Django bug
> tracker. It was much easier to find any information about the things to
> work on than currently for Postgres.
I tend to doubt that a bug tracker would change that si
Robert Haas writes:
> But if we're sure we don't want to support that, changing the behavior
> of the read routines would be fine with me, too. It would even save a
> few cycles. Would you also want to rip out the stuff that fixes up
> opfuncid as dead code? I assume yes, but sometimes I assume
On Wed, Sep 23, 2015 at 4:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> readfuncs.c deliberately ignores any opfuncid read in for an OpExpr,
>> DistinctExpr, NullIfExpr, or ScalarArrayOpExpr, instead resetting the
>> value in the newly-created node to InvalidOid. This is because it
>> assumes
Tomas Vondra writes:
> On 09/11/2015 07:16 PM, Robert Haas wrote:
>> On Fri, Sep 11, 2015 at 1:12 PM, Tomas Vondra
>> wrote:
>>> I'm arguing for fixing the existing bug, and then addressing the case of
>>> over-estimation separately, with proper analysis.
>> Well, this is part of how we're looki
On Wed, Sep 23, 2015 at 5:10 PM, Szymon Lipiński wrote:
>
>
> On 23 September 2015 at 22:07, Stephen Frost wrote:
>
>> * Josh Berkus (j...@agliodbs.com) wrote:
>> > On 09/23/2015 11:18 AM, Kam Lasater wrote:
>> > > At this point not having one is borderline negligent. I'd suggest:
>> > > Github
Szymon Lipiński wrote:
> Then I need to read through the emails. This is not user friendly too, as I
> need to click through the email tree, and if an email has multiple replies,
> it is usually hard not to omit some of them, as after going into a reply, I
> need to click to get to the parent mail
On Wed, Sep 23, 2015 at 5:00 PM, Stephen Frost wrote:
> Kam,
>
> * Kam Lasater (c...@seekayel.com) wrote:
> > > ... The above-referenced individuals
> > > would be the bug tracking system curators, of course. Unless it's got
> > > serious technical issues, the infrastructure team will do our bes
Jeff Janes wrote:
> For whatever it is worth, one of the frustrations I've had with projects
> (other than PostgreSQL) of which I am a casual users is that reporting a
> single bug meant signing up for yet another account on yet another site and
> learning yet another bug tracking system.
Right.
On 23 September 2015 at 22:07, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
> > On 09/23/2015 11:18 AM, Kam Lasater wrote:
> > > At this point not having one is borderline negligent. I'd suggest:
> > > Github Issues, Pivotal Tracker or Redmine (probably in that order).
> > > Th
On Wed, Sep 23, 2015 at 11:43 AM, Robert Haas wrote:
> On Wed, Sep 23, 2015 at 2:30 PM, Kam Lasater wrote:
> > Thanks for the suggestion. However, an issue tracker is not a
> > replacement for mailing list(s) and vice versa. They are both
> > necessary for success.
>
> I venture to say that we a
Kam,
* Kam Lasater (c...@seekayel.com) wrote:
> > ... The above-referenced individuals
> > would be the bug tracking system curators, of course. Unless it's got
> > serious technical issues, the infrastructure team will do our best to
> > support the choice. On the other hand, some of us would l
> > We have to use something OSS; open source projects depending on
> > closed-source infra is bad news. Out of what's available, I'd actually
> > choose Bugzilla; as much as BZ frustrates the heck out of me at times,
> > it's the only OSS tracker that's at all sophisticated.
Josh,
I'm not sure
On 9/22/15 6:27 PM, Jim Nasby wrote:
+ ereport(LOG,
+ (errcode(ERRCODE_OUT_OF_MEMORY),
+ errmsg("out of memory attempting to pg_stat_statement
file"),
+ errdetail("file \"%s\": size %lld", PGSS_TEXT_FILE,
stat.st_size)));
Uh, what?
Oops. I'll fix that a
On 9/22/15 8:01 PM, Peter Geoghegan wrote:
I'm doubtful that this had anything to do with MaxAllocSize. You'd
certainly need a lot of bloat to be affected by that in any way. I
wonder how high pg_stat_statements.max was set to on this system, and
how long each query text was on average.
max was
Robert Haas writes:
> readfuncs.c deliberately ignores any opfuncid read in for an OpExpr,
> DistinctExpr, NullIfExpr, or ScalarArrayOpExpr, instead resetting the
> value in the newly-created node to InvalidOid. This is because it
> assumes we're reading the node from a pg_node_tree column in som
Joshua D. Drake wrote:
> Until that happens asking anyone to put resources into this idea is just not
> worth it.
I wonder if you still have this conversation archived:
Date: Thu, 10 May 2007 11:30:55 -0400
From: Andrew Dunstan
To: "Joshua D. Drake", Magnus Hagander, Alvaro Herrera, Robert Trea
> We have to use something OSS; open source projects depending on
> closed-source infra is bad news. Out of what's available, I'd actually
> choose Bugzilla; as much as BZ frustrates the heck out of me at times,
> it's the only OSS tracker that's at all sophisticated.
There are several OSS projec
* Josh Berkus (j...@agliodbs.com) wrote:
> On 09/23/2015 11:18 AM, Kam Lasater wrote:
> > At this point not having one is borderline negligent. I'd suggest:
> > Github Issues, Pivotal Tracker or Redmine (probably in that order).
> > There are tens to hundreds of other great ones out there, I'm sure
On 09/23/2015 11:43 AM, Robert Haas wrote:
> If somebody does do the work, then we get to the next question: if we
> had an accurate list of open bugs, would anybody who currently doesn't
> work on fixing those bugs step up to help fix them? I hope so, but I
> don't know. If not, we might not fee
On 09/23/2015 11:18 AM, Kam Lasater wrote:
>
> At this point not having one is borderline negligent. I'd suggest:
> Github Issues, Pivotal Tracker or Redmine (probably in that order).
> There are tens to hundreds of other great ones out there, I'm sure one
> of them would also work.
First, unders
On 09/23/2015 11:33 AM, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Kam Lasater wrote:
I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also work.
On 09/23/2015 11:23 AM, Alvaro Herrera wrote:
Kam Lasater wrote:
I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also work.
If you install debbugs and feed it from our lists,
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
> I'm testing the new row-level security feature. I'm not clear on the
> difference between the USING and CHECK clauses in the CREATE POLICY
> statement.
>
> The documentation says:
>
> """
> A policy grants the ability to SELECT, INSERT, UPDAT
readfuncs.c deliberately ignores any opfuncid read in for an OpExpr,
DistinctExpr, NullIfExpr, or ScalarArrayOpExpr, instead resetting the
value in the newly-created node to InvalidOid. This is because it
assumes we're reading the node from a pg_node_tree column in some
system catalog, and if in t
On 9/23/15 2:52 PM, Stephen Frost wrote:
>> That might be reasonable, but the documentation is completely wrong
>> about that.
>
> Really? I feel pretty confident that it's at least mentioned. I
> agree that it should be made more clear.
I quoted the documentation at the beginning of the thread
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Robert Haas wrote:
> > On Wed, Sep 23, 2015 at 2:39 PM, Stephen Frost wrote:
> > > * Robert Haas (robertmh...@gmail.com) wrote:
> > >> On Wed, Sep 23, 2015 at 12:01 PM, Stephen Frost
> > >> wrote:
> > >> > * Robert Haas (robertmh...@gmail.com)
Robert Haas wrote:
> On Wed, Sep 23, 2015 at 2:39 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Wed, Sep 23, 2015 at 12:01 PM, Stephen Frost wrote:
> >> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> >> My expectation would have been:
> >> >>
> >> >> If yo
On 2015-09-23 15:57:02 -0300, Alvaro Herrera wrote:
> I think we need to make a decision here. Is this a terribly serious
> bug/misdesign that needs addressing?
Imo yes. Not sure about terribly, but definitely serious. It's several
data loss bugs in one package.
> If so, we need to backpatch. I
Andres Freund wrote:
> On 2015-09-23 15:03:05 -0300, Alvaro Herrera wrote:
> > Honestly, I wonder whether this message
> > ereport(LOG,
> > (errmsg("performing legacy multixact
> > truncation"),
> > errde
* Zhaomo Yang (zmp...@gmail.com) wrote:
> > Just a side-note, but your mail client doesn't seem to get the quoting
> > quite right sometimes, which can be confusing. Not sure if there's
> > anything you can do about it but wanted to let you know in case there
> > is.
>
> Sorry about this. From no
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 9/23/15 11:05 AM, Stephen Frost wrote:
> > That the USING policy is used if WITH CHECK isn't defined? That was
> > simply done to make policy management simple as in quite a few cases
> > only one policy is needed. If a WITH CHECK was always requir
On 2015-09-23 15:03:05 -0300, Alvaro Herrera wrote:
> The comment on top of TrimMultiXact states that "no locks are needed
> here", but then goes on to grab a few locks.
Hm. Yea. Although that was the case before.
> It's a bit odd that SetMultiXactIdLimit has the "finishedStartup" test
> so low.
On Wed, Sep 23, 2015 at 2:39 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Sep 23, 2015 at 12:01 PM, Stephen Frost wrote:
>> > * Robert Haas (robertmh...@gmail.com) wrote:
>> >> My expectation would have been:
>> >>
>> >> If you specify USING, you can see only
On Wed, Sep 23, 2015 at 2:30 PM, Kam Lasater wrote:
> Thanks for the suggestion. However, an issue tracker is not a
> replacement for mailing list(s) and vice versa. They are both
> necessary for success.
I venture to say that we are succeeding as it is, although of course
we might have more succ
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Sep 23, 2015 at 12:01 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> My expectation would have been:
> >>
> >> If you specify USING, you can see only those rows, but you can give
> >> rows away freely. If you d
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Kam Lasater wrote:
>
> > I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
> > that order). There are tens to hundreds of other great ones out there,
> > I'm sure one of them would also work.
>
> If you install debbugs and fee
> > I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
> > that order). There are tens to hundreds of other great ones out there,
> > I'm sure one of them would also work.
>
> If you install debbugs and feed it from our lists, maybe enough of us
> would jump into the bandwagon enou
On Thu, Sep 3, 2015 at 6:21 AM, Amit Kapila wrote:
> [ new patches ]
More review comments:
ExecParallelEstimate() and ExecParallelInitializeDSM() should use
planstate_tree_walker to iterate over the whole planstate tree.
That's because the parallel node need not be at the top of the tree.
By usi
Kam Lasater wrote:
> I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
> that order). There are tens to hundreds of other great ones out there,
> I'm sure one of them would also work.
If you install debbugs and feed it from our lists, maybe enough of us
would jump into the bandw
Hello,
Last night I heard that Postgres had no issue/bug tracker. At first I
thought the guy was trolling me. Seriously, how could this be. Certainly a
mature open source project that is the database for a measurable percentage
of the internet would have an issue tracker.
Sadly, I was not being t
Hi
I am facing the below issue in setting up BDR:
I have 2 nodes (For simplicity, I will refer them as node 1 & node 2). BDR
group was created from Node 1. When a new postgres node (i.e. node 2) joins
the group, then the node_status in bdr.bdr_nodes table of new node (i.e.
node 2) show 'r', but n
The comment on top of TrimMultiXact states that "no locks are needed
here", but then goes on to grab a few locks. I think we should remove
the comment, or rephrase it to state that we still grab them for
consistency or whatever; or perhaps even remove the lock acquisitions.
(I think the comment is
Stephen,
> Just a side-note, but your mail client doesn't seem to get the quoting
> quite right sometimes, which can be confusing. Not sure if there's
> anything you can do about it but wanted to let you know in case there
> is.
Sorry about this. From now on I'll use the plain text mode for msgs
On Wed, Sep 23, 2015 at 12:26 PM, Peter Eisentraut wrote:
> On 9/23/15 10:44 AM, Robert Haas wrote:
>> On Tue, Sep 22, 2015 at 3:35 PM, Peter Eisentraut wrote:
>>> On 9/16/15 5:52 PM, Simon Riggs wrote:
IMHO the default is the best one at the current time.
See recovery_min_apply_delay.
I wrote:
> Hm ... actually, we probably need *both* types of changes if that's
> what we believe the state values mean.
After a bit more thinking and experimentation, I propose the attached
patch.
regards, tom lane
diff --git a/contrib/postgres_fdw/deparse.c b/contrib/pos
On 9/23/15 11:05 AM, Stephen Frost wrote:
> That the USING policy is used if WITH CHECK isn't defined? That was
> simply done to make policy management simple as in quite a few cases
> only one policy is needed. If a WITH CHECK was always required then
> you'd be constantly writing:
>
> CREATE P
On Tue, Sep 22, 2015 at 3:14 AM, Haribabu Kommi
wrote:
> copy_user_generic_string system call is because of file read operations.
> In my test, I gave the shared_buffers as 12GB with the table size of 18GB.
OK, cool. So that's actually good: all that work would have to be
done either way, and pa
On 9/23/15 10:44 AM, Robert Haas wrote:
> On Tue, Sep 22, 2015 at 3:35 PM, Peter Eisentraut wrote:
>> On 9/16/15 5:52 PM, Simon Riggs wrote:
>>> IMHO the default is the best one at the current time.
>>> See recovery_min_apply_delay.
>>
>> The applications of recovery_min_apply_delay are likely to
On Wed, Sep 23, 2015 at 12:01 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Sep 23, 2015 at 11:24 AM, Stephen Frost wrote:
>> > I'm working on a documentation patch with Adam to improve the docs
>> > around this (and other parts as well). I agree it doesn't c
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Sep 23, 2015 at 11:24 AM, Stephen Frost wrote:
> > I'm working on a documentation patch with Adam to improve the docs
> > around this (and other parts as well). I agree it doesn't come off as
> > naturally intuitive to everyone (it did to me,
On Wed, Sep 23, 2015 at 3:22 AM, Amit Kapila wrote:
>> Instead of passing the Plan down by casting, how about passing
>> &local_node->plan? And similarly for scans and joins.
> Changed as per suggestion.
The point of this change was to make it so that we wouldn't need the
casts any more. You ch
Zhaomo,
Just a side-note, but your mail client doesn't seem to get the quoting
quite right sometimes, which can be confusing. Not sure if there's
anything you can do about it but wanted to let you know in case there
is.
* Zhaomo Yang (zmp...@gmail.com) wrote:
> > It'd be great if others who are
On Wed, Sep 23, 2015 at 11:22 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Tue, Sep 22, 2015 at 5:16 AM, Ildus Kurbangaliev
>> wrote:
>> > Yes, probably.
>> > I'm going to change API calls as you suggested earlier.
>> > How you do think the tranches registration after initialization shoul
On Wed, Sep 23, 2015 at 11:24 AM, Stephen Frost wrote:
> I'm working on a documentation patch with Adam to improve the docs
> around this (and other parts as well). I agree it doesn't come off as
> naturally intuitive to everyone (it did to me, but I'm clearly biased
> as, I think anyway, it was
Robert Haas wrote:
> On Tue, Sep 22, 2015 at 5:16 AM, Ildus Kurbangaliev
> wrote:
> > Yes, probably.
> > I'm going to change API calls as you suggested earlier.
> > How you do think the tranches registration after initialization should
> > look like?
>
> I don't see any need to change anything th
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Sep 23, 2015 at 11:05 AM, Stephen Frost wrote:
> >> Gosh, I think it would have been better to have a cleaner separation
> >> of USING and WITH CHECK. That sounds far too unnecessarily magical.
> >
> > That the USING policy is used if WITH CH
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Sep 22, 2015 at 10:36 PM, Charles Clavadetscher
> wrote:
> > Since the policy is defined for ALL commands and no WITH CHECK is specified
> > then the same condition defined in USING takes effect for all commands,
> > i.e. including INSERT.
>
On Wed, Sep 23, 2015 at 11:05 AM, Stephen Frost wrote:
>> Gosh, I think it would have been better to have a cleaner separation
>> of USING and WITH CHECK. That sounds far too unnecessarily magical.
>
> That the USING policy is used if WITH CHECK isn't defined? That was
> simply done to make poli
On Tue, Sep 22, 2015 at 10:36 PM, Charles Clavadetscher
wrote:
> Since the policy is defined for ALL commands and no WITH CHECK is specified
> then the same condition defined in USING takes effect for all commands, i.e.
> including INSERT.
>
> From the docs
> (http://www.postgresql.org/docs/9.5
On Tue, Sep 22, 2015 at 3:35 PM, Peter Eisentraut wrote:
> On 9/16/15 5:52 PM, Simon Riggs wrote:
>> IMHO the default is the best one at the current time.
>> See recovery_min_apply_delay.
>
> The applications of recovery_min_apply_delay are likely to be varied and
> specific, so there might not be
On Wed, Sep 23, 2015 at 5:56 AM, Amit Kapila wrote:
> While working on read functions for plan nodes (required for
> parallelism), it has been observed [1] by KaiGai and separately
> by me that function _outMergeJoin(), appends boolean in a
> slightly different way as compare to other out function
On Tue, Sep 22, 2015 at 5:16 AM, Ildus Kurbangaliev
wrote:
> Yes, probably.
> I'm going to change API calls as you suggested earlier.
> How you do think the tranches registration after initialization should
> look like?
I don't see any need to change anything there. The idea there is that
an ext
I wrote:
> After thinking a bit more about the existing special case for non-foreign
> Vars, I wonder if what we should do is change these code blocks to look
> like
> collation = r->resultcollid;
> if (collation == InvalidOid)
> state = FDW_COLL
Jeevan Chalke writes:
> On Tue, Sep 22, 2015 at 12:31 AM, Tom Lane wrote:
>> It strikes me that this function is really going about things the wrong
>> way. Rather than trying to determine the output collation per se, what
>> we ought to be asking is "does every operator in the proposed expressi
On 22 September 2015 at 21:14, Alvaro Herrera
wrote:
> Robert Haas wrote:
> > On Tue, Sep 22, 2015 at 10:34 AM, Simon Riggs
> wrote:
>
> > > For 1, Gather makes most sense.
> >
> > Yeah, I'm leaning that way myself. Amit argued for "Parallel Gather"
> > but I think that's overkill. There can't
On 22 September 2015 at 20:34, Robert Haas wrote:
> On Tue, Sep 22, 2015 at 10:34 AM, Simon Riggs
> wrote:
> > Robert, thanks for asking. We'll be stuck with these words for some time,
> > user visible via EXPLAIN so this is important.
>
> I agree, thanks for taking an interest.
>
> > The main o
On Wed, Sep 23, 2015 at 3:21 PM, Tom Lane wrote:
> "Shulgin, Oleksandr" writes:
> > On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
> >> It looks like a bug to me, but I think it might destabilize approved
> >> execution plans(*), so it may not be such a
On 2015-09-23 10:29:09 -0300, Alvaro Herrera wrote:
> > /*
> > + * Delete an individual SLRU segment, identified by the segment number.
> > + */
> > +void
> > +SlruDeleteSegment(SlruCtl ctl, int segno)
>
> Is it okay to change the ABI of SlruDeleteSegment?
I think so. Any previous user of the AP
Tom Lane wrote:
> Personally I think Alvaro's position is unduly conservative: to the extent
> that plans change it'd likely be for the better. But I'm not excited
> enough to fight hard about it.
I don't really care enough. We have received some complaints about
keeping plans stable, but maybe
> @@ -1210,8 +1211,14 @@ restart:;
> (void) SlruScanDirectory(ctl, SlruScanDirCbDeleteCutoff, &cutoffPage);
> }
>
> -void
> -SlruDeleteSegment(SlruCtl ctl, char *filename)
> +/*
> + * Delete an individual SLRU segment, identified by the filename.
> + *
> + * NB: This does not touch the SLR
"Shulgin, Oleksandr" writes:
> On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera
> wrote:
>> It looks like a bug to me, but I think it might destabilize approved
>> execution plans(*), so it may not be such a great idea to back patch
>> branches that are already released. I think HEAD + 9.5 is go
Hi Tom,
On Tue, Sep 22, 2015 at 12:31 AM, Tom Lane wrote:
>
> I think you're blaming the wrong code; RelabelType is handled basically
> the same as most other cases.
>
> It strikes me that this function is really going about things the wrong
> way. Rather than trying to determine the output col
On Wed, Sep 23, 2015 at 2:15 AM, Robert Haas wrote:
> On Tue, Sep 22, 2015 at 11:23 AM, Andrew Dunstan
> wrote:
> > "git bisect" is your friend.
>
> Yeah, but finding someone who has a working Windows build environment
> and a lot of time to run this down is my enemy. We're trying, but if
> any
On Wed, Sep 23, 2015 at 6:42 AM, Kouhei Kaigai wrote:
>
> > > On Thu, Sep 17, 2015 at 4:44 PM, Robert Haas
wrote:
>
> > To verify the patch, I have done 2 things, first I have added elog to
> > the newly supported read funcs and then in planner, I have used
> > nodeToString and stringToNode on pl
While working on read functions for plan nodes (required for
parallelism), it has been observed [1] by KaiGai and separately
by me that function _outMergeJoin(), appends boolean in a
slightly different way as compare to other out functions like
_outSort(). Is there a reason of doing so which is is
On Tue, Sep 22, 2015 at 11:43 PM, Tom Lane wrote:
> Alvaro Herrera writes:
> > In any case I think your patch is a good starting point.
>
> The comments seemed to need some wordsmithing, but I think this is
> probably basically a good idea; we've had similar complaints before
> about some other
On Wed, Sep 23, 2015 at 5:42 AM, Robert Haas wrote:
>
> On Tue, Sep 22, 2015 at 3:21 PM, Amit Kapila
wrote:
> > Attached patch (read_funcs_v1.patch) contains support for all the plan
> > and other nodes (like SubPlan which could be required for worker) except
> > CustomScan node.
>
> It looks lik
Stephen,
It'd be great if others who are interested can help define the grammar
> changes necessary
> and perhaps even help with the code aspect of it.
I'd like to help on both. Can you elaborate a little bit more, especially
on the code aspect?
I don't buy that argument.
It is agreed that blin
98 matches
Mail list logo