and build from the source.
> 4. Run “make check” by following the instructions from src/bin/pg_upgrade and
> setting up
> the olddump and oldinstall to point to the “old” installation used in step 2.
> All tests pass.
Hi all,
Following up on this. What remaining work do we need to do t
> Thanks for taking interest in this proposal. There is no remaining
> work for this proposal. It’s now “waiting for review”. It would be
> great if you can provide a review report, so we can change the status
> to “ready for commit”.
> I’ve updated the patch against the latest HEAD.
Hi all,
Rev
Hi Joel,
Thanks for sharing the patch.
I have a few questions based on a cursory first look.
> If a single listener is found, we signal only that backend.
> Otherwise, we fall back to the existing broadcast behavior.
The idea of not wanting to wake up all backends makes sense to me,
but I don’t
Hi all,
There’s been some renewed attention on improving the performance of the
LISTEN/NOTIFY system, which historically hasn’t scaled well under high
notify frequency. Joel Jacobson recently shared some work on optimizing
the LISTEN path [1], and I wanted to follow up with a proposal focused on
t
> "Joel Jacobson" writes:
>
> Unfortunately, the author of [1] jumped to conclusion and assumed
> the global lock was the problem. I'm quite sure it is probably not,
> because:
>
> We know for sure, that current users do LISTEN and NOTIFY
> in the same database. And there is no point in doing NOTI
On Thu, Sep 4, 2025 at 7:14 AM Arseniy Mukhin
wrote:
> Interesting, have you shared your patch and results somewhere? IIUC
> Tom's approach resolves this bug, because with it we have queue
> entries produced by committed transactions only, so we don't need to
> check their status and don't have d
On Fri, Jul 18, 2025 at 10:06 AM Tom Lane wrote:
> After thinking about this for awhile, I have a rough idea of
> something we could do to improve parallelism of NOTIFY.
> As a bonus, this'd allow processes on hot standby servers to
> receive NOTIFYs from processes on the primary, which is a
> fe
On Wed, Sep 3, 2025 at 2:14 PM Matheus Alcantara
wrote:
> IIUC we don't store notifications of aborted transactions on the
> queue. On PreCommit_Notify we add the notifications on the queue
> and on Commit_Notify() we signal the backends.
>
> Or I'm missing something here?
My understandin
Hi Joel, Arseniy, Matheus, thanks for taking a look. I’ve attached an
updated patch and rebased on the latest commits that fixes the
correctness issues.
On Fri, Sep 5, 2025 at 2:38 AM Joel Jacobson wrote:
> What's the definition of the test table?
It’s just a one column integer table defined as
On Tue, Sep 9, 2025 at 4:02 PM Matheus Alcantara
wrote:
>
> FAILED: src/backend/postgres_lib.a.p/access_rmgrdesc_asyncdesc.c.o
> ccache cc -Isrc/backend/postgres_lib.a.p -Isrc/include -I../src/include
> -I/opt/homebrew/Cellar/icu4c@77/77.1/include -I/opt/homebrew/opt/lz4/include
> -I/opt/homebr
On Tue, Sep 9, 2025 at 3:34 PM Matheus Alcantara
wrote:
>
> On Mon Sep 8, 2025 at 9:08 PM -03, Rishu Bagga wrote:
> > Hi Joel, Arseniy, Matheus, thanks for taking a look. I’ve attached an
> > updated patch and rebased on the latest commits that fixes the
> > correctness is
Attached a new patch that resolves failing tests reported by cfbot.
There were still some failing tests on cfbot - related to expecting
new pages to be zeroed in the notify queue, but since we only write a
single compact notify record in a transaction, regardless of the size
or number of notificat
12 matches
Mail list logo
