public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v2 3/3] Block attempts to set GUCs while loading shared_preload_libraries.
36+ messages / 13 participants
[nested] [flat]
* [PATCH v2 3/3] Block attempts to set GUCs while loading shared_preload_libraries.
@ 2022-04-10 21:27 Nathan Bossart <[email protected]>
0 siblings, 0 replies; 36+ messages in thread
From: Nathan Bossart @ 2022-04-10 21:27 UTC (permalink / raw)
This change attempts to block parameter changes in preloaded
libraries' _PG_init() functions. We cannot reliably support such
behavior because certain parameters contribute to global values
we've already calculated at this point (e.g., MaxBackends). We'd
rather make sure values like MaxBackends are available for use in
_PG_init(), and we encourage extension authors to instead recommend
suitable settings and error if such recommendations are not heeded.
Of course, preloaded libraries could still change the value
directly instead of via SetConfigOption(), but trying to handle
that is probably more trouble than it's worth.
---
src/backend/utils/misc/guc.c | 51 +++++++++++++++++++++++++++++++++---
1 file changed, 47 insertions(+), 4 deletions(-)
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 9e0f262088..51a6e16fe0 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -161,6 +161,11 @@ char *GUC_check_errdetail_string;
char *GUC_check_errhint_string;
static void do_serialize(char **destptr, Size *maxbytes, const char *fmt,...) pg_attribute_printf(3, 4);
+static int set_config_option_internal(const char *name, const char *value,
+ GucContext context, GucSource source,
+ GucAction action, bool changeVal,
+ int elevel, bool is_reload,
+ bool allow_when_loading_preload_libs);
static void set_config_sourcefile(const char *name, char *sourcefile,
int sourceline);
@@ -7560,6 +7565,21 @@ set_config_option(const char *name, const char *value,
GucContext context, GucSource source,
GucAction action, bool changeVal, int elevel,
bool is_reload)
+{
+ return set_config_option_internal(name, value, context, source, action,
+ changeVal, elevel, is_reload, false);
+}
+
+/*
+ * Just like set_config_option(), except allows overriding the ERROR when called
+ * while loading shared_preload_libraries. This is needed for defining custom
+ * GUCs, which involves calling this function to set the GUC.
+ */
+static int
+set_config_option_internal(const char *name, const char *value,
+ GucContext context, GucSource source,
+ GucAction action, bool changeVal, int elevel,
+ bool is_reload, bool allow_when_loading_preload_libs)
{
struct config_generic *record;
union config_var_val newval_union;
@@ -7567,6 +7587,28 @@ set_config_option(const char *name, const char *value,
bool prohibitValueChange = false;
bool makeDefault;
+ /*
+ * We attempt to block parameter changes in preloaded libraries' _PG_init()
+ * functions. We cannot reliably support such behavior because certain
+ * parameters contribute to global values we've already calculated at this
+ * point (e.g., MaxBackends). We'd rather make sure values like MaxBackends
+ * are available for use in _PG_init(), and we encourage extension authors
+ * to instead recommend suitable settings and error if such recommendations
+ * are not heeded. Of course, preloaded libraries could still change the
+ * value directly instead of via SetConfigOption(), but trying to handle
+ * that is probably more trouble than it's worth.
+ *
+ * This ERROR is bypassed when allow_when_loading_preload_libs is true.
+ * This is needed for defining custom GUCs, which involves calling this
+ * function to set the GUC. We still want to allow that.
+ */
+ if (process_shared_preload_libraries_in_progress &&
+ !allow_when_loading_preload_libs)
+ ereport(ERROR,
+ (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
+ errmsg("cannot change parameters while loading "
+ "\"shared_preload_libraries\"")));
+
if (elevel == 0)
{
if (source == PGC_S_DEFAULT || source == PGC_S_FILE)
@@ -9353,10 +9395,11 @@ define_custom_variable(struct config_generic *variable)
/* First, apply the reset value if any */
if (pHolder->reset_val)
- (void) set_config_option(name, pHolder->reset_val,
- pHolder->gen.reset_scontext,
- pHolder->gen.reset_source,
- GUC_ACTION_SET, true, WARNING, false);
+ (void) set_config_option_internal(name, pHolder->reset_val,
+ pHolder->gen.reset_scontext,
+ pHolder->gen.reset_source,
+ GUC_ACTION_SET, true, WARNING, false,
+ true);
/* That should not have resulted in stacking anything */
Assert(variable->stack == NULL);
--
2.25.1
--+HP7ph2BbKc20aGI--
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
@ 2023-03-01 06:47 Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Michael Paquier @ 2023-03-01 06:47 UTC (permalink / raw)
To: Greg Stark <[email protected]>; +Cc: pgsql-hackers
On Tue, Feb 28, 2023 at 01:45:27PM -0500, Greg Stark wrote:
> So I'm not sure if I'll be CFM this month but I'm assuming I will be
> at this point....
Okay, that's OK for me! Thanks for helping out.
> The next pass would be to grab any patches not marked Ready for
> Committer and if they look like they'll need more than a one round of
> feedback and a couple weeks to polish they'll probably get bounced to
> the next commitfest too. It sucks not getting feedback on your patches
> for so long but there are really just sooo many patches and so few
> eyeballs... It would be great if people could do initial reviews of
> these patches before we bounce them because it really is discouraging
> for developers to send patches and not get feedback. But realistically
> it's going to happen to a lot of patches.
I don't have many patches registered this time for the sole reason of
being able to spend more cycles on reviews and see what could make the
cut. So we'll see how it goes, I guess..
The CF would begin in more or less 5 hours as of the moment of this
message:
https://www.timeanddate.com/time/zones/aoe
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../Y%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
@ 2023-03-02 01:26 ` Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Michael Paquier @ 2023-03-02 01:26 UTC (permalink / raw)
To: Greg Stark <[email protected]>; +Cc: pgsql-hackers
On Wed, Mar 01, 2023 at 03:47:17PM +0900, Michael Paquier wrote:
> The CF would begin in more or less 5 hours as of the moment of this
> message:
> https://www.timeanddate.com/time/zones/aoe
Note: I have switched this CF as "In Process" a few hours ago.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../Y%2F%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
@ 2023-03-06 18:46 ` Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Gregory Stark (as CFM) @ 2023-03-06 18:46 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: pgsql-hackers
Sorry, I wasn't feeling very well since Friday. I'm still not 100% but
I'm going to try to do some triage this afternoon.
There are a few patches that need a rebase. And a few patches failing
Meson builds or autoconf stages -- I wonder if there's something
unrelated broken there?
But what I think is really needed is for committers to pick up patches
that are ready to commit and grab them. There are currently two
patches with macdice marked as committer and one with michael-kun
(i.e. you:)
But what can we do to get more some patches picked up now instead of
at the end of the commitfest? Would it help if I started asking on
existing threads if there's a committer willing to take it up?
On Wed, 1 Mar 2023 at 20:27, Michael Paquier <[email protected]> wrote:
>
> On Wed, Mar 01, 2023 at 03:47:17PM +0900, Michael Paquier wrote:
> > The CF would begin in more or less 5 hours as of the moment of this
> > message:
> > https://www.timeanddate.com/time/zones/aoe
>
> Note: I have switched this CF as "In Process" a few hours ago.
> --
> Michael
--
Gregory Stark
As Commitfest Manager
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-03-15 18:29 ` Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-17 14:56 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-22 04:05 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
0 siblings, 4 replies; 36+ messages in thread
From: Gregory Stark (as CFM) @ 2023-03-15 18:29 UTC (permalink / raw)
To: Gregory Stark (as CFM) <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
So, sorry I've been a bit under the weather but can concentrate on the
commitfest now. I tried to recapitulate the history but the activity
log only goes back a certain distance on the web. If I can log in to
the database I guess I could construct the history from sql queries if
it was important.
But where we stand now is:
Status summary:
Needs review: 152.
Waiting on Author: 42.
Ready for Committer: 39.
Committed: 61.
Moved to next CF: 4.
Withdrawn: 17.
Returned with Feedback: 4.
Total: 319.
Of the Needs Review patches there are 81 that have received no email
messages since the CF began. A lot of those have reviews attached but
presumably those reviewers are mostly from earlier CFs and may have
already contributed all they can.
I don't know, should we move some or all of these to the next CF
already? I'm reluctant to bounce them en masse because there are
definitely some patches that will get reviewed and some that should
really be marked "Ready for Committer".
These patches that are "Needs Review" and have received no comments at
all since before March 1st are these. If your patch is amongst this
list I would suggest any of:
1) Move it yourself to the next CF (or withdraw it)
2) Post to the list with any pending questions asking for specific
feedback -- it's much more likely to get feedback than just a generic
"here's a patch plz review"...
3) Mark it Ready for Committer and possibly post explaining the
resolution to any earlier questions to make it easier for a committer
to understand the state
If there's still no emails on these at some point I suppose it will
make sense to move them out of the CF.
* ALTER TABLE SET ACCESS METHOD on partitioned tables
* New hooks in the connection path
* Add log messages when replication slots become active and inactive
* Avoid use deprecated Windows Memory API
* Remove dead macro exec_subplan_get_plan
* Consider parallel for LATERAL subqueries having LIMIT/OFFSET
* pg_rewind WAL deletion pitfall
* Simplify find_my_exec by using realpath(3)
* Move backup-related code to xlogbackup.c/.h
* Avoid hiding shared filesets in pg_ls_tmpdir (pg_ls_* functions for
showing metadata ...)
* Fix bogus error emitted by pg_recvlogical when interrupted
* warn if GUC set to an invalid shared library
* Check consistency of GUC defaults between .sample.conf and
pg_settings.boot_val
* Code checks for App Devs, using new options for transaction behavior
* Lockless queue of waiters based on atomic operations for LWLock
* Fix assertion failure with next_phase_at in snapbuild.c
* Add SPLIT PARTITION/MERGE PARTITIONS commands
* Add sortsupport for range types and btree_gist
* asynchronous execution support for Custom Scan
* Periodic burst growth of the checkpoint_req counter on replica.
* CREATE INDEX CONCURRENTLY on partitioned table
* Fix ParamPathInfo for union-all AppendPath
* Add OR REPLACE option for CREATE OPERATOR
* ALTER TABLE and CLUSTER fail to use a BulkInsertState for toast tables
* Partial aggregates push down
* Non-replayable WAL records through overflows and >MaxAllocSize lengths
* Enable jitlink as an alternative jit linker of legacy Rtdyld and
add riscv jitting support
* Test for function error in logrep worker
* basebackup: support zstd long distance matching
* pgbench - adding pl/pgsql versions of tests
* Function to log backtrace of postgres processes
* More scalable multixacts buffers and locking
* Remove nonmeaningful prefixes in PgStat_* fields
* COPY FROM enable FORCE_NULL/FORCE_NOT_NULL on all columns
* postgres_fdw: commit remote (sub)transactions in parallel during pre-commit
* Add semi-join pushdown to postgres_fdw
* Skip replicating the tables specified in except table option
* Split index and table statistics into different types of stats
* Exclusion constraints on partitioned tables
* Post-special Page Storage TDE support
* Direct I/O (developer-only feature)
* Improve doc for autovacuum on partitioned tables
* Patch to implement missing join selectivity estimation for range types
* Clarify the behavior of the system when approaching XID wraparound
* Set arbitrary GUC options during initdb
* An attempt to avoid
locally-committed-but-not-replicated-to-standby-transactions in
synchronous replication
* Check lateral references within PHVs for memoize cache keys
* Add n_tup_newpage_upd to pg_stat table views
* monitoring usage count distribution
* Reduce wakeup on idle for bgwriter & walwriter for >5s
* Report the query string that caused a memory error under Valgrind
* New [relation] options engine
* Data is copied twice when specifying both child and parent table in
publication
* possibility to take name, signature and oid of currently executed
function in GET DIAGNOSTICS statement
* Named Operators
* nbtree performance improvements through specialization on key shape
* Fix assertion failure in SnapBuildInitialSnapshot()
* Speed up releasing of locks
* Compression dictionaries
* Improve pg_bsd_indent's handling of multiline initialization expressions
* Add EXPLAIN option GENERIC_PLAN for parameterized queries
* User functions for building SCRAM secrets
* Exit walsender before confirming remote flush in logical replication
* Refactoring postgres_fdw/connection.c
* Add pg_stat_session
* Doc: Improve note about copying into postgres_fdw foreign tables in batch
* Kerberos/GSSAPI Credential Delegation
* 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
* Some revises in adding sorting path
* ResourceOwner refactoring
* 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
* Dynamic result sets from procedures
* BRIN - SK_SEARCHARRAY and scan key preprocessing
* MERGE ... WHEN NOT MATCHED BY SOURCE
* Reuse Workers and Replication Slots during Logical Replication
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-03-17 13:43 ` Greg Stark <[email protected]>
2023-03-17 14:29 ` Re: Commitfest 2023-03 starting tomorrow! Aleksander Alekseev <[email protected]>
2023-03-17 14:38 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
3 siblings, 3 replies; 36+ messages in thread
From: Greg Stark @ 2023-03-17 13:43 UTC (permalink / raw)
To: Gregory Stark (as CFM) <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
On Wed, 15 Mar 2023 at 14:29, Gregory Stark (as CFM)
<[email protected]> wrote:
>
> These patches that are "Needs Review" and have received no comments at
> all since before March 1st are these. If your patch is amongst this
> list I would suggest any of:
>
> 1) Move it yourself to the next CF (or withdraw it)
> 2) Post to the list with any pending questions asking for specific
> feedback -- it's much more likely to get feedback than just a generic
> "here's a patch plz review"...
> 3) Mark it Ready for Committer and possibly post explaining the
> resolution to any earlier questions to make it easier for a committer
> to understand the state
>
> If there's still no emails on these at some point I suppose it will
> make sense to move them out of the CF.
I'm going to go ahead and do this today. Any of these patches that are
"Waiting on Author" and haven't received any emails or status changes
since March 1 I'm going to move out of the commitfest(*). If you
really think your patch in this list is important to get committed
then please respond to the thread explaining any plans or feedback
needed.
It would be nice to actually do Returned With Feedback where
appropriate but there are too many to go through them thoroughly. I'll
only be able to do a quick review of each thread checking for
important bug fixes or obviously rejected patches.
(*) I reserve the right to skip and leave some patches where
appropriate. In particular I'll skip patches that are actually from
committers on the theory that they could just commit them when they
feel like it anyways. Some patches may be intentionally waiting until
the end of the release cycle to avoid conflicts too.
> * ALTER TABLE SET ACCESS METHOD on partitioned tables
> * New hooks in the connection path
> * Add log messages when replication slots become active and inactive
> * Avoid use deprecated Windows Memory API
> * Remove dead macro exec_subplan_get_plan
> * Consider parallel for LATERAL subqueries having LIMIT/OFFSET
> * pg_rewind WAL deletion pitfall
> * Simplify find_my_exec by using realpath(3)
> * Move backup-related code to xlogbackup.c/.h
> * Avoid hiding shared filesets in pg_ls_tmpdir (pg_ls_* functions for
> showing metadata ...)
> * Fix bogus error emitted by pg_recvlogical when interrupted
> * warn if GUC set to an invalid shared library
> * Check consistency of GUC defaults between .sample.conf and
> pg_settings.boot_val
> * Code checks for App Devs, using new options for transaction behavior
> * Lockless queue of waiters based on atomic operations for LWLock
> * Fix assertion failure with next_phase_at in snapbuild.c
> * Add SPLIT PARTITION/MERGE PARTITIONS commands
> * Add sortsupport for range types and btree_gist
> * asynchronous execution support for Custom Scan
> * Periodic burst growth of the checkpoint_req counter on replica.
> * CREATE INDEX CONCURRENTLY on partitioned table
> * Fix ParamPathInfo for union-all AppendPath
> * Add OR REPLACE option for CREATE OPERATOR
> * ALTER TABLE and CLUSTER fail to use a BulkInsertState for toast tables
> * Partial aggregates push down
> * Non-replayable WAL records through overflows and >MaxAllocSize lengths
> * Enable jitlink as an alternative jit linker of legacy Rtdyld and
> add riscv jitting support
> * Test for function error in logrep worker
> * basebackup: support zstd long distance matching
> * pgbench - adding pl/pgsql versions of tests
> * Function to log backtrace of postgres processes
> * More scalable multixacts buffers and locking
> * Remove nonmeaningful prefixes in PgStat_* fields
> * COPY FROM enable FORCE_NULL/FORCE_NOT_NULL on all columns
> * postgres_fdw: commit remote (sub)transactions in parallel during pre-commit
> * Add semi-join pushdown to postgres_fdw
> * Skip replicating the tables specified in except table option
> * Split index and table statistics into different types of stats
> * Exclusion constraints on partitioned tables
> * Post-special Page Storage TDE support
> * Direct I/O (developer-only feature)
> * Improve doc for autovacuum on partitioned tables
> * Patch to implement missing join selectivity estimation for range types
> * Clarify the behavior of the system when approaching XID wraparound
> * Set arbitrary GUC options during initdb
> * An attempt to avoid
> locally-committed-but-not-replicated-to-standby-transactions in
> synchronous replication
> * Check lateral references within PHVs for memoize cache keys
> * Add n_tup_newpage_upd to pg_stat table views
> * monitoring usage count distribution
> * Reduce wakeup on idle for bgwriter & walwriter for >5s
> * Report the query string that caused a memory error under Valgrind
> * New [relation] options engine
> * Data is copied twice when specifying both child and parent table in
> publication
> * possibility to take name, signature and oid of currently executed
> function in GET DIAGNOSTICS statement
> * Named Operators
> * nbtree performance improvements through specialization on key shape
> * Fix assertion failure in SnapBuildInitialSnapshot()
> * Speed up releasing of locks
> * Compression dictionaries
> * Improve pg_bsd_indent's handling of multiline initialization expressions
> * Add EXPLAIN option GENERIC_PLAN for parameterized queries
> * User functions for building SCRAM secrets
> * Exit walsender before confirming remote flush in logical replication
> * Refactoring postgres_fdw/connection.c
> * Add pg_stat_session
> * Doc: Improve note about copying into postgres_fdw foreign tables in batch
> * Kerberos/GSSAPI Credential Delegation
> * 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
> * Some revises in adding sorting path
> * ResourceOwner refactoring
> * 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
> * Dynamic result sets from procedures
> * BRIN - SK_SEARCHARRAY and scan key preprocessing
> * MERGE ... WHEN NOT MATCHED BY SOURCE
> * Reuse Workers and Replication Slots during Logical Replication
--
greg
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
@ 2023-03-17 14:29 ` Aleksander Alekseev <[email protected]>
2 siblings, 0 replies; 36+ messages in thread
From: Aleksander Alekseev @ 2023-03-17 14:29 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>
Hi Greg,
> > These patches that are "Needs Review" and have received no comments at
> > all since before March 1st are these. If your patch is amongst this
> > list I would suggest any of:
> >
> > 1) Move it yourself to the next CF (or withdraw it)
> > 2) Post to the list with any pending questions asking for specific
> > feedback -- it's much more likely to get feedback than just a generic
> > "here's a patch plz review"...
> > 3) Mark it Ready for Committer and possibly post explaining the
> > resolution to any earlier questions to make it easier for a committer
> > to understand the state
Sorry for the late reply. It was a busy week. I see several patches I
authored and/or reviewed in the list. I would like to comment on
those.
* Avoid use deprecated Windows Memory API
We can reject or mark as RwF this one due to controversy and the fact
that the patch doesn't currently apply. I poked the author today.
* Clarify the behavior of the system when approaching XID wraparound
This is a wanted [1][see the discussion] and a pretty straightforward
change. I think it should be targeting PG16.
* Compression dictionaries
This one doesn't target PG16. Moved to the next CF.
* Add pg_stat_session
This patch was in good shape last time I checked but other people had
certain questions. The author hasn't replied since Feb 16th. So it's
unlikely to end up in PG6 and I suggest moving it to the next CF,
unless anyone objects.
* ResourceOwner refactoring
IMO this one still has a chance to make it to PG16. Let's keep it in
the CF for now.
Additionally:
* Add 64-bit XIDs into PostgreSQL 16
Is not going to make it to PG16, moving to the next CF.
* Pluggable toaster
The discussion is happening in the "Compression dictionaries" thread
now, since we decided to join our efforts in this area, see the latest
messages. I suggest marking this thread as RwF, unless anyone objects.
[1]: https://www.postgresql.org/message-id/CAH2-Wz%3D3mmHST-t9aR5LNkivXC%2B18JD_XC0ht4y5LQBLzq%2Bpsg%40ma...
--
Best regards,
Aleksander Alekseev
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
@ 2023-03-17 14:38 ` Tom Lane <[email protected]>
2023-03-17 15:08 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-19 16:05 ` Re: Commitfest 2023-03 starting tomorrow! Peter Eisentraut <[email protected]>
2 siblings, 2 replies; 36+ messages in thread
From: Tom Lane @ 2023-03-17 14:38 UTC (permalink / raw)
To: Greg Stark <[email protected]>; +Cc: Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
Greg Stark <[email protected]> writes:
>> These patches that are "Needs Review" and have received no comments at
>> all since before March 1st are these.
Just a couple of comments on ones that caught my eye:
>> * Simplify find_my_exec by using realpath(3)
The problem with this one is that Peter would like it to do something
other than what I think it should do. Not sure how to resolve that.
>> * Fix assertion failure with next_phase_at in snapbuild.c
This one, and others that are bug fixes, probably deserve more slack.
>> * Periodic burst growth of the checkpoint_req counter on replica.
There is recent discussion of this one no?
>> * Fix ParamPathInfo for union-all AppendPath
I pushed this yesterday.
>> * Add OR REPLACE option for CREATE OPERATOR
I think this one should be flat-out rejected.
>> * Partial aggregates push down
You've listed a lot of small features here that still have time to
get some love --- it's not like we're hard up against the end of the CF.
If they'd been in Waiting on Author state for awhile, I'd agree with
booting them, but not when they're in Needs Review.
>> * Set arbitrary GUC options during initdb
I do indeed intend to push this one on my own authority at some point,
but I'm happy to leave it there for now in case anyone wants to take
another look.
>> * Check lateral references within PHVs for memoize cache keys
I think this one is a bug fix too.
>> * Data is copied twice when specifying both child and parent table in
>> publication
Isn't there active discussion of this one?
>> * Improve pg_bsd_indent's handling of multiline initialization expressions
This is going to get pushed, it's just waiting until the commitfest
settles. I guess you can move it to the next one if you want, but
that won't accomplish much.
regards, tom lane
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-17 14:38 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
@ 2023-03-17 15:08 ` Greg Stark <[email protected]>
1 sibling, 0 replies; 36+ messages in thread
From: Greg Stark @ 2023-03-17 15:08 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Fri, 17 Mar 2023 at 10:39, Tom Lane <[email protected]> wrote:
>
> You've listed a lot of small features here that still have time to
> get some love --- it's not like we're hard up against the end of the CF.
> If they'd been in Waiting on Author state for awhile, I'd agree with
> booting them, but not when they're in Needs Review.
Oh, that's exactly my intent -- when I listed them two days ago it was
a list of Waiting on Author patches without updates since March 1. But
I didn't recheck them this morning yet.
If they've gotten comments in the last two days or had their status
updated then great. It's also possible there are threads that aren't
attached to the commitfest or are attached to a related patch that I
may not be aware of.
--
greg
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-17 14:38 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
@ 2023-03-19 16:05 ` Peter Eisentraut <[email protected]>
2023-03-19 20:56 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
1 sibling, 1 reply; 36+ messages in thread
From: Peter Eisentraut @ 2023-03-19 16:05 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Greg Stark <[email protected]>; +Cc: Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On 17.03.23 15:38, Tom Lane wrote:
>>> Simplify find_my_exec by using realpath(3)
> The problem with this one is that Peter would like it to do something
> other than what I think it should do. Not sure how to resolve that.
I have no objection to changing the internal coding of the current behavior.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-17 14:38 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-03-19 16:05 ` Re: Commitfest 2023-03 starting tomorrow! Peter Eisentraut <[email protected]>
@ 2023-03-19 20:56 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 36+ messages in thread
From: Tom Lane @ 2023-03-19 20:56 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
Peter Eisentraut <[email protected]> writes:
> On 17.03.23 15:38, Tom Lane wrote:
>>> Simplify find_my_exec by using realpath(3)
>> The problem with this one is that Peter would like it to do something
>> other than what I think it should do. Not sure how to resolve that.
> I have no objection to changing the internal coding of the current behavior.
Oh ... where the thread trailed off [1] was you not answering whether
you'd accept a compromise behavior. If it's okay to stick with the
behavior we have, then I'll just do the original patch (modulo Munro's
observations about _fullpath's error reporting).
regards, tom lane
[1] https://www.postgresql.org/message-id/2319396.1664978360%40sss.pgh.pa.us
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
@ 2023-03-18 20:26 ` Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2 siblings, 1 reply; 36+ messages in thread
From: Alvaro Herrera @ 2023-03-18 20:26 UTC (permalink / raw)
To: Greg Stark <[email protected]>; +Cc: Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On 2023-Mar-17, Greg Stark wrote:
> I'm going to go ahead and do this today. Any of these patches that are
> "Waiting on Author" and haven't received any emails or status changes
> since March 1 I'm going to move out of the commitfest(*).
So I've come around to thinking that booting patches out of commitfest
is not really such a great idea. It turns out that the number of active
patch submitters seems to have reached a peak during the Postgres 12
timeframe, and has been steadily decreasing since then; and I think
this is partly due to frustration caused by our patch process.
It turns out that we expect that contributors will keep the patches the
submit up to date, rebasing over and over for months on end, with no
actual review occurring, and if this rebasing activity stops for a few
weeks, we boot these patches out. This is demotivating: people went
great lengths to introduce themselves to our admittedly antiquated
process (no pull requests, remember), we gave them no feedback, and then
we reject their patches with no further effort? I think this is not
good.
At this point, I'm going to suggest that reviewers should be open to the
idea of applying a submitted patch to some older Git commit in order to
review it. If we have given feedback, then it's OK to put a patch as
"waiting on author" and eventually boot it; but if we have not given
feedback, and there is no reason to think that the merge conflicts some
how make the patch fundamentally obsolete, then we should *not* set it
Waiting on Author. After all, it is quite easy to "git checkout" a
slightly older tree to get the patch to apply cleanly and review it
there.
Authors should, of course, be encouraged to keep patches conflict-free,
but this should not be a hard requirement.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
@ 2023-03-18 21:43 ` Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Peter Geoghegan @ 2023-03-18 21:43 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Sat, Mar 18, 2023 at 1:26 PM Alvaro Herrera <[email protected]> wrote:
> At this point, I'm going to suggest that reviewers should be open to the
> idea of applying a submitted patch to some older Git commit in order to
> review it. If we have given feedback, then it's OK to put a patch as
> "waiting on author" and eventually boot it; but if we have not given
> feedback, and there is no reason to think that the merge conflicts some
> how make the patch fundamentally obsolete, then we should *not* set it
> Waiting on Author. After all, it is quite easy to "git checkout" a
> slightly older tree to get the patch to apply cleanly and review it
> there.
It seems plausible that improved tooling that makes it quick and easy
to test a given patch locally could improve things for everybody.
It's possible to do a git checkout to a slightly older tree today, of
course. But in practice it's harder than it really should be. It would
be very nice if there was an easy way to fetch from a git remote, and
then check out a branch with a given patch applied on top of the "last
known good git tip" commit. The tricky part would be systematically
tracking which precise master branch commit is the last known "good
commit" for a given CF entry. That seems doable to me.
I suspect that removing friction when it comes to testing a patch
locally (often just "kicking the tires" of a patch) could have an
outsized impact. If something is made extremely easy, and requires
little or no context to get going with, then people tend to do much
more of it. Even when they theoretically don't have a good reason to
do so. And even when they theoretically already had a good reason to
do so, before the improved tooling/workflow was in place.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
@ 2023-03-18 23:19 ` Justin Pryzby <[email protected]>
2023-03-18 23:28 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Justin Pryzby @ 2023-03-18 23:19 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Sat, Mar 18, 2023 at 02:43:38PM -0700, Peter Geoghegan wrote:
> On Sat, Mar 18, 2023 at 1:26 PM Alvaro Herrera <[email protected]> wrote:
> > At this point, I'm going to suggest that reviewers should be open to the
> > idea of applying a submitted patch to some older Git commit in order to
> > review it. If we have given feedback, then it's OK to put a patch as
> > "waiting on author" and eventually boot it; but if we have not given
> > feedback, and there is no reason to think that the merge conflicts some
> > how make the patch fundamentally obsolete, then we should *not* set it
> > Waiting on Author. After all, it is quite easy to "git checkout" a
> > slightly older tree to get the patch to apply cleanly and review it
> > there.
>
> It seems plausible that improved tooling that makes it quick and easy
> to test a given patch locally could improve things for everybody.
>
> It's possible to do a git checkout to a slightly older tree today, of
> course. But in practice it's harder than it really should be. It would
> be very nice if there was an easy way to fetch from a git remote, and
> then check out a branch with a given patch applied on top of the "last
> known good git tip" commit. The tricky part would be systematically
> tracking which precise master branch commit is the last known "good
> commit" for a given CF entry. That seems doable to me.
It's not only doable, but already possible.
https://www.postgresql.org/message-id/CA%2BhUKGLW2PnHxabF3JZGoPfcKFYRCtx%2Bhu5a5yw%3DKWy57yW5cg%40ma...
The only issue with this is that cfbot has squished all the commits into
one, and lost the original commit messages (if any). I submitted
patches to address that but still waiting for feedback.
https://www.postgresql.org/message-id/[email protected]
--
Justin
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
@ 2023-03-18 23:28 ` Peter Geoghegan <[email protected]>
2023-03-18 23:44 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Peter Geoghegan @ 2023-03-18 23:28 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Sat, Mar 18, 2023 at 4:19 PM Justin Pryzby <[email protected]> wrote:
> The only issue with this is that cfbot has squished all the commits into
> one, and lost the original commit messages (if any). I submitted
> patches to address that but still waiting for feedback.
>
> https://www.postgresql.org/message-id/[email protected]
Right. I would like to see that change. But you still need to have CF
tester/the CF app remember the last master branch commit that worked
before bitrot. And you have to provide an easy way to get that
information.
I generally don't care if that means that I have to initdb - I do that
all the time. It's a small price to pay for a workflow that I know is
practically guaranteed to get me a usable postgres executable on the
first try, without requiring any special effort. I don't want to even
think about bitrot until I'm at least 10 minutes into looking at
something.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-18 23:28 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
@ 2023-03-18 23:44 ` Justin Pryzby <[email protected]>
2023-03-19 22:13 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Justin Pryzby @ 2023-03-18 23:44 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Sat, Mar 18, 2023 at 04:28:02PM -0700, Peter Geoghegan wrote:
> On Sat, Mar 18, 2023 at 4:19 PM Justin Pryzby <[email protected]> wrote:
> > The only issue with this is that cfbot has squished all the commits into
> > one, and lost the original commit messages (if any). I submitted
> > patches to address that but still waiting for feedback.
> >
> > https://www.postgresql.org/message-id/[email protected]
>
> Right. I would like to see that change. But you still need to have CF
> tester/the CF app remember the last master branch commit that worked
> before bitrot. And you have to provide an easy way to get that
> information.
No - the last in cfbot's repo is from the last time it successfully
applied the patch. You can summarily check checkout cfbot's branch to
build (or just to git log -p it, if you dislike github's web interface).
If you're curious and still wanted to know what commit it was applied
on, it's currently the 2nd commit in "git log" (due to squishing
all patches into one).
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-18 23:28 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:44 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
@ 2023-03-19 22:13 ` Thomas Munro <[email protected]>
2023-03-20 00:05 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
2023-03-20 14:14 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-21 09:59 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
0 siblings, 3 replies; 36+ messages in thread
From: Thomas Munro @ 2023-03-19 22:13 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Peter Geoghegan <[email protected]>; Alvaro Herrera <[email protected]>; Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Sun, Mar 19, 2023 at 12:44 PM Justin Pryzby <[email protected]> wrote:
> On Sat, Mar 18, 2023 at 04:28:02PM -0700, Peter Geoghegan wrote:
> > On Sat, Mar 18, 2023 at 4:19 PM Justin Pryzby <[email protected]> wrote:
> > > The only issue with this is that cfbot has squished all the commits into
> > > one, and lost the original commit messages (if any). I submitted
> > > patches to address that but still waiting for feedback.
> > >
> > > https://www.postgresql.org/message-id/[email protected]
> >
> > Right. I would like to see that change. But you still need to have CF
> > tester/the CF app remember the last master branch commit that worked
> > before bitrot. And you have to provide an easy way to get that
> > information.
>
> No - the last in cfbot's repo is from the last time it successfully
> applied the patch. You can summarily check checkout cfbot's branch to
> build (or just to git log -p it, if you dislike github's web interface).
>
> If you're curious and still wanted to know what commit it was applied
> on, it's currently the 2nd commit in "git log" (due to squishing
> all patches into one).
I realised that part of Alvaro's complaint was probably caused by
cfbot's refusal to show any useful information just because it
couldn't apply a patch the last time it tried. A small improvement
today: now it shows a ♲ symbol (with hover text "Rebase needed") if it
doesn't currently apply, but you can still see the most recent CI test
results. And from there you can find your way to the parent commit
ID.
The reason for the previous behaviour is that it had no memory, but I
had to give it one that so I can study flapping tests, log highlights,
statistical trends etc. Reminds me, I also need to teach it to track
the postgres/postgres master mirror's CI results, because it's still
(rather stupidly) testing patches when master itself is failing (eg
the recent slapd commits), which ought to be easy enough to avoid
given the data...
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-18 23:28 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:44 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-19 22:13 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
@ 2023-03-20 00:05 ` Thomas Munro <[email protected]>
2023-03-20 00:10 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2 siblings, 1 reply; 36+ messages in thread
From: Thomas Munro @ 2023-03-20 00:05 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Peter Geoghegan <[email protected]>; Alvaro Herrera <[email protected]>; Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2023 at 11:13 AM Thomas Munro <[email protected]> wrote:
> I realised that part of Alvaro's complaint was probably caused by
> cfbot's refusal to show any useful information just because it
> couldn't apply a patch the last time it tried. A small improvement
> today: now it shows a ♲ symbol (with hover text "Rebase needed") if it
> doesn't currently apply, but you can still see the most recent CI test
> results. And from there you can find your way to the parent commit
> ID.
And in the cases where it still shows no results, that'd be because
the patch set hasn't successfully applied in the past 46 days, ie
since 1 Feb, when cfbot started retaining history. That visible
amnesia should gradually disappear as those patches make progress and
the history window expands. I suppose then someone might complain
that it should be clearer if a patch hasn't applied for a very long
time; suggestions for how to show that are welcome. I wondered about
making them gradually fade out to white, ghost memories that
eventually disappear completely after a few commitfests :-D
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-18 23:28 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:44 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-19 22:13 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
2023-03-20 00:05 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
@ 2023-03-20 00:10 ` Tom Lane <[email protected]>
2023-03-20 00:53 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Tom Lane @ 2023-03-20 00:10 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Peter Geoghegan <[email protected]>; Alvaro Herrera <[email protected]>; Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
Thomas Munro <[email protected]> writes:
> ... I suppose then someone might complain
> that it should be clearer if a patch hasn't applied for a very long
> time; suggestions for how to show that are welcome.
Can you make the pop-up tooltip text read "Rebase needed since
YYYY-MM-DD"?
regards, tom lane
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-18 23:28 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:44 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-19 22:13 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
2023-03-20 00:05 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
2023-03-20 00:10 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
@ 2023-03-20 00:53 ` Thomas Munro <[email protected]>
0 siblings, 0 replies; 36+ messages in thread
From: Thomas Munro @ 2023-03-20 00:53 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Peter Geoghegan <[email protected]>; Alvaro Herrera <[email protected]>; Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2023 at 1:10 PM Tom Lane <[email protected]> wrote:
> Thomas Munro <[email protected]> writes:
> > ... I suppose then someone might complain
> > that it should be clearer if a patch hasn't applied for a very long
> > time; suggestions for how to show that are welcome.
>
> Can you make the pop-up tooltip text read "Rebase needed since
> YYYY-MM-DD"?
Done. It's the GMT date of the first failure to apply.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-18 23:28 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:44 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-19 22:13 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
@ 2023-03-20 14:14 ` Greg Stark <[email protected]>
2 siblings, 0 replies; 36+ messages in thread
From: Greg Stark @ 2023-03-20 14:14 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Peter Geoghegan <[email protected]>; Alvaro Herrera <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
The next level of this would be something like notifying the committer
with a list of patches in the CF that a commit broke. I don't
immediately see how to integrate that with our workflow but I have
seen something like this work well in a previous job. When committing
code you often went and updated other unrelated projects to adapt to
the new API (or could adjust the code you were committing to cause
less breakage).
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-18 23:28 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:44 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-19 22:13 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
@ 2023-03-21 09:59 ` Alvaro Herrera <[email protected]>
2 siblings, 0 replies; 36+ messages in thread
From: Alvaro Herrera @ 2023-03-21 09:59 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Peter Geoghegan <[email protected]>; Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On 2023-Mar-20, Thomas Munro wrote:
> I realised that part of Alvaro's complaint was probably caused by
> cfbot's refusal to show any useful information just because it
> couldn't apply a patch the last time it tried. A small improvement
> today: now it shows a ♲ symbol (with hover text "Rebase needed") if it
> doesn't currently apply, but you can still see the most recent CI test
> results. And from there you can find your way to the parent commit
> ID.
Thank you for improving and continue to think about further enhancements
to the CF bot. It has clearly improved our workflow a lot.
My complaint wasn't actually targetted at the CF bot. It turns out that
I gave a talk on Friday at a private EDB mini-conference about the
PostgreSQL open source process; and while preparing for that one, I
ran some 'git log' commands to obtain the number of code contributors
for each release, going back to 9.4 (when we started using the
'Authors:' tag more prominently). What I saw is a decline in the number
of unique contributors, from its maximum at version 12, down to the
numbers we had in 9.5. We went back 4 years. That scared me a lot.
So I started a conversation about that and some people told me that it's
very easy to be discouraged by our process. I don't need to mention
that it's antiquated -- this in itself turns off youngsters. But in
addition to that, I think newbies might be discouraged because their
contributions seem to go nowhere even after following the process.
This led me to suggesting that perhaps we need to be more lenient when
it comes to new contributors. As I said, for seasoned contributors,
it's not a problem to keep up with our requirements, however silly they
are. But people who spend their evenings a whole week or month trying
to understand how to patch for one thing that they want, to be received
by six months of silence followed by a constant influx of "please rebase
please rebase please rebase", no useful feedback, and termination with
"eh, you haven't rebased for the 1001th time, your patch has been WoA
for X days, we're setting it RwF, feel free to return next year" ...
they are most certainly off-put and will *not* try again next year.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Por suerte hoy explotó el califont porque si no me habría muerto
de aburrido" (Papelucho)
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-03-17 14:56 ` Justin Pryzby <[email protected]>
3 siblings, 0 replies; 36+ messages in thread
From: Justin Pryzby @ 2023-03-17 14:56 UTC (permalink / raw)
To: Gregory Stark (as CFM) <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
On Wed, Mar 15, 2023 at 02:29:26PM -0400, Gregory Stark (as CFM) wrote:
> 1) Move it yourself to the next CF (or withdraw it)
> 2) Post to the list with any pending questions asking for specific
> feedback -- it's much more likely to get feedback than just a generic
> "here's a patch plz review"...
> 3) Mark it Ready for Committer and possibly post explaining the
> resolution to any earlier questions to make it easier for a committer
> to understand the state
>
> If there's still no emails on these at some point I suppose it will
> make sense to move them out of the CF.
> * Avoid hiding shared filesets in pg_ls_tmpdir (pg_ls_* functions for
> showing metadata ...)
My patch. I don't care if it's in v1[3456], but I wish it would somehow
progress - idk what else is needed. I wrote this after Thomas Munro +1
my thinking that it's absurd for pg_ls_tmpdir() to not show [shared]
filesets in tempdirs...
> * CREATE INDEX CONCURRENTLY on partitioned table
My patch. I think there's agreement that this patch is ready, except
that it's waiting on the bugfix for the progress reporting patch. IDK
if there's interest in this, but it'd be a good candidate for v16.
> * basebackup: support zstd long distance matching
My patch. No discussion, but I'm hopeful and don't see why this
shouldn't be in v16.
> * warn if GUC set to an invalid shared library
My patch. I'm waiting for feedback on 0001, which has gotten no
response. I moved it.
> * ALTER TABLE and CLUSTER fail to use a BulkInsertState for toast tables
My patch. There's been no recent discussion, so I guess I'll postpone
it for v17.
> * Check consistency of GUC defaults between .sample.conf and pg_settings.boot_val
IDK what's needed to progress this; If left here, since it will cause
*this* patch to fail if someone else forgets to add a new GUC to the
sample config. Which is odd.
--
Justin
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-03-22 04:05 ` Greg Stark <[email protected]>
3 siblings, 0 replies; 36+ messages in thread
From: Greg Stark @ 2023-03-22 04:05 UTC (permalink / raw)
To: Gregory Stark (as CFM) <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
So a week later
Status summary: March 15 March 22
Needs review: 152 128
Waiting on Author: 42 36
Ready for Committer: 39 32
Committed: 61 82
Moved to next CF: 4 15
Withdrawn: 17 16 (?)
Rejected: 0 5
Returned with Feedback: 4 5
Total: 319.
These patches that are "Needs Review" and have received no comments at
all since before March 1st are now below. There are about 20 fewer
such patches than there were last week.
No emails since August-December 2022:
* New hooks in the connection path
* Add log messages when replication slots become active and inactive
* Remove dead macro exec_subplan_get_plan
* Consider parallel for LATERAL subqueries having LIMIT/OFFSET
* pg_rewind WAL deletion pitfall
* Simplify find_my_exec by using realpath(3)
* Move backup-related code to xlogbackup.c/.h
* Avoid hiding shared filesets in pg_ls_tmpdir (pg_ls_* functions for
showing metadata ...)
* Fix bogus error emitted by pg_recvlogical when interrupted
* Check consistency of GUC defaults between .sample.conf and
pg_settings.boot_val
* Code checks for App Devs, using new options for transaction behavior
* Lockless queue of waiters based on atomic operations for LWLock
* Fix assertion failure with next_phase_at in snapbuild.c
* Add sortsupport for range types and btree_gist
* asynchronous execution support for Custom Scan
* CREATE INDEX CONCURRENTLY on partitioned table
* Partial aggregates push down
* Non-replayable WAL records through overflows and >MaxAllocSize lengths
No emails since January 2023
* Enable jitlink as an alternative jit linker of legacy Rtdyld and add
riscv jitting support
* basebackup: support zstd long distance matching
* pgbench - adding pl/pgsql versions of tests
* Function to log backtrace of postgres processes
* More scalable multixacts buffers and locking
* COPY FROM enable FORCE_NULL/FORCE_NOT_NULL on all columns
* postgres_fdw: commit remote (sub)transactions in parallel during pre-commit
* 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
* Set arbitrary GUC options during initdb
* 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
* Reduce wakeup on idle for bgwriter & walwriter for >5s
* Report the query string that caused a memory error under Valgrind
No emails since February 2023
* New [relation] options engine
* possibility to take name, signature and oid of currently executed
function in GET DIAGNOSTICS statement
* Named Operators
* 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
* User functions for building SCRAM secrets
* Refactoring postgres_fdw/connection.c
* Add pg_stat_session
* Doc: Improve note about copying into postgres_fdw foreign tables in batch
* 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
* Some revises in adding sorting path
* ResourceOwner refactoring
* 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
* Dynamic result sets from procedures
* BRIN - SK_SEARCHARRAY and scan key preprocessing
* Reuse Workers and Replication Slots during Logical Replication
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-03-28 16:12 ` Gregory Stark (as CFM) <[email protected]>
2023-03-29 09:03 ` Re: Commitfest 2023-03 starting tomorrow! Aleksander Alekseev <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
3 siblings, 2 replies; 36+ messages in thread
From: Gregory Stark (as CFM) @ 2023-03-28 16:12 UTC (permalink / raw)
To: Gregory Stark (as CFM) <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
Status summary:
Needs review: 116.
Waiting on Author: 30.
Ready for Committer: 32.
Committed: 94.
Moved to next CF: 17.
Returned with Feedback: 6.
Rejected: 6.
Withdrawn: 18.
Total: 319.
Ok, here are the patches that have been stuck in "Waiting
on Author" for a while. I divided them into three groups.
* The first group have been stuck for over a week and mostly look like
they should be RwF. Some I guess just moved to next CF. But some of
them I'm uncertain if I should leave or if they really should be RfC
or NR.
* The other two groups have had some updates in the last week
(actually I used 10 days). But some of them still look like they're
pretty much dead for this CF and should either be moved forward or
Rwf or Rejected.
So here's the triage list. I'm going to send emails and start clearing
out the patches pretty much right away. Some of these are pretty
clearcut.
Nothing in over a week:
----------------------
* Better infrastructure for automated testing of concurrency issues
- Consensus that this is desirable. But it's not clear what it's
actually waiting on Author for. RwF?
* Provide the facility to set binary format output for specific OID's
per session
- I think Dave was looking for feedback and got it from Tom and
Peter. I don't actually see a specific patch here but there are two
patches linked in the original message. There seems to be enough
feedback to proceed but nobody's working on it. RwF?
* pg_visibility's pg_check_visible() yields false positive when
working in parallel with autovacuum
- Bug, but tentatively a false positive...
* CAST( ... ON DEFAULT)
- it'll have to wait till there's something solid from the committee"
-- Rejected?
* Fix tab completion MERGE
- Partly committed but
v9-0002-psql-Add-PartialMatches-macro-for-better-tab-complet.patch
remains. There was a review from Dean Rasheed. Move to next CF?
* Fix recovery conflict SIGUSR1 handling
- This looks like a suite of bug fixes and looks like it should be
Needs Review or Ready for Commit
* Prefetch the next tuple's memory during seqscans
- David Rowley said it was dependeny on "heapgettup() refactoring"
which has been refactored. So is it now Needs Review or Ready for
Commit? Is it likely to happen this CF?
* Pluggable toaster
- This seems to have digressed from the original patch. There were
patches early on and a lot of feedback. Is the result that the
original patches are Rejected or are they still live?
* psql - refactor echo code
- "I think this patch requires an up-to-date summary and explanation"
from Peter. But it seems like Tom was ok with it and just had some
additional improvements he wanted that were added. It sounds like
this might be "Ready for Commit" if someone familiar with the patch
looked at it.
* Push aggregation down to base relations and joins
- Needs a significant rebase (since March 1).
* Remove self join on a unique column
- An offer of a Bounty! There was one failing test which was
apparently fixed? But it looks like this should be in Needs Review
or Ready for Commit.
* Split index and table statistics into different types of stats
- Was stuck on "Generate pg_stat_get_xact*() functions with Macros"
which was committed. So "Ready for Commit" now?
* Default to ICU during initdb
- Partly committed, 0001 waiting until after CF
* suppressing useless wakeups in logical/worker.c
- Got feedback March 17. Doesn't look like it's going to be ready this CF.
* explain analyze rows=%.0f
- Patch updated January, but I think Tom still had some simple if
tedious changes he asked for
* Fix order of checking ICU options in initdb and create database
- Feedback Last November but no further questions or progress
* Introduce array_shuffle() and array_sample() functions
- Feedback from Tom last September. No further questions or progress
Status Updates in last week:
----------------------------
* Some revises in adding sorting path
- Got feedback Feb 21 and author responded but doesn't look like it's
going to be ready this CF
* Add TAP tests for psql \g piped into program
- Peter Eisentraut asked for a one-line change, otherwise it looks
like it's Ready for Commit?
* Improvements to Meson docs
- Some feedback March 15 but no response. I assume this is still in
play
Emails in last week:
-------------------
* RADIUS tests and improvements
- last feedback March 20, last patch March 4. Should probably be moved
to the next CF unless there's progress soon.
* Direct SSL Connections
- (This is mine) Code for SSL is pretty finished. The last patch for
ALPN support needs a bit of polish. I'll be doing that momentarily.
* Fix alter subscription concurrency errors
- "patch as-submitted is pretty uninteresting" and "patch that I don't
care much about" ... I guess this is Rejected or Withdrawn
* Fix improper qual pushdown after applying outer join identity 3
- Tom Lane's patch. Active discussion as of March 21.
* Error "initial slot snapshot too large" in create replication slot
- Active discussion as of March 24. Is this now Needs Review or Ready
for Committer?
* Transparent column encryption
- Active discussion as of March 24
* Make ON_ERROR_STOP stop on shell script failure
- I rebased this but I think it needs a better review. I may have a
chance to do that or someone else could. The original author
[email protected] seems to have disappeared but the
patch seems to be perhaps committable?
* pg_stats and range statistics
- Updated patch as of March 24, should be Needs Review I guess?
* TDE key management patches
- Actively under discussion
* Reconcile stats in find_tabstat_entry() and get rid of
PgStat_BackendFunctionEntry
- Actively under discussion
--
Gregory Stark
As Commitfest Manager
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-03-29 09:03 ` Aleksander Alekseev <[email protected]>
1 sibling, 0 replies; 36+ messages in thread
From: Aleksander Alekseev @ 2023-03-29 09:03 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Michael Paquier <[email protected]>; Gregory Stark (as CFM) <[email protected]>
Hi,
> * Pluggable toaster
> - This seems to have digressed from the original patch. There were
> patches early on and a lot of feedback. Is the result that the
> original patches are Rejected or are they still live?
We agreed to work on a completely new RFC which is currently discussed
within the "Compression dictionaries" thread, see [1][2] and below. I
guess it means either Rejected or RwF.
[1]: https://www.postgresql.org/message-id/20230203095540.zutul5vmsbmantbm%40alvherre.pgsql
[2]: https://www.postgresql.org/message-id/20230203095658.imkcw2sypawe3py3%40alvherre.pgsql
--
Best regards,
Aleksander Alekseev
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-04-04 15:04 ` Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:18 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-04-07 14:20 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-04-08 15:37 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
1 sibling, 3 replies; 36+ messages in thread
From: Gregory Stark (as CFM) @ 2023-04-04 15:04 UTC (permalink / raw)
To: Gregory Stark (as CFM) <[email protected]>; +Cc: Michael Paquier <[email protected]>; 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
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-04-04 15:18 ` Tom Lane <[email protected]>
2023-04-04 18:36 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2 siblings, 1 reply; 36+ messages in thread
From: Tom Lane @ 2023-04-04 15:18 UTC (permalink / raw)
To: Gregory Stark (as CFM) <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
"Gregory Stark (as CFM)" <[email protected]> writes:
> 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.
Yeah, we just don't have enough people ...
> 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:
I have comments on a few of these:
> * Remove dead macro exec_subplan_get_plan
TBH, I'd reject this one as not being worth the trouble.
> * monitoring usage count distribution
And I'm dubious how many people care about this, either.
> * Improve pg_bsd_indent's handling of multiline initialization expressions
This is going to go in once the commit fest is done; we're just holding
off to avoid creating merge issues during the CF time crunch.
> * clean up permission checks after 599b33b94
I believe that the actual bug fixes are in, and what's left is just a test
case that people weren't very excited about adding. So maybe this should
get closed out as committed.
Perhaps we'll get some of the others done by the end of the week.
regards, tom lane
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:18 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
@ 2023-04-04 18:36 ` Greg Stark <[email protected]>
2023-04-05 07:49 ` Re: Commitfest 2023-03 starting tomorrow! Daniel Gustafsson <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Greg Stark @ 2023-04-04 18:36 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Tue, 4 Apr 2023 at 11:18, Tom Lane <[email protected]> wrote:
>
> > * clean up permission checks after 599b33b94
>
> I believe that the actual bug fixes are in, and what's left is just a test
> case that people weren't very excited about adding. So maybe this should
> get closed out as committed.
I'm not super convinced about this one. I'm not a big "all tests are
good tests" believer but this test seems like a pretty reasonable one.
Permissions checks and user mappings are user-visible behaviour that
are easy to overlook when making changes with unexpected side effects.
It seems like the test would be just as easy to commit as to not
commit and I don't see anything tricky about it that would necessitate
a more in depth review.
--
greg
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:18 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-04-04 18:36 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
@ 2023-04-05 07:49 ` Daniel Gustafsson <[email protected]>
0 siblings, 0 replies; 36+ messages in thread
From: Daniel Gustafsson @ 2023-04-05 07:49 UTC (permalink / raw)
To: Greg Stark <[email protected]>; +Cc: Tom Lane <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
> On 4 Apr 2023, at 20:36, Greg Stark <[email protected]> wrote:
>
> On Tue, 4 Apr 2023 at 11:18, Tom Lane <[email protected]> wrote:
>>
>>> * clean up permission checks after 599b33b94
>>
>> I believe that the actual bug fixes are in, and what's left is just a test
>> case that people weren't very excited about adding. So maybe this should
>> get closed out as committed.
>
> I'm not super convinced about this one. I'm not a big "all tests are
> good tests" believer but this test seems like a pretty reasonable one.
> Permissions checks and user mappings are user-visible behaviour that
> are easy to overlook when making changes with unexpected side effects.
>
> It seems like the test would be just as easy to commit as to not
> commit and I don't see anything tricky about it that would necessitate
> a more in depth review.
Agreed, I think this test has value and don't see a strong reason not to commit
it.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-04-07 14:20 ` Greg Stark <[email protected]>
2023-04-07 22:01 ` Re: Commitfest 2023-03 starting tomorrow! Kirk Wolak <[email protected]>
2 siblings, 1 reply; 36+ messages in thread
From: Greg Stark @ 2023-04-07 14:20 UTC (permalink / raw)
To: Gregory Stark (as CFM) <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
As announced on this list feature freeze is at 00:00 April 8 AoE.
That's less than 24 hours away. If you need to set your watches to AoE
timezone it's currently:
$ TZ=AOE+12 date
Fri 07 Apr 2023 02:05:50 AM AOE
As we stand we have:
Status summary:
Needs review: 82
Waiting on Author: 16
Ready for Committer: 27
Committed: 115
Moved to next CF: 38
Returned with Feedback: 10
Rejected: 9
Withdrawn: 22
Total: 319.
In less than 24h most of the remaining patches will get rolled forward
to the next CF. The 16 that are Waiting on Author might be RwF
perhaps. The only exceptions would be non-features like Bug Fixes and
cleanup patches that have been intentionally held until the end --
those become Open Issues for the release.
So if we move forward all the remaining patches (so these numbers are
high by about half a dozen) the *next* CF would look like:
Commitfest 2023-07: Now April 8
Needs review: 46. 128
Waiting on Author: 17. 33
Ready for Committer: 3. 30
Total: 66 191
I suppose that's better than the 319 we came into this CF with but
there's 3 months to accumulate more unreviewed patches...
I had hoped to find lots of patches that I could bring the hammer down
on and say there's just no interest in or there's no author still
maintaining. But that wasn't the case. Nearly all the patches still
had actively interested authors and looked like they were legitimately
interesting and worthwhile features that people just haven't had the
time to review or commit.
--
greg
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-07 14:20 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
@ 2023-04-07 22:01 ` Kirk Wolak <[email protected]>
2023-04-07 22:29 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Kirk Wolak @ 2023-04-07 22:01 UTC (permalink / raw)
To: Greg Stark <[email protected]>; +Cc: Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Fri, Apr 7, 2023 at 10:21 AM Greg Stark <[email protected]> wrote:
> As announced on this list feature freeze is at 00:00 April 8 AoE.
> That's less than 24 hours away. If you need to set your watches to AoE
> timezone it's currently:
>
> $ TZ=AOE+12 date
> Fri 07 Apr 2023 02:05:50 AM AOE
>
> As we stand we have:
>
> Status summary:
> Needs review: 82
> Waiting on Author: 16
> Ready for Committer: 27
> Committed: 115
> Moved to next CF: 38
> Returned with Feedback: 10
> Rejected: 9
> Withdrawn: 22
> Total: 319.
>
> In less than 24h most of the remaining patches will get rolled forward
> to the next CF. The 16 that are Waiting on Author might be RwF
> perhaps. The only exceptions would be non-features like Bug Fixes and
> cleanup patches that have been intentionally held until the end --
> those become Open Issues for the release.
>
> So if we move forward all the remaining patches (so these numbers are
> high by about half a dozen) the *next* CF would look like:
>
> Commitfest 2023-07: Now April 8
> Needs review: 46. 128
> Waiting on Author: 17. 33
> Ready for Committer: 3. 30
> Total: 66 191
>
> I suppose that's better than the 319 we came into this CF with but
> there's 3 months to accumulate more unreviewed patches...
>
> I had hoped to find lots of patches that I could bring the hammer down
> on and say there's just no interest in or there's no author still
> maintaining. But that wasn't the case. Nearly all the patches still
> had actively interested authors and looked like they were legitimately
> interesting and worthwhile features that people just haven't had the
> time to review or commit.
>
>
> --
> greg
>
> The %T added to the PSQL Prompt is about 5 lines of code. Reviewed and
Ready to commit.
That could knock one more off really quickly :-)
Excellent work to everyone.
Thanks, Kirk
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-07 14:20 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-04-07 22:01 ` Re: Commitfest 2023-03 starting tomorrow! Kirk Wolak <[email protected]>
@ 2023-04-07 22:29 ` Tom Lane <[email protected]>
2023-04-08 02:40 ` Re: Commitfest 2023-03 starting tomorrow! Kirk Wolak <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Tom Lane @ 2023-04-07 22:29 UTC (permalink / raw)
To: Kirk Wolak <[email protected]>; +Cc: Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
Kirk Wolak <[email protected]> writes:
> The %T added to the PSQL Prompt is about 5 lines of code. Reviewed and
> Ready to commit.
> That could knock one more off really quickly :-)
I'm still objecting to it, for the same reason as before.
regards, tom lane
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-07 14:20 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-04-07 22:01 ` Re: Commitfest 2023-03 starting tomorrow! Kirk Wolak <[email protected]>
2023-04-07 22:29 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
@ 2023-04-08 02:40 ` Kirk Wolak <[email protected]>
2023-04-09 23:46 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Kirk Wolak @ 2023-04-08 02:40 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Fri, Apr 7, 2023 at 6:29 PM Tom Lane <[email protected]> wrote:
> Kirk Wolak <[email protected]> writes:
> > The %T added to the PSQL Prompt is about 5 lines of code. Reviewed and
> > Ready to commit.
> > That could knock one more off really quickly :-)
>
> I'm still objecting to it, for the same reason as before.
>
> regards, tom lane
>
Tom,
I got no response to my point that the backquote solution is cumbersome
because I have to use* psql in both windows*
*and in linux environments* (realizing I am the odd duck in this group).
But my fall back was a common script file. Then I shared my
psqlrc file with a co-worker, and they ran into the missing script file.
[ie, the same command does not work in both systems].
I won't argue beyond this point, I'd just like to hear that you
considered this final point...
and I can move on.
Thanks, Kirk
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-07 14:20 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-04-07 22:01 ` Re: Commitfest 2023-03 starting tomorrow! Kirk Wolak <[email protected]>
2023-04-07 22:29 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-04-08 02:40 ` Re: Commitfest 2023-03 starting tomorrow! Kirk Wolak <[email protected]>
@ 2023-04-09 23:46 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 36+ messages in thread
From: Michael Paquier @ 2023-04-09 23:46 UTC (permalink / raw)
To: Kirk Wolak <[email protected]>; +Cc: Tom Lane <[email protected]>; Greg Stark <[email protected]>; Gregory Stark (as CFM) <[email protected]>; pgsql-hackers
On Fri, Apr 07, 2023 at 10:40:01PM -0400, Kirk Wolak wrote:
> I got no response to my point that the backquote solution is cumbersome
> because I have to use* psql in both windows*
> *and in linux environments* (realizing I am the odd duck in this group).
> But my fall back was a common script file. Then I shared my
> psqlrc file with a co-worker, and they ran into the missing script file.
> [ie, the same command does not work in both systems].
>
> I won't argue beyond this point, I'd just like to hear that you
> considered this final point...
> and I can move on.
FYI, this specific patch has been moved to the next commit fest of
2023-07:
https://commitfest.postgresql.org/43/4227/
This implies that this discussion will be considered for the
development cycle of v17, planned to begin in July.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../ZDNOV6e%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Commitfest 2023-03 starting tomorrow!
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
@ 2023-04-08 15:37 ` Greg Stark <[email protected]>
2 siblings, 0 replies; 36+ messages in thread
From: Greg Stark @ 2023-04-08 15:37 UTC (permalink / raw)
To: Gregory Stark (as CFM) <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
So here we are at the end of the CF:
Status summary: March 15 March 22 March 28 April 4 April 8
Needs review: 152 128 116 96 74
Waiting on Author: 42 36 30 21 14
Ready for Committer: 39 32 32 35 27
Committed: 61 82 94 101 124
Moved to next CF: 4 15 17 28 39
Withdrawn: 17 16 18 20 10
Rejected: 0 5 6 8 9
Returned with Feedback: 4 5 6 10 22
Total: 319.
I'm now going to go through and:
a) Mark Waiting on Author any patches that aren't building Waiting on
Author. There was some pushback about asking authors to do trivial
rebases but in three months it won't make sense to start a CF with
already-non-applying patches.
b) Mark any patches that received solid feedback in the last week with
either Returned with Feedback or Rejected. I think this was already
done though with 12 RwF and 1 Rejected in the past four days alone.
c) Pick out the Bug Fixes, cleanup patches, and other non-feature
patches that might be open issues for v16.
d) Move to Next CF any patches that remain.
--
greg
^ permalink raw reply [nested|flat] 36+ messages in thread
end of thread, other threads:[~2023-04-09 23:46 UTC | newest]
Thread overview: 36+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-04-10 21:27 [PATCH v2 3/3] Block attempts to set GUCs while loading shared_preload_libraries. Nathan Bossart <[email protected]>
2023-03-01 06:47 Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-02 01:26 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-03-06 18:46 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-15 18:29 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-17 13:43 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-17 14:29 ` Re: Commitfest 2023-03 starting tomorrow! Aleksander Alekseev <[email protected]>
2023-03-17 14:38 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-03-17 15:08 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-19 16:05 ` Re: Commitfest 2023-03 starting tomorrow! Peter Eisentraut <[email protected]>
2023-03-19 20:56 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-03-18 20:26 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-18 21:43 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:19 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-18 23:28 ` Re: Commitfest 2023-03 starting tomorrow! Peter Geoghegan <[email protected]>
2023-03-18 23:44 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-19 22:13 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
2023-03-20 00:05 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
2023-03-20 00:10 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-03-20 00:53 ` Re: Commitfest 2023-03 starting tomorrow! Thomas Munro <[email protected]>
2023-03-20 14:14 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-21 09:59 ` Re: Commitfest 2023-03 starting tomorrow! Alvaro Herrera <[email protected]>
2023-03-17 14:56 ` Re: Commitfest 2023-03 starting tomorrow! Justin Pryzby <[email protected]>
2023-03-22 04:05 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-03-28 16:12 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-03-29 09:03 ` Re: Commitfest 2023-03 starting tomorrow! Aleksander Alekseev <[email protected]>
2023-04-04 15:04 ` Re: Commitfest 2023-03 starting tomorrow! Gregory Stark (as CFM) <[email protected]>
2023-04-04 15:18 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-04-04 18:36 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-04-05 07:49 ` Re: Commitfest 2023-03 starting tomorrow! Daniel Gustafsson <[email protected]>
2023-04-07 14:20 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
2023-04-07 22:01 ` Re: Commitfest 2023-03 starting tomorrow! Kirk Wolak <[email protected]>
2023-04-07 22:29 ` Re: Commitfest 2023-03 starting tomorrow! Tom Lane <[email protected]>
2023-04-08 02:40 ` Re: Commitfest 2023-03 starting tomorrow! Kirk Wolak <[email protected]>
2023-04-09 23:46 ` Re: Commitfest 2023-03 starting tomorrow! Michael Paquier <[email protected]>
2023-04-08 15:37 ` Re: Commitfest 2023-03 starting tomorrow! Greg Stark <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox