Commitfest 2023-03 starting tomorrow!

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

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

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 <michael@paquier.xyz> 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

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

On Wed, 15 Mar 2023 at 14:29, Gregory Stark (as CFM)
<stark.cfm@gmail.com> 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

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]/messages/by-id/CAH2-Wz=3mmHST-t9aR5LNkivXC+18JD_XC0ht4y5LQBLzq+psg@mail.gmail.com[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]: /messages/by-id/CAH2-Wz=3mmHST-t9aR5LNkivXC+18JD_XC0ht4y5LQBLzq+psg@mail.gmail.com

--
Best regards,
Aleksander Alekseev

Greg Stark <stark@mit.edu> 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

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

On Fri, 17 Mar 2023 at 10:39, Tom Lane <tgl@sss.pgh.pa.us> 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

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/

On Sat, Mar 18, 2023 at 1:26 PM Alvaro Herrera <alvherre@alvh.no-ip.org> 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

On Sat, Mar 18, 2023 at 02:43:38PM -0700, Peter Geoghegan wrote:

On Sat, Mar 18, 2023 at 1:26 PM Alvaro Herrera <alvherre@alvh.no-ip.org> 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.

/messages/by-id/CA+hUKGLW2PnHxabF3JZGoPfcKFYRCtx+hu5a5yw=KWy57yW5cg@mail.gmail.com

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.

/messages/by-id/20220623193125.GB22452@telsasoft.com

--
Justin

On Sat, Mar 18, 2023 at 4:19 PM Justin Pryzby <pryzby@telsasoft.com> 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.

/messages/by-id/20220623193125.GB22452@telsasoft.com

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

On Sat, Mar 18, 2023 at 04:28:02PM -0700, Peter Geoghegan wrote:

On Sat, Mar 18, 2023 at 4:19 PM Justin Pryzby <pryzby@telsasoft.com> 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.

/messages/by-id/20220623193125.GB22452@telsasoft.com

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).

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.

Peter Eisentraut <peter.eisentraut@enterprisedb.com> 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]/messages/by-id/2319396.1664978360@sss.pgh.pa.us 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]: /messages/by-id/2319396.1664978360@sss.pgh.pa.us

On Sun, Mar 19, 2023 at 12:44 PM Justin Pryzby <pryzby@telsasoft.com> 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 <pryzby@telsasoft.com> 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.

/messages/by-id/20220623193125.GB22452@telsasoft.com

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...

On Mon, Mar 20, 2023 at 11:13 AM Thomas Munro <thomas.munro@gmail.com> 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

Thomas Munro <thomas.munro@gmail.com> 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