From: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Subject: | Re: [patch] demote |
Date: | 2020-06-25 17:27:54 |
Message-ID: | 20200625192754.3e105cfc@firost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Here is a summary of my work during the last few days on this demote approach.
Please, find in attachment v2-0001-Demote-PoC.patch and the comments in the
commit message and as FIXME in code.
The patch is not finished or bug-free yet, I'm still not very happy with the
coding style, it probably lack some more code documentation, but a lot has
changed since v1. It's still a PoC to push the discussion a bit further after
being myself silent for some days.
The patch is currently relying on a demote checkpoint. I understand a forced
checkpoint overhead can be massive and cause major wait/downtime. But I keep
this for a later step. Maybe we should be able to cancel a running checkpoint?
Or leave it to its synching work but discard the result without wirting it to
XLog?
I hadn't time to investigate Robert's concern about shared memory for snapshot
during recovery.
The patch doesn't deal with prepared xact yet. Testing "start->demote->promote"
raise an assert if some prepared xact exist. I suppose I will rollback them
during demote in next patch version.
I'm not sure how to divide this patch in multiple small independent steps. I
suppose I can split it like:
1. add demote checkpoint
2. support demote: mostly postmaster, startup/xlog and checkpointer related
code
3. cli using pg_ctl demote
...But I'm not sure it worth it.
Regards,
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Demote-PoC.patch | text/x-patch | 48.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2020-06-25 17:44:42 | Re: Default setting for enable_hashagg_disk |
Previous Message | Bruce Momjian | 2020-06-25 17:17:56 | Re: Default setting for enable_hashagg_disk |