Message-ID: <26aa6466-5a85-6f63-dfc9-24cd1cf36502@oss.nttdata.com>
Date: Fri, 1 Jul 2022 14:02:14 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.10.0
Subject: Re: Backup command and functions can cause assertion failure and
 segmentation fault
Content-Language: en-US
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
References: <3374718f-9fbf-a950-6d66-d973e027f44c@oss.nttdata.com>
 <20220701.114653.401585706513489837.horikyota.ntt@gmail.com>
 <20220701.115614.908767952051113921.horikyota.ntt@gmail.com>
 <20220701.120537.503466015850285563.horikyota.ntt@gmail.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
In-Reply-To: <20220701.120537.503466015850285563.horikyota.ntt@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/26aa6466-5a85-6f63-dfc9-24cd1cf36502%40oss.nttdata.com>
Precedence: bulk


On 2022/07/01 12:05, Kyotaro Horiguchi wrote:
> At Fri, 01 Jul 2022 11:56:14 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
>> At Fri, 01 Jul 2022 11:46:53 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> 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..
> 
> So this is the first cut of that.

Thanks for reviewing the patch!

+	PG_FINALLY();
+	{
  		endptr = do_pg_backup_stop(labelfile->data, !opt->nowait, &endtli);
  	}
-	PG_END_ENSURE_ERROR_CLEANUP(do_pg_abort_backup, BoolGetDatum(false));
-
+	PG_END_TRY();

This change makes perform_base_backup() call do_pg_backup_stop() even when an error is reported while taking a backup, i.e., between PG_TRY() and PG_FINALLY(). Why do_pg_backup_stop() needs to be called in such an error case? It not only cleans up the backup state but also writes the backup-end WAL record, waits for WAL archiving. In an error case, I think that only the cleanup of the backup state is necessary. So it seems ok to use do_pg_abort_backup() in that case, as it is for now.

So I'm still thinking that the patch I posted is simpler and enough.

Regards,

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