pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Crash by targetted recovery
Date: Tue, 10 Mar 2020 10:50:52 +0900
Message-ID: <0e356860-2c03-bfe6-5256-40ac8f0d6333@oss.nttdata.com> (raw)
In-Reply-To: <203fa5df-f98f-35ac-fea9-2aa2ffcdd31a@oss.nttdata.com>
References: <0db8f83f-5b66-75e9-6d99-93f19fc33165@oss.nttdata.com>
	<20200306.102946.81443433484362211.horikyota.ntt@gmail.com>
	<00dac90c-c37d-0a99-6d4d-97acb48a06bf@oss.nttdata.com>
	<20200309.134927.754909343807949809.horikyota.ntt@gmail.com>
	<203fa5df-f98f-35ac-fea9-2aa2ffcdd31a@oss.nttdata.com>



On 2020/03/09 15:46, Fujii Masao wrote:
> 
> 
> On 2020/03/09 13:49, Kyotaro Horiguchi wrote:
>> At Sat, 7 Mar 2020 01:46:16 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
>>>> (It seems retroverting to the first patch when I started this...)
>>>> The second place covers wider cases so I reverted the first place.
>>>
>>> Thanks for updating the patch that way.
>>> Not sure which patch you're mentioning, though.
>>
>> That meant 0003.
>>
>>> Regarding 0003 patch, I added a bit more detail comments into
>>> the patch so that we can understand the code more easily.
>>> Updated version of 0003 patch attached. Barring any objection,
>>> at first, I plan to commit this patch.
>>
>> Looks good to me. Thanks for writing the detailed comments.
> 
> Thanks for the review! Pushed.
> 
> I will review other two patches later.

Pushed the v5-0001-Tidy-up-XLogSource-usage.patch!

Regarding the remaining patch adding the regression test,

+$result =
+  $node_standby->safe_psql('postgres', "SELECT pg_last_wal_replay_lsn()");
+my ($seg, $off) = split('/', $result);
+my $target = sprintf("$seg/%08X", (hex($off) / $segsize + 1) * $segsize);

What happens if "off" part gets the upper limit and "seg" part needs
to be incremented? What happens if pg_last_wal_replay_lsn() advances
very much (e.g., because of autovacuum) beyond the segment boundary
until the standby restarts? Of course, these situations very rarely happen,
but I'd like to avoid adding such not stable test if possible.

Regards,

-- 
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters





view thread (18+ messages)  latest in thread

Message-ID: <0e356860-2c03-bfe6-5256-40ac8f0d6333@oss.nttdata.com>
Permalink:  ../0e356860-2c03-bfe6-5256-40ac8f0d6333@oss.nttdata.com/
Also on:    postgresql.org/message-id/0e356860-2c03-bfe6-5256-40ac8f0d6333@oss.nttdata.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: masao.fujii@oss.nttdata.com, horikyota.ntt@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: Crash by targetted recovery
  In-Reply-To: <0e356860-2c03-bfe6-5256-40ac8f0d6333@oss.nttdata.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox