On 08.11.2019 18:06, 曾文旌(义从) wrote:
Thank you very much for inspecting my patch.
Yes, there was bug in my implementation of ON COMMIT DELETE ROWS for GTT.
It is fixed in global_private_temp-6.patch
Yes another bug, also fixed in new version of the patch.
Sorry, I do not understand which lock you are talking about.
I have not introduced any special locks for GTT.
You are right.
But instead of prohibiting ALTER TABLE at all for GTT, we can check
that there are no other backends using it.
I do not think that we should maintain some hash in shared memory to check it.
As far as ALTER TABLE is rare and slow operation in any case, we can just check presence of GTT files
created by other backends.
I have implemented this check in global_private_temp-6.patch
Thank you for noticing it.
Autovacuum full should really be prohibited for GTT.
Storage files will be cleaned in any case on backend termination.
Certainly if backend creates and deletes huge number of GTT in the loop, it can cause space exhaustion.
But it seems to be very strange pattern of GTT usage.
But why do we need some special handling of visibility rules for GTT comparing with normal (local) temp tables?
Them are also not proceeded by autovacuum?
In principle, I have also implemented special visibility rules for GTT, but only for the case when them
are accessed at replica. And it is not included in this patch, because everybody think that access to GTT
replica should be considered in separate patch.
-- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
|Free forum by Nabble||Edit this page|