Re: Commitfest 2023-03 starting tomorrow! - Mailing list pgsql-hackers

From Gregory Stark (as CFM)
Subject Re: Commitfest 2023-03 starting tomorrow!
Date
Msg-id CAM-w4HP8zE_WeUxDNkyUvCtx_wwb105fXW4YiifVy8+aQ_uxtw@mail.gmail.com
Whole thread Raw
In response to Re: Commitfest 2023-03 starting tomorrow!  ("Gregory Stark (as CFM)" <stark.cfm@gmail.com>)
Responses Re: Commitfest 2023-03 starting tomorrow!
Re: Commitfest 2023-03 starting tomorrow!
Re: Commitfest 2023-03 starting tomorrow!
List pgsql-hackers
Only a few more days remain before feature freeze. We've now crossed
over 100 patches committed according to the CF app:

 Status summary:     March 15    March 22    March 28    April 4
   Needs review:         152         128         116          96
   Waiting on Author:     42          36          30          21
   Ready for Committer:   39          32          32          35
   Committed:             61          82          94         101
   Moved to next CF:       4          15          17          28
   Withdrawn:             17          16          18          20
   Rejected:               0           5           6           8
   Returned with Feedback: 4           5           6          10
 Total: 319.

Perhaps more importantly we've crossed *under* 100 patches waiting for review.

However I tried to do a pass of the Needs Review patches and found
that a lot of them were really waiting for comment and seemed to be
useful features or bug fixes that already had a significant amount of
work put into them and seemed likely to get committed if there was
time available to work on them.

There seems to be a bit of a mix of either

a) patches that just never got any feedback -- in some cases
presumably because the patch required special competency in a niche
area

or

b) patches that had active discussion and patches being updated until
discussion died out. Presumably because the author either got busy
elsewhere or perhaps the discussion seemed unproductive and exhausted
them.

What I didn't see, that I expected to see, was patches that were just
uninteresting to anyone other than the author but that people were
just too polite to reject.

So I think these patches are actual useful patches that we would want
to have but are likely, modulo some bug fixes, to get moved along to
the next CF again without any progress this CF:


* Remove dead macro exec_subplan_get_plan
* pg_rewind WAL deletion pitfall
* Avoid hiding shared filesets in pg_ls_tmpdir (pg_ls_* functions for
showing metadata ...)
* Fix bogus error emitted by pg_recvlogical when interrupted
* Lockless queue of waiters based on atomic operations for LWLock
* Add sortsupport for range types and btree_gist
* Enable jitlink as an alternative jit linker of legacy Rtdyld and add
riscv jitting support
* basebackup: support zstd long distance matching
* Function to log backtrace of postgres processes
* More scalable multixacts buffers and locking
* COPY FROM enable FORCE_NULL/FORCE_NOT_NULL on all columns
* Add semi-join pushdown to postgres_fdw
* Skip replicating the tables specified in except table option
* Post-special Page Storage TDE support
* Direct I/O (developer-only feature)
* Improve doc for autovacuum on partitioned tables
* An attempt to avoid
locally-committed-but-not-replicated-to-standby-transactions in
synchronous replication
* Check lateral references within PHVs for memoize cache keys
* monitoring usage count distribution
* New [relation] options engine
* nbtree performance improvements through specialization on key shape
* Fix assertion failure in SnapBuildInitialSnapshot()
* Speed up releasing of locks
* Improve pg_bsd_indent's handling of multiline initialization expressions
* Refactoring postgres_fdw/connection.c
* Add pg_stat_session
* archive modules loose ends
* Fix dsa_free() to re-bin segment
* Reduce timing overhead of EXPLAIN ANALYZE using rdtsc
* clean up permission checks after 599b33b94
* Fix the description of GUC "max_locks_per_transaction" and
"max_pred_locks_per_transaction" in guc_table.c
* some namespace.c refactoring
* Add function to_oct
* Switching XLog source from archive to streaming when primary available
* BRIN - SK_SEARCHARRAY and scan key preprocessing
* Reuse Workers and Replication Slots during Logical Replication



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Check whether binaries can be released for s390x
Next
From: Jacob Champion
Date:
Subject: Re: RFC: logical publication via inheritance root?