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

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