Re: Table AM and DROP TABLE [ Was: Table AM and DDLs]

From: Andres Freund <andres(at)anarazel(dot)de>
To: Mats Kindahl <mats(at)timescale(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Table AM and DROP TABLE [ Was: Table AM and DDLs]
Date: 2022-08-01 23:44:24
Message-ID: 20220801234424.flhdq6cit7kajxpw@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-04-05 21:57:12 +0200, Mats Kindahl wrote:
> 2. In the storage layer, the function RelationDropStorage is called,
> which will record the table to be dropped in the pendingDeletes
>
> When committing (or aborting) the transaction, there are two calls that are
> interesting, in this order:
>
> 1. CallXactCallbacks which calls registered callbacks
> 2. smgrDoPendingDeletes, which calls the storage layer directly to
> perform the actual deletion, if necessary.
>
> Now, suppose that we want to replace the storage layer with a different
> one. It is straightforward to replace it by implementing the Table AM
> methods above, but we are missing a callback on dropping the table. If we
> have that, we can record the table-to-be-dropped in a similar manner to how
> the heap AM does it and register a transaction callback using
> RegisterXactCallback.

I don't think implementing dropping relation data at-commit/rollback using
xact callbacks can be correct. The dropping needs to be integrated with the
commit / abort records, so it is redone during crash recovery - that's not
possible with xact callbacks.

To me it still seems fundamentally the wrong direction to implement a "drop
relation callback" tableam callback.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-08-02 00:03:24 Re: [PATCH] postgresql.conf.sample comment alignment.
Previous Message Peter Smith 2022-08-01 23:40:26 [DOCS] Stats views and functions not in order?