On Wed, Jul 20, 2022 at 03:49:17PM +0900, Michael Paquier wrote:
> Adding an extra test to cover the second scenario is easier. So I
> have added one as of the attached, addressing your other comments
> while on it. I have also decided to add the tests at the bottom of
> 001_stream_rep.pl, as the
On Wed, Jul 20, 2022 at 02:00:00PM +0900, Fujii Masao wrote:
> I reported two trouble cases; they are the cases where BASE_BACKUP
> is canceled and terminated, respectively. But you added the test
> only for one of them. Is this intentional?
Nope. The one I have implemented was the fanciest case
On 2022/07/16 11:36, Michael Paquier wrote:
I was thinking about doing that only on HEAD. One thing interesting
about this patch is that it can also be used as a point of reference
for other future things.
Ok, here are review comments:
+my $connstr =
+ $node->connstr('postgres') . " repli
On Fri, Jul 15, 2022 at 04:46:32PM +0900, Fujii Masao wrote:
> On 2022/07/14 17:00, Michael Paquier wrote:
>> and it is possible to rely on
>> pg_stat_activity.wait_event to be BaseBackupThrottle, which would make
>
> ISTM that you can also use pg_stat_progress_basebackup.phase.
Indeed, as of "st
On 2022/07/14 17:00, Michael Paquier wrote:
On Fri, Jul 08, 2022 at 08:56:14AM -0400, Robert Haas wrote:
On Thu, Jul 7, 2022 at 10:58 AM Fujii Masao wrote:
But if many think that it's worth adding the test, I will give a
try. But even in that case, I think it's better to commit the
proposed
On Fri, Jul 08, 2022 at 08:56:14AM -0400, Robert Haas wrote:
> On Thu, Jul 7, 2022 at 10:58 AM Fujii Masao
> wrote:
>> But if many think that it's worth adding the test, I will give a
>> try. But even in that case, I think it's better to commit the
>> proposed patch at first to fix the bug, and t
On Thu, Jul 7, 2022 at 10:58 AM Fujii Masao wrote:
> But if many think that it's worth adding the test, I will give a try. But
> even in that case, I think it's better to commit the proposed patch at first
> to fix the bug, and then to write the patch adding the test.
I don't think that we nece
On 2022/07/07 9:09, Michael Paquier wrote:
On Wed, Jul 06, 2022 at 11:27:58PM +0900, Fujii Masao wrote:
For the test, BASE_BACKUP needs to be canceled after it finishes
do_pg_backup_start(), i.e., checkpointing, and before it calls
do_pg_backup_stop(). So the timing to cancel that seems more
On Wed, Jul 06, 2022 at 11:27:58PM +0900, Fujii Masao wrote:
> For the test, BASE_BACKUP needs to be canceled after it finishes
> do_pg_backup_start(), i.e., checkpointing, and before it calls
> do_pg_backup_stop(). So the timing to cancel that seems more severe
> than the test added in 0475a97f. I
On 2022/07/01 15:41, Michael Paquier wrote:
On Fri, Jul 01, 2022 at 03:32:50PM +0900, Fujii Masao wrote:
Sounds good idea to me. I updated the patch in that way. Attached.
Skimming quickly through the thread, this failure requires a
termination of a backend running BASE_BACKUP. This is bas
On Fri, Jul 01, 2022 at 03:32:50PM +0900, Fujii Masao wrote:
> Sounds good idea to me. I updated the patch in that way. Attached.
Skimming quickly through the thread, this failure requires a
termination of a backend running BASE_BACKUP. This is basically
something done by the TAP test added in 04
On 2022/07/01 15:09, Masahiko Sawada wrote:
The change looks good to me. I've also confirmed the change fixed the issues.
Thanks for the review and test!
@@ -233,6 +233,12 @@ perform_base_backup(basebackup_options *opt, bbsink *sink)
StringInfo labelfile;
StringInfo tblspc_map_f
Hi,
On Thu, Jun 30, 2022 at 12:29 PM Fujii Masao
wrote:
>
> Hi,
>
> I found that the assertion failure and the segmentation fault could
> happen by running pg_backup_start(), pg_backup_stop() and BASE_BACKUP
> replication command, in v15 or before.
>
> Here is the procedure to reproduce the asser
On 2022/07/01 12:05, Kyotaro Horiguchi wrote:
At Fri, 01 Jul 2022 11:56:14 +0900 (JST), Kyotaro Horiguchi
wrote in
At Fri, 01 Jul 2022 11:46:53 +0900 (JST), Kyotaro Horiguchi
wrote in
Please find the attached.
Mmm. It forgot the duplicate-call prevention and query-cancel
handling... Th
At Fri, 01 Jul 2022 11:56:14 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 01 Jul 2022 11:46:53 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > Please find the attached.
>
> Mmm. It forgot the duplicate-call prevention and query-cancel
> handling... The first one is the same as you posted
At Fri, 01 Jul 2022 11:46:53 +0900 (JST), Kyotaro Horiguchi
wrote in
> Please find the attached.
Mmm. It forgot the duplicate-call prevention and query-cancel
handling... The first one is the same as you posted but the second one
is still a problem..
regards.
--
Kyotaro Horiguchi
NTT Open So
At Thu, 30 Jun 2022 12:28:43 +0900, Fujii Masao
wrote in
> The root cause of these failures seems that sessionBackupState flag
> is not reset to SESSION_BACKUP_NONE even when BASE_BACKUP is aborted.
> So attached patch changes do_pg_abort_backup callback so that
> it resets sessionBackupState. I
Hi,
I found that the assertion failure and the segmentation fault could
happen by running pg_backup_start(), pg_backup_stop() and BASE_BACKUP
replication command, in v15 or before.
Here is the procedure to reproduce the assertion failure.
1. Connect to the server as the REPLICATION user who is
18 matches
Mail list logo
