RE: archive status ".ready" files may be created too early - Mailing list pgsql-hackers

From matsumura.ryo@fujitsu.com
Subject RE: archive status ".ready" files may be created too early
Date
Msg-id OSAPR01MB50270BF01719418683625CECE8660@OSAPR01MB5027.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: archive status ".ready" files may be created too early  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: archive status ".ready" files may be created too early  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Re: archive status ".ready" files may be created too early  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
Hello, Horiguchi-san

At Monday, July 6, 2020 05:13:40 +0000,  "Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>" wrote in
> > > after WAL buffer is filled up to the requested position. So when it
> > > crosses segment boundary we know the all past corss segment-boundary
> > > records are stable. That means all we need to remember is only the
> > > position of the latest corss-boundary record.
> >
> > I could not agree. In the following case, it may not work well.
> > - record-A and record-B (record-B is a newer one) is copied, and
> > - lastSegContRecStart/End points to record-B's, and
> > - FlushPtr is proceeded to in the middle of record-A.
>
> IIUC, that means record-B is a cross segment-border record and we hav e
> flushed beyond the recrod-B. In that case crash recovery afterwards
> can read the complete record-B and will finish recovery *after* the
> record-B. That's what we need here.

I'm sorry I didn't explain enough.

Record-A and Record-B are cross segment-border records.
Record-A spans segment X and X+1
Record-B spans segment X+2 and X+3.
If both records have been inserted to WAL buffer, lastSegContRecStart/End points to Record-B.
If a writer flushes upto the middle of segment-X+1, NotifyStableSegments() allows the writer to notify segment-X.
Is my understanding correct?

Regards
Ryo Matsumrua



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Resetting spilled txn statistics in pg_stat_replication
Next
From: Etsuro Fujita
Date:
Subject: Re: Performing partition pruning using row value