On Fri, May 1, 2020 at 5:32 PM Ranier Vilela <ranier...@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 and close 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+1oong6smovbkghkvsftoncrf...@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
