| 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.
| 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 |