Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Mon, 2021-03-22 at 09:46 -0400, Stephen Frost wrote: > > * tsunakawa.ta...@fujitsu.com (tsunakawa.ta...@fujitsu.com) wrote: > > > From: Stephen Frost <sfr...@snowman.net> > > > > The argument here seems to stem from the idea that issueing a 'TRUNCATE' > > > > inside the transaction before starting the 'COPY' command is 'too hard'. > > > > > > No, we can't ask using TRUNCATE because the user wants to add data to a > > > table. > > > > First- what are you expecting would actually happen during crash > > recovery in this specific case with your proposed new WAL level? > > > > Second, use partitioning, or unlogged tables (with the patch discussed > > elsewhere to allow flipping them to logged without writing the entire > > thing to WAL). > > Perhaps allowing to set unlogged tables to logged ones without writing WAL > is a more elegant way to do that, but I cannot see how that would be any > more crash safe than this patch. Besides, the feature doesn't exist yet.
I'm not suggesting it's somehow more crash safe- but it's at least very clear what happens in such a case, to wit: the entire table is cleared on crash recovery. > So I think that argument doesn't carry much weight. We're talking about two different ways to accomplish essentially the same thing- one which introduces a new WAL level, vs. one which adds an optimization for a WAL level we already have. That the second is more elegant is more-or-less entirely the point I'm making here, so it seems pretty relevant. Thanks, Stephen
signature.asc
Description: PGP signature
