On Thu, Sep 08, 2022 at 02:35:24PM +0300, Dmitry Koval wrote: > Thanks a lot Justin! > > After compilation PostgreSQL+patch with macros > RELCACHE_FORCE_RELEASE, > RANDOMIZE_ALLOCATED_MEMORY, > I saw a problem on Windows 10, MSVC2019.
Yes, it passes tests on my CI improvements branch. https://github.com/justinpryzby/postgres/runs/8248668269 Thanks to Alexander Pyhalov for reminding me about RELCACHE_FORCE_RELEASE last year ;) On Tue, May 31, 2022 at 12:32:43PM +0300, Dmitry Koval wrote: > This can be useful for this example cases: > need to merge all one-day partitions > into a month partition. +1, we would use this (at least the MERGE half). I wonder if it's possible to reduce the size of this patch (I'm starting to try to absorb it). Is there a way to refactor/reuse existing code to reduce its footprint ? partbounds.c is adding 500+ LOC about checking if proposed partitions meet the requirements (don't overlap, etc). But a lot of those checks must already happen, no? Can you re-use/refactor the existing checks ? An UPDATE on a partitioned table will move tuples from one partition to another. Is there a way to re-use that ? Also, postgres already supports concurrent DDL (CREATE+ATTACH and DETACH CONCURRENTLY). Is it possible to leverage that ? (Mostly to reduce the patch size, but also because maybe some cases could be concurrent?). If the patch were split into separate parts for MERGE and SPLIT, would the first patch be significantly smaller than the existing patch (hopefully half as big) ? That would help to review it, even if both halves were ultimately squished together. (An easy way to do this is to open up all the files in separate editor instances, trim out the parts that aren't needed for the first patch, save the files but don't quit the editors, test compilation and regression tests, then git commit --amend -a. Then in each editor, "undo" all the trimmed changes, save, and git commit -a). Would it save much code if "default" partitions weren't handled in the first patch ? -- Justin