Re: Backup command and functions can cause assertion failure and segmentation fault

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Backup command and functions can cause assertion failure and segmentation fault
Date: 2022-07-06 14:27:58
Message-ID: fa0f1057-923e-ad61-e6f4-ba5fc29135ec@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 basically
> something done by the TAP test added in 0475a97f with a WAL sender
> killed, and MAX_RATE being used to make sure that we have enough time
> to kill the WAL sender even on fast machines. So you could add a
> regression test, no?

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'm afraid that some tests can easily cancel the BASE_BACKUP while it's performing a checkpoint in do_pg_backup_start(). So for now I'm thinking to avoid such an unstable test.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-07-06 14:30:38 Re: transformLockingClause() bug
Previous Message Tom Lane 2022-07-06 14:20:33 Re: AIX support - alignment issues