Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

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

Re: [HACKERS] Parallel Seq Scan

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

Re: [HACKERS] Calculage avg. width when operator = is missing

"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 >>

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

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

Re: [HACKERS] Rework the way multixact truncations work

> @@ -1210,8 +1211,14 @@ restart:; > (void) SlruScanDirectory(ctl, SlruScanDirCbDeleteCutoff, ); > } > > -void > -SlruDeleteSegment(SlruCtl ctl, char *filename) > +/* > + * Delete an individual SLRU segment, identified by the filename. > + * > + * NB: This does not touch the SLRU buffers

Re: [HACKERS] a funnel by any other name

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,

Re: [HACKERS] unclear about row-level security USING vs. CHECK

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 >

Re: [HACKERS] unclear about row-level security USING vs. CHECK

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 >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] Calculage avg. width when operator = is missing

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

Re: [HACKERS] Rework the way multixact truncations work

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

Re: [HACKERS] hot_standby_feedback default and docs

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

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

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

Re: [HACKERS] a funnel by any other name

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

Re: [HACKERS] unclear about row-level security USING vs. CHECK

* 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,

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

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 =

Re: [HACKERS] unclear about row-level security USING vs. CHECK

* 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

Re: [HACKERS] Calculage avg. width when operator = is missing

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

Re: [HACKERS] Inconsistency in Output function of MergeJoin

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

Re: [HACKERS] CREATE POLICY and RETURNING

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

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

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

Re: [HACKERS] Parallel Seq Scan

On Wed, Sep 23, 2015 at 3:22 AM, Amit Kapila wrote: >> Instead of passing the Plan down by casting, how about passing >> _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

Re: [HACKERS] unclear about row-level security USING vs. CHECK

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

Re: [HACKERS] unclear about row-level security USING vs. CHECK

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

Re: [HACKERS] unclear about row-level security USING vs. CHECK

* 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

Re: [HACKERS] hot_standby_feedback default and docs

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.

Re: [HACKERS] unclear about row-level security USING vs. CHECK

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] Parallel Seq Scan

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

Re: [HACKERS] hot_standby_feedback default and docs

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

[HACKERS] Postgres - BDR issue

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

[HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] Rework the way multixact truncations work

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.

Re: [HACKERS] Rework the way multixact truncations work

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"), > >

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* 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

Re: [HACKERS] unclear about row-level security USING vs. CHECK

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: >> >> >>

[HACKERS] clearing opfuncid vs. parallel query

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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.

Re: [HACKERS] Parallel Seq Scan

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

> > 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

Re: [HACKERS] unclear about row-level security USING vs. CHECK

* 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

Re: [HACKERS] CREATE POLICY and RETURNING

* 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

Re: [HACKERS] unclear about row-level security USING vs. CHECK

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,

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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,

Re: [HACKERS] unclear about row-level security USING vs. CHECK

* 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

Re: [HACKERS] unclear about row-level security USING vs. CHECK

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

Re: [HACKERS] Rework the way multixact truncations work

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

Re: [HACKERS] Rework the way multixact truncations work

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.

Re: [HACKERS] unclear about row-level security USING vs. CHECK

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

Re: [HACKERS] Calculage avg. width when operator = is missing

On Tue, Sep 22, 2015 at 11:17 PM, Alvaro Herrera wrote: > Shulgin, Oleksandr wrote: > > On Sep 22, 2015 8:58 PM, "Andrew Dunstan" wrote: > > > > Yes, "/revenons/ à /nos moutons/." You can set up text based comparison > > > ops fairly easily for

Re: [HACKERS] Calculage avg. width when operator = is missing

On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera wrote: > Tom Lane wrote: > > > Should we consider this HEAD-only, or a back-patchable bug fix? > > Or perhaps compromise on HEAD + 9.5? > > It looks like a bug to me, but I think it might destabilize approved > execution

Re: [HACKERS] CREATE POLICY and RETURNING

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

Re: [HACKERS] Parallel Seq Scan

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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.

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

>> 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.

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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:

Re: [HACKERS] CREATE POLICY and RETURNING

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] unclear about row-level security USING vs. CHECK

* 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: > >

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] DBT-3 with SF=20 got failed

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,

Re: [HACKERS] clearing opfuncid vs. parallel query

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

Re: [HACKERS] clearing opfuncid vs. parallel query

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] Calculage avg. width when operator = is missing

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

> 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

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

> > 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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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,

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

* 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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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,

Re: [HACKERS] clearing opfuncid vs. parallel query

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

[HACKERS] Inconsistency in Output function of MergeJoin

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

Re: [HACKERS] Support for N synchronous standby servers - take 2

> 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.

Re: [HACKERS] Parallel Seq Scan

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] Support for N synchronous standby servers - take 2

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

Re: [HACKERS] clearing opfuncid vs. parallel query

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

Re: [HACKERS] clearing opfuncid vs. parallel query

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

Re: [HACKERS] Bad row estimation with indexed func returning bool

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] Support for N synchronous standby servers - take 2

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,

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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): > >

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

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

Re: [HACKERS] Postgres - BDR issue

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

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

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 =