On Fri, Jul 12, 2019 at 10:16:21AM +1200, Thomas Munro wrote:
> Attempts to keep subtopics separated have so
> far failed, so the thread ostensibly about orphaned file cleanup is
> now about undo work allocation, but I figured it'd be useful to
> highlight this patch separately as it'll be the first to go in, and
> it's needed by your work Shawn. So I hope we're still on the same
> page with this refactoring patch.
Thanks for reminding me about this thread - I will revisit this again,
had some more feedback after doing my PoC for the pgCon. Need to find
that too...
> One thing I'm not sure about is the TODO message in parsexlog.c's
> extractPageInfo() function.
>
> [1] https://www.postgresql.org/message-id/CA%2BTgmob4htT-9Tq7eHG3wS%3DdpKFbQZOyqgSr1iWmV_65Duz6Pw%40mail.gmail.com
+
+ /* TODO: How should we handle other smgr IDs? */
+ if (smgrid != SMGR_MD)
continue;
All files are copied verbatim from source to target except for relation
files. So this would include slru data and undo data. From what I read
in the docs, I do not believe we need any special handling for either
new SMGRs and your current code should suffice.
process_block_change() is very relation specific so if different
handling is required by different SMGRs, it would make sense to call on
smgr specific functions instead.
Can't wait for the SMGR_MD to SMGR_REL change :-) It will make
understanding this code a tad bit easier.
--
Shawn Debnath
Amazon Web Services (AWS)
