Thread: Schedule for 9.5alpha1
There was agreement at the PGCon dev meeting that we should put out a
9.5alpha1 release as soon as possible, to encourage wider testing
(and that it should be called an "alpha", because people aren't convinced
it's up to beta quality yet). After a little back and forth, that release
has been set for next week, ie we'll wrap Monday June 29 for public
announcement Thursday July 2.
If there are any open 9.5 issues you can fix before Monday, please do.
Also, there was agreement that we'd begin the first 9.6 commitfest
on July 1. I anticipate forking off the REL9_5_STABLE branch on
Tuesday to make way for that.
regards, tom lane
On Thu, Jun 25, 2015 at 8:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If there are any open 9.5 issues you can fix before Monday, please do. I have 3 pending bug fixes for UPSERT, including 2 trivial ones. This does not include my "minor refactoring" patch, which is not a bugfix. The last of those 3 was posted on 2015-05-30. I'm rather frustrated that it's so difficult to get maintenance/bugfix patches committed. Frankly, as a non-committer, I don't see a reason to bother trying to fix any open 9.5 items by Monday. The probability of anyone picking them up by then seems very low. -- Peter Geoghegan
On June 25, 2015 9:35:27 PM GMT+02:00, Peter Geoghegan <pg@heroku.com> wrote: >On Thu, Jun 25, 2015 at 8:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If there are any open 9.5 issues you can fix before Monday, please >do. > >I have 3 pending bug fixes for UPSERT, including 2 trivial ones. This >does not include my "minor refactoring" patch, which is not a bugfix. >The last of those 3 was posted on 2015-05-30. > >I'm rather frustrated that it's so difficult to get maintenance/bugfix >patches committed. Frankly, as a non-committer, I don't see a reason >to bother trying to fix any open 9.5 items by Monday. The probability >of anyone picking them up by then seems very low. It'd have been easier if you'd done it the way I asked. This way I have to look much closer... --- Please excuse brevity and formatting - I am writing this on my mobile phone.
On Thu, Jun 25, 2015 at 12:39 PM, Andres Freund <andres@anarazel.de> wrote: > It'd have been easier if you'd done it the way I asked. This way I have to look much closer... Well, I actually prototyped your approach to that and decided against it only after having gone to the trouble of doing so. In any case, I think it's appropriate that you review the wholerow var bugfix patch carefully. So I'm not talking about that one, as I think you gathered. I'm not singling you out; clearly you were very busy with other, more important things the entire time. I'm just giving my perspective. -- Peter Geoghegan
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane > Sent: Friday, June 26, 2015 12:00 AM > To: pgsql-hackers@postgreSQL.org > Subject: [HACKERS] Schedule for 9.5alpha1 > > There was agreement at the PGCon dev meeting that we should put out a > 9.5alpha1 release as soon as possible, to encourage wider testing > (and that it should be called an "alpha", because people aren't convinced > it's up to beta quality yet). After a little back and forth, that release > has been set for next week, ie we'll wrap Monday June 29 for public > announcement Thursday July 2. > > If there are any open 9.5 issues you can fix before Monday, please do. > I have a serious open item reported 1.5 month ago then reminded several times has not been fixed up yet. 9A28C8860F777E439AA12E8AEA7694F8010F3EA6@BPXM15GP.gisp.nec.co.jp Patch is less than 100 lines, entirely designed according to Tom's suggestion. The problem is, commit 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e reverted create_plan_recurse() to static function, thus, extension lost way to transform Path node to Plan node if it wants to takes underlying child nodes, like SeqScan, HashJoin and so on. Tom's suggestion is to add a list of Path nodes on CustomPath structure, to be transformed by createplan.c, instead of public create_plan_recurse(). It is nearly obvious problem, and bugfix patch already exists. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com>
Attachment
On Thu, Jun 25, 2015 at 3:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: > It is nearly obvious problem, and bugfix patch already exists. My current strategy is to post these items on the "PostgreSQL 9.5 Open Items" page, even when the issue is totally trivial -- maybe that makes a small difference, even if it sometimes feels inappropriate for small items. There are some other items with clear or clear-ish fixes beyond the ones that I mentioned. For one further example not involving UPSERT, ISTM based on pgCon discussion that "Arguable RLS security bug, EvalPlanQual() paranoia" can be fixed with a well written doc patch, once we figure out exactly how to explain the issue, which should be straightforward. For another, the rest of the jsonb stuff is now almost open-and-shut (again, this conclusion is based on discussion during pgCon, in this instance with Andrew). That fix involves an actual small adjustment to semantics. This is just the stuff I'm involved in. I think that the experience of myself and Kaigai-san with bug fixes are representative. Some committers request that I post simple bugfixes to the next commitfest. That might help with making sure that they eventually get some attention, which makes some sense at a different time in the cycle, but it does not help at all with making sure that they get timely attention when we're up against a deadline for putting out a release (even if it is an alpha). Besides, even when a release is not upcoming, my strong personal preference is to fix bugs ASAP. I'm tired of having to chase down known bugs when a patch has been around for a long time, and an actual fix is blocking on committer availability -- sometimes I feel the need to privately twist someone's arm just to get something done that should be straightforward. If this is the way things are supposed to work, we should document known bugs in the alpha release notes. -- Peter Geoghegan
On Fri, Jun 26, 2015 at 8:03 AM, Peter Geoghegan <pg@heroku.com> wrote: > On Thu, Jun 25, 2015 at 3:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: >> It is nearly obvious problem, and bugfix patch already exists. > > My current strategy is to post these items on the "PostgreSQL 9.5 Open > Items" page, even when the issue is totally trivial -- maybe that > makes a small difference, even if it sometimes feels inappropriate for > small items. This is the right approach to me, this page being dedicated to that. And I am doing the same when I spot something. > I'm tired of having to chase down known bugs when a patch has been > around for a long time, and an actual fix is blocking on committer > availability -- sometimes I feel the need to privately twist someone's > arm just to get something done that should be straightforward. Patience is the key here IMO, committer time being precious. And I guess that the requirement for the .0 release will be to clear all those items btw, so they will be fixed at some point. > If this is the way things are supposed to work, we should document known bugs > in the alpha release notes. Perhaps. Being able to track them in the code tree does not sound like a bad thing to me. -- Michael
On Thu, Jun 25, 2015 at 4:30 PM, Michael Paquier <michael.paquier@gmail.com> wrote: >> I'm tired of having to chase down known bugs when a patch has been >> around for a long time, and an actual fix is blocking on committer >> availability -- sometimes I feel the need to privately twist someone's >> arm just to get something done that should be straightforward. > > Patience is the key here IMO, committer time being precious. And I > guess that the requirement for the .0 release will be to clear all > those items btw, so they will be fixed at some point. Some more transparency in both directions, and the ability to triage bugs would be nice. Sometimes things aren't that complicated, but are still important (while other times, things can be complicated and unimportant). I have no good way of making a representation about which category any given bug fix falls under. Also, while the commitfest app makes it pretty likely that someone will get around to considering a bug fix eventually, the time that that takes is completely unbounded. -- Peter Geoghegan
On 06/25/2015 05:09 PM, Peter Geoghegan wrote: > > On Thu, Jun 25, 2015 at 4:30 PM, Michael Paquier > <michael.paquier@gmail.com> wrote: >>> I'm tired of having to chase down known bugs when a patch has been >>> around for a long time, and an actual fix is blocking on committer >>> availability -- sometimes I feel the need to privately twist someone's >>> arm just to get something done that should be straightforward. >> >> Patience is the key here IMO, committer time being precious. And I >> guess that the requirement for the .0 release will be to clear all >> those items btw, so they will be fixed at some point. > > Some more transparency in both directions, and the ability to triage > bugs would be nice. Sometimes things aren't that complicated, but are > still important (while other times, things can be complicated and > unimportant). I have no good way of making a representation about > which category any given bug fix falls under. > > Also, while the commitfest app makes it pretty likely that someone > will get around to considering a bug fix eventually, the time that > that takes is completely unbounded. Perhaps Heroku could sponsor a committer or two for triage. I know there are a couple that are not currently bound by other Pg companies. Sincerely, JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: > I have a serious open item reported 1.5 month ago then reminded > several times has not been fixed up yet. > > 9A28C8860F777E439AA12E8AEA7694F8010F3EA6@BPXM15GP.gisp.nec.co.jp > > Patch is less than 100 lines, entirely designed according to Tom's suggestion. > > The problem is, commit 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e reverted > create_plan_recurse() to static function, thus, extension lost way to > transform Path node to Plan node if it wants to takes underlying child > nodes, like SeqScan, HashJoin and so on. > > Tom's suggestion is to add a list of Path nodes on CustomPath structure, > to be transformed by createplan.c, instead of public create_plan_recurse(). > > It is nearly obvious problem, and bugfix patch already exists. Yes, I am quite unhappy with this situation. Tom promised me at PGCon that he would look at this soon, but there is no sign that he has, and he said the same thing weeks ago. I think it can't be right to let this sit for another month or three. Even if the API you've implemented is worse than something Tom can design, it is certainly better than the status quo. I would rather have a working but imperfect API and have to break compatibility later in beta than have a non-working API. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: >> I have a serious open item reported 1.5 month ago then reminded >> several times has not been fixed up yet. >> >> 9A28C8860F777E439AA12E8AEA7694F8010F3EA6@BPXM15GP.gisp.nec.co.jp >> >> Patch is less than 100 lines, entirely designed according to Tom's suggestion. >> >> The problem is, commit 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e reverted >> create_plan_recurse() to static function, thus, extension lost way to >> transform Path node to Plan node if it wants to takes underlying child >> nodes, like SeqScan, HashJoin and so on. >> >> Tom's suggestion is to add a list of Path nodes on CustomPath structure, >> to be transformed by createplan.c, instead of public create_plan_recurse(). >> >> It is nearly obvious problem, and bugfix patch already exists. > > Yes, I am quite unhappy with this situation. Tom promised me at PGCon > that he would look at this soon, but there is no sign that he has, and > he said the same thing weeks ago. I think it can't be right to let > this sit for another month or three. Even if the API you've > implemented is worse than something Tom can design, it is certainly > better than the status quo. I would rather have a working but > imperfect API and have to break compatibility later in beta than have > a non-working API. ...given which, I have committed this. I did not like the use of custom_children as a generic monicker, so I changed it to custom_paths, custom_plans, or custom_ps, as appropriate in each case. I did a bit of cosmetic cleanup as well. This does seem much nicer than giving custom plans direct access to create_plan_recurse(). The fact that you found various other places of using those lists demonstrates that nicely. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
> On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> >> I have a serious open item reported 1.5 month ago then reminded
> >> several times has not been fixed up yet.
> >>
> >> 9A28C8860F777E439AA12E8AEA7694F8010F3EA6@BPXM15GP.gisp.nec.co.jp
> >>
> >> Patch is less than 100 lines, entirely designed according to Tom's suggestion.
> >>
> >> The problem is, commit 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e reverted
> >> create_plan_recurse() to static function, thus, extension lost way to
> >> transform Path node to Plan node if it wants to takes underlying child
> >> nodes, like SeqScan, HashJoin and so on.
> >>
> >> Tom's suggestion is to add a list of Path nodes on CustomPath structure,
> >> to be transformed by createplan.c, instead of public create_plan_recurse().
> >>
> >> It is nearly obvious problem, and bugfix patch already exists.
> >
> > Yes, I am quite unhappy with this situation. Tom promised me at PGCon
> > that he would look at this soon, but there is no sign that he has, and
> > he said the same thing weeks ago. I think it can't be right to let
> > this sit for another month or three. Even if the API you've
> > implemented is worse than something Tom can design, it is certainly
> > better than the status quo. I would rather have a working but
> > imperfect API and have to break compatibility later in beta than have
> > a non-working API.
>
> ...given which, I have committed this. I did not like the use of
> custom_children as a generic monicker, so I changed it to
> custom_paths, custom_plans, or custom_ps, as appropriate in each case.
> I did a bit of cosmetic cleanup as well.
>
> This does seem much nicer than giving custom plans direct access to
> create_plan_recurse(). The fact that you found various other places
> of using those lists demonstrates that nicely.
>
Thanks for your help!
One advantage of the approach, I think, is custom_paths list allows to
implement N-way (N > 2) join more naturally than just direct accesses
to create_plan_recurse().
The example below shows contents of t1, t2 and t3 are enough small to
load GPU RAM, so the custom "GpuJoin" can run these 4 tables join within
a single step.
postgres=# explain select * from t0 natural join t1 natural join t2 natural join t3;
QUERY PLAN
------------------------------------------------------------------------------------------------Custom Scan (GpuJoin)
(cost=6501.77..249476.48rows=9899296 width=176) Bulkload: On (density: 100.00%) Depth 1: Logic: GpuHashJoin,
HashKeys:(cid), JoinQual: (cid = cid), nrows_ratio: 0.98995197 Depth 2: Logic: GpuHashJoin, HashKeys: (aid), JoinQual:
(aid= aid), nrows_ratio: 1.00000000 Depth 3: Logic: GpuHashJoin, HashKeys: (bid), JoinQual: (bid = bid), nrows_ratio:
1.00000000 -> Custom Scan (BulkScan) on t0 (cost=0.00..242855.74 rows=9999774 width=77) -> Seq Scan on t3
(cost=0.00..734.00rows=40000 width=37) -> Seq Scan on t1 (cost=0.00..734.00 rows=40000 width=37) -> Seq Scan on t2
(cost=0.00..734.00 rows=40000 width=37)
(9 rows)
Best regards,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>