On 2015-12-10 18:36:32 +0100, Andres Freund wrote: > On 2015-12-10 12:19:12 -0500, Robert Haas wrote: > > On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund <and...@anarazel.de> wrote: > > > I've, pushed the fix for the promotion related issue. I'm afraid that > > > the ALTER TABLE <unlogged-table> SET TABLESPACE issue is a bit bigger > > > than it though. > > > > I think that I would have preferred to fix this by flushing unlogged > > buffers in bulk at the end of recovery, rather than by flushing them > > as they are generated. This approach seems needlessly inefficient. > > We touched on that somewhere in the thread - having to scan all of > shared buffers isn't free either, and it'd mean that promotion would > take longer because it'd do all the writes at once. As we don't fsync > them during the flush itself, and as init forks don't ever get > rewritten, I don't think it makes any actual difference? The total > number of writes to the OS is the same, no?
Oh, and the primary, in most places, immediately does an smgrimmedsync() after creating the init fork anyway. So in comparison to that a plain smrwrite() during replay is nearly free. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
