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
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? |