On 21/03/2025 15:24, Yura Sokolov wrote:
I've just rebased patches and merged last two fix-commits (0003 and 0004)
into 0002.
Thanks for reviving this! I looked over this again and committed.
On May 14, 2024 at 14:16 Robert Haas wrote:
I think it would be helpful to make it more clear exactl
I've just rebased patches and merged last two fix-commits (0003 and 0004)
into 0002.
--
regards
Yura Sokolov aka funny-falconFrom f8923c9b8e2f470dd3caaa1e71fb3b931389148b Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Fri, 21 Mar 2025 16:03:30 +0300
Subject: [PATCH v5 1/3] Reapply "libp
On Mon, Jan 29, 2024 at 2:32 AM Kyotaro Horiguchi
wrote:
> [ new patch set ]
Hi,
I think it would be helpful to make it more clear exactly what's going
on here. It looks 0001 is intended to revert
21ef4d4d897563adb2f7920ad53b734950f1e0a4, which was itself a revert of
728f86fec65537eade8d9e751961
Thank you fixing the issue.
At Tue, 23 Jan 2024 11:43:43 +0200, Heikki Linnakangas wrote i
n
> There's an existing AmWalReceiverProcess() macro too. Let's use that.
Mmm. I sought an Is* function becuase "IsLogicalWorker()" is placed on
the previous line. Our convention regarding those functions
On Wed, Jan 24, 2024 at 8:29 PM Fujii Masao wrote:
>
> On Tue, Jan 23, 2024 at 6:43 PM Heikki Linnakangas wrote:
> > There's an existing AmWalReceiverProcess() macro too. Let's use that.
>
> +1
>
> > Hmm, but doesn't bgworker_die() have that problem with exit(1)ing in the
> > signal handler?
>
>
On Tue, Jan 23, 2024 at 6:43 PM Heikki Linnakangas wrote:
> There's an existing AmWalReceiverProcess() macro too. Let's use that.
+1
> Hmm, but doesn't bgworker_die() have that problem with exit(1)ing in the
> signal handler?
Yes, that's a problem. This issue was raised sometimes so far,
but ha
On 23/01/2024 10:24, Kyotaro Horiguchi wrote:
Thank you for looking this!
At Tue, 23 Jan 2024 15:07:10 +0900, Fujii Masao wrote in
Regarding the patch, here are the review comments.
+/*
+ * Is current process a wal receiver?
+ */
+bool
+IsWalReceiver(void)
+{
+ return WalRcv != NULL;
+}
This
On 23/01/2024 06:23, Kyotaro Horiguchi wrote:
At Mon, 22 Jan 2024 13:29:10 -0800, Andres Freund wrote in
Hi,
On 2024-01-19 12:28:05 +0900, Michael Paquier wrote:
On Thu, Jan 18, 2024 at 03:42:28PM +0200, Heikki Linnakangas wrote:
Given that commit 728f86fec6 that introduced this issue was no
Thank you for looking this!
At Tue, 23 Jan 2024 15:07:10 +0900, Fujii Masao wrote
in
> Regarding the patch, here are the review comments.
>
> +/*
> + * Is current process a wal receiver?
> + */
> +bool
> +IsWalReceiver(void)
> +{
> + return WalRcv != NULL;
> +}
>
> This looks wrong because Wa
On Tue, Jan 23, 2024 at 1:23 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 22 Jan 2024 13:29:10 -0800, Andres Freund wrote
> in
> > Hi,
> >
> > On 2024-01-19 12:28:05 +0900, Michael Paquier wrote:
> > > On Thu, Jan 18, 2024 at 03:42:28PM +0200, Heikki Linnakangas wrote:
> > > > Given that commit 728f8
At Mon, 22 Jan 2024 13:29:10 -0800, Andres Freund wrote in
> Hi,
>
> On 2024-01-19 12:28:05 +0900, Michael Paquier wrote:
> > On Thu, Jan 18, 2024 at 03:42:28PM +0200, Heikki Linnakangas wrote:
> > > Given that commit 728f86fec6 that introduced this issue was not strictly
> > > required, perhaps
Hi,
On 2024-01-19 12:28:05 +0900, Michael Paquier wrote:
> On Thu, Jan 18, 2024 at 03:42:28PM +0200, Heikki Linnakangas wrote:
> > Given that commit 728f86fec6 that introduced this issue was not strictly
> > required, perhaps we should just revert it for v16.
>
> Is there a point in keeping 728f8
On Thu, Jan 18, 2024 at 10:42 PM Heikki Linnakangas wrote:
> Given that commit 728f86fec6 that introduced this issue was not strictly
> required, perhaps we should just revert it for v16.
+1 for the revert.
This issue should be fixed in the upcoming minor release
since it might cause unexpected
2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review" [1], but it seems
there were CFbot test failures last time it was run [2]. Please have a
look and post an updated version if necessary.
==
[1] https://commitfest.postgresql.org/46/4748/
[2] https://cirrus-ci.com/github/postg
On Thu, Jan 18, 2024 at 03:42:28PM +0200, Heikki Linnakangas wrote:
> Given that commit 728f86fec6 that introduced this issue was not strictly
> required, perhaps we should just revert it for v16.
Is there a point in keeping 728f86fec6 as well on HEAD? That does not
strike me as wise to keep that
On 18/01/2024 10:26, Kyotaro Horiguchi wrote:
At Sun, 31 Dec 2023 20:07:41 +0900 (JST), Kyotaro Horiguchi
wrote in
We've noticed that when walreceiver is waiting for a connection to
complete, standby does not immediately respond to promotion
requests. In PG14, upon receiving a promotion reques
At Sun, 31 Dec 2023 20:07:41 +0900 (JST), Kyotaro Horiguchi
wrote in
> We've noticed that when walreceiver is waiting for a connection to
> complete, standby does not immediately respond to promotion
> requests. In PG14, upon receiving a promotion request, walreceiver
> terminates instantly, but
(Apology for resubmitting due to poor subject of the previous mail)
---
Hello.
We've noticed that when walreceiver is waiting for a connection to
complete, standby does not immediately respond to promotion
requests. In PG14, upon receiving a promotion request, walreceiver
terminates instantly, but
18 matches
Mail list logo
