Re: archive status ".ready" files may be created too early

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "a(dot)lubennikova(at)postgrespro(dot)ru" <a(dot)lubennikova(at)postgrespro(dot)ru>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "matsumura(dot)ryo(at)fujitsu(dot)com" <matsumura(dot)ryo(at)fujitsu(dot)com>, "masao(dot)fujii(at)gmail(dot)com" <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: archive status ".ready" files may be created too early
Date: 2020-12-17 22:20:35
Message-ID: 27586CFC-D623-429E-BE91-9C83538D6E97@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/15/20, 2:33 AM, "Kyotaro Horiguchi" <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> You're right in that regard. There's a window where partial record is
> written when write location passes F0 after insertion location passes
> F1. However, remembering all spanning records seems overkilling to me.

I'm curious why you feel that recording all cross-segment records is
overkill. IMO it seems far simpler to just do that rather than try to
reason about all these different scenarios and rely on various
(and possibly fragile) assumptions. You only need to record the end
location of records that cross into the next segment (or that fit
perfectly into the end of the current one) and to evaluate which
segments to mark .ready as the "flushed" LSN advances. I'd expect
that in most cases we wouldn't need to store more than a couple of
record boundaries, so it's not like we'd normally be storing dozens of
boundaries. Even if we did need to store several boundaries, AFAICT
the approach I'm proposing should still work well enough.

Nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2020-12-17 23:13:25 Re: Minor documentation error regarding streaming replication protocol
Previous Message Gilles Darold 2020-12-17 22:12:26 Re: [UNVERIFIED SENDER] Re: [BUG] orphaned function