Thread: Commitfest wrapup
These remaining CF entries look like they're bugs that are maybe Open Issues for release? * fix spinlock contention in LogwrtResult * Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work * Add checkpoint and redo LSN to LogCheckpointEnd log message * standby recovery fails when re-replaying due to missing directory which was removed in previous replay. * Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns * fix psql pattern handling * Possible fails in pg_stat_statements test * pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory * Fix pg_rewind race condition just after promotion Was the plan to commit this after feature freeze? * pg_stat_statements: Track statement entry timestamp A couple minor documentation, testing, and diagnostics patches that may be committable even after feature freeze? * Improve role attributes docs * Reloption tests iprovement. Test resetting illegal option that was actually set for some reason * Make message at end-of-recovery less scary * jit_warn_above_fraction parameter And then there are the more devlish cases. I think some of these patches are Rejected or Returned with Feedback but I'm not certain. Some of them have split into multiple discussions or are partly committed but still related work remains. Any opinions on what to do with these? * Simplify some RI checks to reduce SPI overhead * Map WAL segment files on PMEM as WAL buffers * Support custom authentication methods using hooks * Implement INSERT SET syntax * Logical insert/update/delete WAL records for custom table AMs -- greg
On 2022-Apr-08, Greg Stark wrote: > These remaining CF entries look like they're bugs that are maybe Open > Issues for release? > > * fix spinlock contention in LogwrtResult I don't have a good enough grip on barriers needed for this, so I'd rather move it to pg16 to have time for further study. > * fix psql pattern handling Sounds like a bugfix, but how old and how backpatchable a fix is? Thread is quite long. > * Avoid erroring out when unable to remove or parse logical rewrite > files to save checkpoint work > * standby recovery fails when re-replaying due to missing directory > which was removed in previous replay. > * Logical replication failure "ERROR: could not map filenode > "base/13237/442428" to relation OID" with catalog modifying txns > * Fix pg_rewind race condition just after promotion > * pg_receivewal fail to streams when the partial file to write is not > fully initialized present in the wal receiver directory Sound like bugfixes to be backpatched. > A couple minor documentation, testing, and diagnostics patches that > may be committable even after feature freeze? > > * Improve role attributes docs Let's get it pushed. There's also a logical replication "row filter" doc patch that I don't see in your list, we should get that in. Maybe it's not in CF. I had a quibble with paras length in that one; requires stylistic edit. https://postgr.es/m/CAHut+PvyxMedYY-jHaT9YSfEPHv0jU2-CZ8F_nPvhuP0b955og@mail.gmail.com > * Reloption tests iprovement. Test resetting illegal option that was > actually set for some reason I think we should push this one. > * jit_warn_above_fraction parameter Unsure; seems a good patch, but is there enough consensus? > * Simplify some RI checks to reduce SPI overhead Move to next; a lot more work is required. > * Map WAL segment files on PMEM as WAL buffers > * Support custom authentication methods using hooks > * Implement INSERT SET syntax > * Logical insert/update/delete WAL records for custom table AMs New features. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Uno puede defenderse de los ataques; contra los elogios se esta indefenso"
On Sat, 9 Apr 2022 at 06:44, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > > * Simplify some RI checks to reduce SPI overhead > > Move to next; a lot more work is required. If it's going to be part of a much larger patch set I wonder if it shouldn't just be marked Rejected and start a new thread and new CF entry for the whole suite. > > * Map WAL segment files on PMEM as WAL buffers > > * Support custom authentication methods using hooks > > * Implement INSERT SET syntax > > * Logical insert/update/delete WAL records for custom table AMs > > New features. Yeah, this bunch definitely consists of new features, just not sure if they should be moved forward or Rejected or RWF. Some of them had some negative feedback or the development has taken some turns that make me think starting new patches specifically for the parts that remain may make more sense. -- greg
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2022-Apr-08, Greg Stark wrote:
>> * fix psql pattern handling
> Sounds like a bugfix, but how old and how backpatchable a fix is?
> Thread is quite long.
There's been more contention than one could wish about both what
the behavior should be and how to refactor the code to achieve it.
Nonetheless, I think there is general consensus that the current
behavior isn't very desirable, so if we can reach agreement I think
this should be treated as a bug fix.
>> * Avoid erroring out when unable to remove or parse logical rewrite
>> files to save checkpoint work
It seems like people are not convinced that this cure is better than
the disease.
>> * standby recovery fails when re-replaying due to missing directory
>> which was removed in previous replay.
>> * Logical replication failure "ERROR: could not map filenode
>> "base/13237/442428" to relation OID" with catalog modifying txns
>> * Fix pg_rewind race condition just after promotion
>> * pg_receivewal fail to streams when the partial file to write is not
>> fully initialized present in the wal receiver directory
> Sound like bugfixes to be backpatched.
Yeah. I'm not sure why these have received so little love.
The only one of this ilk that I've personally looked at was
>> * Make message at end-of-recovery less scary
which for me adds far too much complication for the claimed benefit.
Maybe somebody else with a lot more familiarity with the current WAL
code will care to push that, but I'm not touching it. Post-FF
doesn't seem like a good time for it anyway from a risk/reward
standpoint.
regards, tom lane
Greg Stark <stark@mit.edu> writes:
> On Sat, 9 Apr 2022 at 06:44, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>>> * Simplify some RI checks to reduce SPI overhead
>> Move to next; a lot more work is required.
> If it's going to be part of a much larger patch set I wonder if it
> shouldn't just be marked Rejected and start a new thread and new CF
> entry for the whole suite.
IMV, "rejected" means "we don't want this patch nor any plausible
rework of it". In this case, the feedback is more like "why aren't
we changing all of ri_triggers this way", so I'd call it RWF.
>>> * Map WAL segment files on PMEM as WAL buffers
>>> * Support custom authentication methods using hooks
>>> * Implement INSERT SET syntax
>>> * Logical insert/update/delete WAL records for custom table AMs
>> New features.
> Yeah, this bunch definitely consists of new features, just not sure if
> they should be moved forward or Rejected or RWF.
Probably just move them forward. The only one of these four that's
been really sitting around for a long time is INSERT SET, and I think
there we've just not quite made up our minds if we want it or not.
regards, tom lane
On Sat, 9 Apr 2022 at 10:51, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > Sound like bugfixes to be backpatched. > > Yeah. I'm not sure why these have received so little love. Since bug fixes are important enough that they'll definitely get done (and can happen after feature freeze) there's a bit of a perverse incentive to focus on other things... "Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it" I think every project struggles with bugs that sit in bug tracking systems indefinitely. The Open Issues is the biggest hammer we have. Maybe we should be tracking "Open Issues" from earlier in the process -- things that we think we shouldn't do a release without addressing. -- greg
On 4/9/22 1:14 PM, Greg Stark wrote: > On Sat, 9 Apr 2022 at 10:51, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >>> Sound like bugfixes to be backpatched. >> >> Yeah. I'm not sure why these have received so little love. > > Since bug fixes are important enough that they'll definitely get done > (and can happen after feature freeze) there's a bit of a perverse > incentive to focus on other things... > > "Everybody was sure that Somebody would do it. Anybody could have done > it, but Nobody did it" > > I think every project struggles with bugs that sit in bug tracking > systems indefinitely. The Open Issues is the biggest hammer we have. > Maybe we should be tracking "Open Issues" from earlier in the process > -- things that we think we shouldn't do a release without addressing. The RMT does both delineate and track open issues as a result of new features committed and a subset of issues in existing releases. Traditionally the RMT is more hands off on the latter unless it determines that not fixing the issue would have stability or other consequences if it's not included in the release. Jonathan