Jacob Champion <jacob.champ...@enterprisedb.com> writes: > On Fri, Jul 12, 2024 at 7:59 AM Mohab Yaser > <mohabyaserofficial2...@gmail.com> wrote: >> So if anyone faced the same problem please let me know.
> I agree that it's rough at the moment. I don't pretend to have any > solutions, but you might check the Bug Fixes section of the current > Commitfest, to help review: > https://commitfest.postgresql.org/48/ Certainly, the CF app is a good place to find out about bugs that someone else is already working on. As far as checking the status of reports in the bugs mailing list goes, we don't have a tracker for that (yes, it's been discussed). If the mailing list thread about a bug doesn't make the status obvious, you could search the commit log to see if the thread is referenced anywhere. For example, this set of commits closed out bug #18467: ----- Author: Etsuro Fujita <efuj...@postgresql.org> Branch: master Release: REL_17_BR [8cfbac149] 2024-06-07 17:45:00 +0900 Branch: REL_16_STABLE [8405d5a37] 2024-06-07 17:45:02 +0900 Branch: REL_15_STABLE [b33c141cc] 2024-06-07 17:45:04 +0900 Branch: REL_14_STABLE [269e2c391] 2024-06-07 17:45:06 +0900 Branch: REL_13_STABLE [2b461efc5] 2024-06-07 17:45:08 +0900 postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote servers. Previously, when considering LIMIT pushdown, postgres_fdw failed to check whether the query has this clause, which led to pushing false LIMIT clauses, causing incorrect results. This clause has been supported since v13, so we need to do a remote-version check before deciding that it will be safe to push such a clause, but we do not currently have a way to do the check (without accessing the remote server); disable pushing such a clause for now. Oversight in commit 357889eb1. Back-patch to v13, where that commit added the support. Per bug #18467 from Onder Kalaci. Patch by Japin Li, per a suggestion from Tom Lane, with some changes to the comments by me. Review by Onder Kalaci, Alvaro Herrera, and me. Discussion: https://postgr.es/m/18467-7bb89084ff03a08d%40postgresql.org ----- (This output is from our tool src/tools/git_changelog, which I like because it knows how to collapse similar commits across various branches into one entry.) As this example shows, it's now standard for PG commit log messages to include a link to the relevant email thread, so all you need is the message-ID of the first message in the thread to search the commit log with. regards, tom lane
