| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
| Date: | 2021-09-03 21:54:33 |
| Message-ID: | 20210903215433.jm66bzp2fi4xjnog@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-09-03 14:25:10 +0530, Dilip Kumar wrote:
> Yeah, we can surely lock the relation as described by Robert, but IMHO,
> while creating the database we are already holding the exclusive lock on
> the database and there is no one else allowed to be connected to the
> database, so do we actually need to bother about the lock for the
> correctness?
The problem is that checkpointer, bgwriter, buffer reclaim don't care about
the database of the buffer they're working on... The exclusive lock on the
database doesn't change anything about that. Perhaps you can justify it's safe
because there can't be any dirty buffers or such though.
> I think we already have such a code in multiple places where we bypass the
> shared buffers for copying the relation
> e.g. index_copy_data(), heapam_relation_copy_data().
That's not at all comparable. We hold an exclusive lock on the relation at
that point, and we don't have a separate implementation of reading tuples from
the table or something like that.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2021-09-03 23:17:33 | Re: A reloption for partitioned tables - parallel_workers |
| Previous Message | Tom Lane | 2021-09-03 21:44:43 | Re: Add guc to enable send SIGSTOP to peers when backend exits abnormally |