Horton

Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Dilip Kumar <dilipbalaut@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-17T18:22:52Z
Lists: pgsql-hackers 
On Thu, Jun 17, 2021 at 2:17 PM Andres Freund <andres@anarazel.de> wrote:
> Adding a hacky special case implementation for cross-database relation
> accesses that violates all kinds of assumptions (like holding a lock on
> a relation when accessing it / pinning pages, processing relcache
> invals, ...) doesn't seem like a good plan.

I agree that we don't want hacky code that violates assumptions, but
bypassing shared_buffers is a bit hacky, too. Can't we lock the
relations as we're copying them? We know pg_class's OID a fortiori,
and we can find out all the other OIDs as we go.

I'm just thinking that the hackiness of going around shared_buffers
feels irreducible, but maybe the hackiness in the patch is something
that can be solved with more engineering.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. When using the WAL-logged CREATE DATABASE strategy, bulk extend.

  2. Avoid using a fake relcache entry to own an SmgrRelation.

  3. Fix data-corruption hazard in WAL-logged CREATE DATABASE.

  4. initdb: When running CREATE DATABASE, use STRATEGY = WAL_COPY.

  5. Simplify a needlessly-complicated regular expression.

  6. In 020_createdb.pl, change order of command-line arguments.

  7. Add new block-by-block strategy for CREATE DATABASE.

  8. Fix replay of create database records on standby

  9. Refactor code for reading and writing relation map files.

  10. Replace RelationOpenSmgr() with RelationGetSmgr().

  11. Refactor the fsync queue for wider use.