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

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: bossartn(at)amazon(dot)com, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, hlinnaka(at)iki(dot)fi, matsumura(dot)ryo(at)fujitsu(dot)com, masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: archive status ".ready" files may be created too early
Date: 2021-01-06 06:53:52
Message-ID: 60C21920-AB0D-43AF-BDB9-98E70153B654@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

Thanks for working on this.

> 18 дек. 2020 г., в 10:42, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> написал(а):
>
> I noticed that we can cause the continuation record flushed
> immedately.

I've took a look into the code and want to share some thoughts.

1. Maybe we could tend to avoid interlacing field protected by different locks in XLogCtlData? We can place lastNotifiedSeg somewhere near field that is protected by WALWriteLock. I'm not sure it's useful idea.
2. In XLogInsertRecord() we release &XLogCtl->info_lck just to compute few bytes. And possibly aquire it back. Maybe just hold the lock a little longer?
3. Things that are done by GetLastNotifiedSegment() could just be atomic read? I'm not sure it's common practice.

Thanks!

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hou, Zhijie 2021-01-06 06:57:31 RE: Parallel Inserts in CREATE TABLE AS
Previous Message Luc Vlaming 2021-01-06 06:53:14 Re: Parallel Inserts in CREATE TABLE AS