Re: Table AM and DROP TABLE [ Was: Table AM and DDLs] - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Table AM and DROP TABLE [ Was: Table AM and DDLs]
Date
Msg-id 20220801234424.flhdq6cit7kajxpw@awork3.anarazel.de
Whole thread Raw
In response to Table AM and DROP TABLE [ Was: Table AM and DDLs]  (Mats Kindahl <mats@timescale.com>)
Responses Re: Table AM and DROP TABLE [ Was: Table AM and DDLs]
List 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



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: [DOCS] Stats views and functions not in order?
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] postgresql.conf.sample comment alignment.