On Fri, May 1, 2020 at 5:32 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
> I can suggest improvements?
>
> 1. In case Object is cached, delay open_table until the last moment, for the row to be blocked as little as possible
andclose the table as quickly as possible.
> 2. In case Object is cached and the tuple is invalid, do not open table.
> 3. Otherwise, is it possible to call systable_endscan, after table_close?
>
> I think that lock resources, for as little time as possible, it is an advantage..
Only if it's correct, which (3) definitely wouldn't be, and I'm
doubtful about (1) as well.
This reminds me: I think that the issues in
http://postgr.es/m/CA+TgmoYaFYRRdRZ94p_Qdt+1oONg6sMOvbkGHKVsFtONCrFkhw@mail.gmail.com
should be considered here - we should guarantee that there's a
snapshot registered continuously from before the call to
SearchSysCache1 until after the call to CatalogTupleDelete. In the
systable_beginscan case, we should be fine as long as the
systable_endscan follows the CatalogTupleDelete call.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
