Jacob Champion <jacob.champion@enterprisedb.com> writes:
> On Fri, Jul 12, 2024 at 7:59 AM Mohab Yaser
> <mohabyaserofficial2003@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 <efujita@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