Different lock level between AO and AOCO when vacuum opening visimap aux table

[linxu han]

Hi,

I notice that AO vacuum acquires a ShareUpdateExclusive lock when opening the auxiliary table, while AOCO vacuum acquires a Share lock. Is there any design consideration, or is it just a coding mistake？

In my point of view, AO and AOCO table should have no difference in the logic of acquiring  lock, so the lock level should be same.

Since we will lock on QD when update/delete AO tables (Exclusive lock), so maybe it is useless to release lock level of aux table on QE,  but better to be consistent, isn't it?

thanks,

linxu

[Huansong Fu]

Hi Linxu,

Could you please provide a little more details, like the code where you observed the difference (if so)? If you saw it from an actual example, could you please let us know how you created the table and was there any index? And maybe some other details like was it VACUUM or VACUUM FULL, on QD or QE, GPDB 6 or 7?

I looked briefly at the code, the only thing I found slightly related is this: https://github.com/greenplum-db/gpdb/blob/main/src/backend/commands/vacuum.c#L2323-L2324 . So when there's bitmap index on the table we'll lock it in ShareLock on QD before proceeding with vacuum. The purpose was to avoid deadlock because reindex_index() would be called later and it'll acquire ShareLock on the table. However, this is related only if there's bitmap index on the table/aux tables. Not sure if we have bitmap created for the AOCO aux tables in your example somehow. So detailed repro of the problem would be very helpful.

Thanks,

Huansong