Thread: open items
Hi, Just a few reminders about the open items list at https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items -- - Please don't add issues to this list unless they are the result of development done during this release cycle. This is not a general-purpose bug tracker. - The owner of an item is the person who committed the patch that caused the problem, because that committer is responsible for cleaning up the mess. Of course, the patch author is warmly invited to help, especially if they have aspirations of being a committer some day themselves. Other help is welcome, too. - Fixing the stuff on this list is a time-boxed activity. We want to put out a release on time. If the stuff listed here doesn't get fixed, the release management team will have to do something about it, like start yelling at people, or forcing patches to be reverted, which will be no fun for anyone involved, including but not limited to the release management team. A great number of things that were added as open items have already been resolved, but some of the remaining items have been there for a while. Here's a quick review of what's on the list as of this moment: * Incorrect Assert in heap_end/rescan for BHS. Either the description of this item is inaccurate, or we've been unable to fix an incorrect assert after more than a month. I interpret https://www.postgresql.org/message-id/54858BA1-084E-4F7D-B2D1-D15505E512FF%40yesql.se as a vote in favor of committing some patch by Melanie to fix this. Either Tomas should commit that patch, or Melanie should commit that patch, or somebody should say why that patch shouldn't be committed, or someone should request more help determining whether that patch is indeed the correct fix, or something. But let's not just sit on this. * Register ALPN protocol id with IANA. From the mailing list thread, it is abundantly clear that IANA is in no hurry to finish dealing with what seems to be a completely pro forma request from our end. I think we just have to be patient. * not null constraints break dump/restore. I asked whether all of the issues had been addressed here and Justin Pryzby opined that the only thing that was still relevant for this release was a possible test case change, which I would personally consider a good enough reason to at least consider calling this done. But it's not clear to me whether Justin's opinion is the consensus position, or perhaps more relevantly, whether it's Álvaro's position. * Temporal PKs allow duplicates with empty ranges. Peter Eisentraut has started working with Paul Jungwirth on this. Looks good so far. * Rename sslnegotiation "requiredirect." option to "directonly". I still think Heikki has implemented the wrong behavior here, and I don't think this renaming is going to make any difference one way or the other in how understandable it is. But if we're going to leave the behavior as-is and do the renaming, then let's get that done. * Race condition with local injection point detach. Discussion is ongoing. -- Robert Haas EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes: > * Register ALPN protocol id with IANA. From the mailing list thread, > it is abundantly clear that IANA is in no hurry to finish dealing with > what seems to be a completely pro forma request from our end. I think > we just have to be patient. This appears to have been approved without anyone mentioning it on the list, and the registry now lists "postgresql" at the bottom: https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids - ilmari
On Thu, May 9, 2024 at 3:38 PM Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > * Register ALPN protocol id with IANA. From the mailing list thread, > > it is abundantly clear that IANA is in no hurry to finish dealing with > > what seems to be a completely pro forma request from our end. I think > > we just have to be patient. > > This appears to have been approved without anyone mentioning it on the > list, and the registry now lists "postgresql" at the bottom: > > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids Nice, thanks! -- Robert Haas EDB: http://www.enterprisedb.com
On Thu, May 09, 2024 at 03:28:13PM -0400, Robert Haas wrote: > Just a few reminders about the open items list at > https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items -- Thanks for summarizing the situation. > * Race condition with local injection point detach. Discussion is ongoing. I have sent a patch for that yesterday, which I assume is going in the right direction to close entirely the loop: https://www.postgresql.org/message-id/Zjx9-2swyNg6E1y1%40paquier.xyz There is still one point of detail related to the amount of flexibility we'd want for detachs (concurrent detach happening in parallel of an automated one in the shmem callback) that I'm not entirely sure about yet but I've proposed an idea to solve that as well. I'm hopeful in getting that wrapped at the beginning of next week. -- Michael
Attachment
On 2024-May-09, Robert Haas wrote: > * not null constraints break dump/restore. I asked whether all of the > issues had been addressed here and Justin Pryzby opined that the only > thing that was still relevant for this release was a possible test > case change, which I would personally consider a good enough reason to > at least consider calling this done. But it's not clear to me whether > Justin's opinion is the consensus position, or perhaps more > relevantly, whether it's Álvaro's position. I have fixed the reported issues, so as far as these specific items go, we could close the reported open item. However, in doing so I realized that some code is more complex than it needs to be, and exposes users to ugliness that they don't need to see, so I posted additional patches. I intend to get these committed today. A possible complaint is that the upgrade mechanics which are mostly in pg_dump with some pieces in pg_upgrade are not very explicitly documented. There are already comments in all relevant places, but perhaps an overall picture is necessary. I'll see about this, probably as a long comment somewhere. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "La virtud es el justo medio entre dos defectos" (Aristóteles)
On Thu, May 9, 2024 at 3:28 PM Robert Haas <robertmhaas@gmail.com> wrote: > > Just a few reminders about the open items list at > https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items -- > > * Incorrect Assert in heap_end/rescan for BHS. Either the description > of this item is inaccurate, or we've been unable to fix an incorrect > assert after more than a month. I interpret > https://www.postgresql.org/message-id/54858BA1-084E-4F7D-B2D1-D15505E512FF%40yesql.se > as a vote in favor of committing some patch by Melanie to fix this. > Either Tomas should commit that patch, or Melanie should commit that > patch, or somebody should say why that patch shouldn't be committed, > or someone should request more help determining whether that patch is > indeed the correct fix, or something. But let's not just sit on this. Sorry, yes, the trivial fix has been done for a while. There is one outstanding feedback on the patch: an update to one of the comments suggested by Tomas. I got distracted by trying to repro and fix a bug from the section "live issues affecting stable branches". I will update this BHS patch by tonight and commit it once Tomas has a chance to +1. Thanks, Melanie
> On 10 May 2024, at 14:48, Melanie Plageman <melanieplageman@gmail.com> wrote: > > On Thu, May 9, 2024 at 3:28 PM Robert Haas <robertmhaas@gmail.com> wrote: >> >> Just a few reminders about the open items list at >> https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items -- >> >> * Incorrect Assert in heap_end/rescan for BHS. Either the description >> of this item is inaccurate, or we've been unable to fix an incorrect >> assert after more than a month. I interpret >> https://www.postgresql.org/message-id/54858BA1-084E-4F7D-B2D1-D15505E512FF%40yesql.se >> as a vote in favor of committing some patch by Melanie to fix this. It's indeed a vote for that. >> Either Tomas should commit that patch, or Melanie should commit that >> patch, or somebody should say why that patch shouldn't be committed, >> or someone should request more help determining whether that patch is >> indeed the correct fix, or something. But let's not just sit on this. > > Sorry, yes, the trivial fix has been done for a while. There is one > outstanding feedback on the patch: an update to one of the comments > suggested by Tomas. I got distracted by trying to repro and fix a bug > from the section "live issues affecting stable branches". I will > update this BHS patch by tonight and commit it once Tomas has a chance > to +1. +1 -- Daniel Gustafsson
On Fri, May 10, 2024 at 8:48 AM Melanie Plageman <melanieplageman@gmail.com> wrote: > Sorry, yes, the trivial fix has been done for a while. There is one > outstanding feedback on the patch: an update to one of the comments > suggested by Tomas. I got distracted by trying to repro and fix a bug > from the section "live issues affecting stable branches". I will > update this BHS patch by tonight and commit it once Tomas has a chance > to +1. Great, thanks! -- Robert Haas EDB: http://www.enterprisedb.com
On Fri, May 10, 2024 at 7:14 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > A possible complaint is that the upgrade mechanics which are mostly in > pg_dump with some pieces in pg_upgrade are not very explicitly > documented. There are already comments in all relevant places, but > perhaps an overall picture is necessary. I'll see about this, probably > as a long comment somewhere. I think that would be really helpful. -- Robert Haas EDB: http://www.enterprisedb.com
On 09/05/2024 22:39, Robert Haas wrote: > On Thu, May 9, 2024 at 3:38 PM Dagfinn Ilmari Mannsåker > <ilmari@ilmari.org> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> * Register ALPN protocol id with IANA. From the mailing list thread, >>> it is abundantly clear that IANA is in no hurry to finish dealing with >>> what seems to be a completely pro forma request from our end. I think >>> we just have to be patient. >> >> This appears to have been approved without anyone mentioning it on the >> list, and the registry now lists "postgresql" at the bottom: >> >> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids > > Nice, thanks! Committed the change from "TBD-pgsql" to "postgresql", thanks! -- Heikki Linnakangas Neon (https://neon.tech)
Hi, We are down to three open items, all of which have proposed fixes. That is great, but we need to keep things moving along, because according to https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items we are due to release beta1 on May 23. That means that a release freeze will be in effect from Saturday, May 18, which is four days from now. Since committing patches sometimes leads to unexpected surprises, it would be best if the proposed fixes were put into place sooner rather than later, to allow time for any adjustments that may be required. * Incorrect Assert in heap_end/rescan for BHS Melanie posted a new patch version 23 hours ago, Michael Paquier reviewed it 7 hours ago. See https://www.postgresql.org/message-id/CAAKRu_a%2B5foybidkmh8FpFAV7iegxetPyPXQ5%3D%2B%2BkqZ%2BZDEUcg%40mail.gmail.com * Temporal PKs allow duplicates with empty ranges Peter proposes to revert the feature. See https://www.postgresql.org/message-id/64c2b2ab-7ce9-475e-ac59-3bfec528bada%40eisentraut.org * Rename sslnegotiation "requiredirect" option to "directonly" Latest patch is at https://www.postgresql.org/message-id/3fdaf4b1-82d1-45bb-8175-f97ff53a1f01%40iki.fi and, I at least, like it The basic proposal is to get rid of the idea of having a way to try both modes (negotiated/direct) and make sslnegotiation just pick one behavior or the other. Thanks, ...Robert
On Tue, May 14, 2024 at 09:52:35AM -0400, Robert Haas wrote: > We are down to three open items, all of which have proposed fixes. > That is great, but we need to keep things moving along, because > according to https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items > we are due to release beta1 on May 23. That means that a release > freeze will be in effect from Saturday, May 18, which is four days > from now. Since committing patches sometimes leads to unexpected > surprises, it would be best if the proposed fixes were put into place > sooner rather than later, to allow time for any adjustments that may > be required. As of this minute, the open item list is empty @-@. Thanks all for the various resolutions, updates and commits! -- Michael