From: | "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca> |
---|---|
To: | "Fujii Masao" <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: POC and rebased patch for CSN based snapshots |
Date: | 2020-06-19 04:36:44 |
Message-ID: | 2020061912364160415939@highgo.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>You mean that the last generated CSN needs to be WAL-logged because any smaller
>CSN than the last one should not be reused after crash recovery. Right?
Yes that's it.
>If right, that WAL-logging seems not necessary because CSN mechanism assumes
>CSN is increased monotonically. IOW, even without that WAL-logging, CSN afer
>crash recovery must be larger than that before. No?
CSN collected based on time of system in this patch, but time is not reliable all the
time. And it designed for Global CSN(for sharding) where it may rely on CSN from
other node , which generated from other machine.
So monotonically is not reliable and it need to keep it's largest CSN in wal in case
of crash.
Regards,
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2020-06-19 05:16:47 | Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute |
Previous Message | David Rowley | 2020-06-19 04:21:18 | Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans |