Robert Haas escribió: > All right, so here's a patch that does something along those lines. > We have to always take a new snapshot when somebody scans a catalog > that has no syscache, because there won't be any invalidation messages > to work off of in that case. The only catalog in that category that's > accessed during backend startup (which is mostly what your awful test > case is banging on) is pg_db_role_setting. We could add a syscache > for that catalog or somehow force invalidation messages to be sent > despite the lack of a syscache, but what I chose to do instead is > refactor things slightly so that we use the same snapshot for all four > scans of pg_db_role_setting, instead of taking a new one each time. I > think that's unimpeachable on correctness grounds; it's no different > than if we'd finished all four scans in the time it took us to finish > the first one, and then gotten put to sleep by the OS scheduler for as > long as it took us to scan the other three. Point being that there's > no interlock there.
That seems perfectly acceptable to me, yeah. > The difference is 3-4%, which is quite a lot less than what you > measured before, although on different hardware, so results may vary. 3-4% on that synthetic benchmark sounds pretty acceptable to me, as well. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers