Re: CREATE DATABASE ... STRATEGY WAL_LOG issues

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: CREATE DATABASE ... STRATEGY WAL_LOG issues
Date: 2023-03-22 05:11:58
Message-ID: 20230322051158.mkmq24uttohh6prg@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-03-21 09:34:14 -0700, Andres Freund wrote:
> On 2023-03-21 11:33:59 -0400, Robert Haas wrote:
> > That feels like it would be slightly more rational behavior,
> > but I'm not smart enough to guess whether anyone would actually be
> > happier (or less happy) after such a change than they are now.
>
> Yea, I'm not either. The current behaviour does have the feature that it will
> read in some data for each table, but limits trashing of shared buffers for
> huge tables. That's good if your small to medium sized source database isn't
> in s_b, because the next CREATE DATABASE has a change to not need to read the
> data again. But if you have a source database with lots of small relations, it
> can easily lead to swamping s_b.

Patch with the two minimal fixes attached. As we don't know whether it's worth
changing the strategy, the more minimal fixes seem more appropriate.

Greetings,

Andres Freund

Attachment Content-Type Size
v1-0001-Fix-memory-leak-and-inefficiency-in-CREATE-DATABA.patch text/x-diff 1.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-03-22 05:16:28 Re: Initial Schema Sync for Logical Replication
Previous Message Peter Smith 2023-03-22 04:50:07 Re: Data is copied twice when specifying both child and parent table in publication