Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot
От | Kyotaro Horiguchi |
---|---|
Тема | Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot |
Дата | |
Msg-id | 20230428.160752.1318937619423627249.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot
|
Список | pgsql-bugs |
At Fri, 28 Apr 2023 15:48:16 +0900, Michael Paquier <michael@paquier.xyz> wrote in > On Fri, Apr 28, 2023 at 03:04:04PM +0900, Kyotaro Horiguchi wrote: > > Just I wanted not to do that much in the guc callback including memory > > context operations. If it is compeltly safe, I don't object just > > clearing snapshots in the callback. > > I vaguely recalled some memory context deletions done in one of the > assign callbacks, like the one for the plan resets, but it doesn't > seem to be the case, looking closely.. Hm. For the the record, I'm not saying that it is dangerous to clear snapshots directly in the callback. In fact, as I mentioned earlier, I believe there is no issue with that. But, I believe it is simpler that the actual work is separate from the callback path since we don't need to worry about when the guc-callback will be called. Regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: