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

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Mats Kindahl <mats(at)timescale(dot)com>
Subject: Re: Table AM and DROP TABLE [ Was: Table AM and DDLs]
Date: 2022-02-16 09:07:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 27/09/2021 14:59, Aleksander Alekseev wrote:
> Hi hackers,
>> As a matter of fact, I think the patch I suggested is the right approach:
>> let me elaborate on why.
>> [...]
>> 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.
> Since no one objected in 5 months, I assume Mats made a good point. At least,
> personally, I can't argue.

I agree that having a table AM callback at relation drop would make it
more consistent with creating and truncating a relation. Then again, the
indexam API doesn't have a drop-callback either.

But what can you actually do in the callback? WAL replay of dropping the
storage needs to work without running any AM-specific code. It happens
as part of replaying a commit record. So whatever action you do in the
callback will not be executed at WAL replay. Also, because the callback
merely *schedules* things to happen at commit, it cannot generate
separate WAL records about dropping resources either.

Mats's in-memory table is an interesting example. I guess you don't even
try WAL-logging that, so it's OK that nothing happens at WAL replay. As
you said, the callback to schedule deletion of the shared memory block
and use an end-of-xact callback to perform the deletion. You're
basically re-inventing a pending-deletes mechanism similar to smgr's.

I think you could actually piggyback on smgr's pending-deletions
mechanism instead of re-inventing it. In the callback, you can call
smgrGetPendingDeletes(), and drop the shared memory segment for any
relation in that list.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-02-16 09:30:29 Re: Column Filtering in Logical Replication
Previous Message Masahiko Sawada 2022-02-16 09:04:14 Re: Race conditions in