On Wed, Sep 15, 2021 at 2:57 AM Tom Lane wrote:
> Hearing no comments, I pushed that.
Thank you!
> > I'm inclined to think we should flat-out reject LISTEN in any process
> > that is not attached to a frontend, at least until somebody takes the
> > trouble to add infrastructure that would let
I wrote:
> Hence, I present the attached, which also tweaks things to avoid an
> extra pq_flush in the end-of-command code path, and improves the
> comments to discuss the issue of NOTIFYs sent by procedures.
Hearing no comments, I pushed that.
> I'm inclined to think we should flat-out reject
Artur Zakirov writes:
> [ v2-0001-signal-backends-on-commit.patch ]
I had an epiphany while looking at this. Now that PostgresMain
calls ProcessNotifyInterrupt at the same place it calls
ProcessCompletedNotifies (which it does since 790026972), we don't
actually need ProcessCompletedNotifies to
Artur Zakirov writes:
> On Mon, Sep 6, 2021 at 9:27 PM Tom Lane wrote:
>> Hm. So that forecloses back-patching this to earlier than v13.
>> On the other hand, given that we've been ignoring the bug for awhile,
>> maybe a fix that only works in v13+ is good enough. (Or maybe by now
>> it'd be
Thank you Tom for your review.
On Mon, Sep 6, 2021 at 9:27 PM Tom Lane wrote:
>
> Artur Zakirov writes:
> > I attached the patch which fixes it in a different way. It calls
> > SignalBackends() in AtCommit_Notify(). It is possible to call
> > SignalBackends()
> > outside of
Artur Zakirov writes:
> I attached the patch which fixes it in a different way. It calls
> SignalBackends() in AtCommit_Notify(). It is possible to call SignalBackends()
> outside of ProcessCompletedNotifies() after the commit
> 51004c7172b5c35afac050f4d5849839a06e8d3b, which removes necessity of
Should Arthur patch be included in PostgreSQL 14 - Beta 4?
Hello hackers,
On Wed, Jul 14, 2021 at 11:30 AM Sergey Fedchenko wrote:
>
> Hi all! I still can reproduce it on 14beta1 version. I adapted a patch I
> found in this thread
> https://github.com/seregayoga/postgres/commit/338bc33f2cf77edde7c45bfdfb9f39a92ec57eb8
> . It solved this bug for me
Hi all! I still can reproduce it on 14beta1 version. I adapted a patch I found
in this thread
https://github.com/seregayoga/postgres/commit/338bc33f2cf77edde7c45bfdfb9f39a92ec57eb8
. It solved this bug for me (tested with simple Go program using
https://github.com/lib/pq ). It would be nice
On Fri, 2019-06-28 at 17:22 -0400, Alvaro Herrera wrote:
> On 2019-Feb-22, Robert Welin wrote:
>
> > I have reproduced this bug on PostgreSQL version 10.7 and 11.2
> > using the
> > steps described in Michael Powers' original report. The issue also
> > still
> > seems to be present even with the
On 2019-Feb-22, Robert Welin wrote:
> I have reproduced this bug on PostgreSQL version 10.7 and 11.2 using the
> steps described in Michael Powers' original report. The issue also still
> seems to be present even with the patch provided by Sergei Kornilov.
>
> Are there plans to address this
If you are trying to get around the issue for now, what my team did was
cron an insert statement on the database server. We have a queue table that
has some of these triggers setup so it was easy to write a no-op row to the
queue. This had the side effect of flushing the notification queue.
We
I have reproduced this bug on PostgreSQL version 10.7 and 11.2 using the
steps described in Michael Powers' original report. The issue also still
seems to be present even with the patch provided by Sergei Kornilov.
Are there plans to address this issue any time soon or is there some way
I can
On 2018-07-24 18:01:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > One other thing, somewhat independent, I wonder is if it's actually
> > problematic that we don't do ProcessCompletedNotifies() in a bunch of
> > processes, because that means we'll not necessarily call
> >
Andres Freund writes:
> One other thing, somewhat independent, I wonder is if it's actually
> problematic that we don't do ProcessCompletedNotifies() in a bunch of
> processes, because that means we'll not necessarily call
> asyncQueueAdvanceTail(). Perhaps that means we actually *do* need to do
Hi,
On 2018-07-24 17:43:30 -0400, Tom Lane wrote:
> Andres Freund writes:
> > But I wonder if we shouldn't actually move the signalling part of
> > ProcessCompletedNotifies() into CommitTransactionCommand() in v11. Given
> > that transactions can now commit without a ready command being sent,
Andres Freund writes:
> But I wonder if we shouldn't actually move the signalling part of
> ProcessCompletedNotifies() into CommitTransactionCommand() in v11. Given
> that transactions can now commit without a ready command being sent, due
> to the addition of procedures, that kind of seems
Hi Tom, Peter,
On 2018-07-24 21:22:18 +0300, Sergei Kornilov wrote:
> in fact, I've already tried to build fix. Adding ProcessCompletedNotifies to
> apply_handle_commit fixed this issue and i think this is right place. In
> src/backend/tcop/postgres.c we call ProcessCompletedNotifies similar
18 matches
Mail list logo
