Re: question about pending updates in pgstat_report_inj
От | Sami Imseih |
---|---|
Тема | Re: question about pending updates in pgstat_report_inj |
Дата | |
Msg-id | CAA5RZ0vWqjFJMFMo6wLmrL1ftYazV+-gXfMB31fjMYWnaNgY4Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: question about pending updates in pgstat_report_inj (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: question about pending updates in pgstat_report_inj
|
Список | pgsql-hackers |
> > >Maybe I am missing something obvious for injection_points? > > > > The point of deferring updating shared stats is to avoid contention. That's certainly crucial for something like relationaccess. But it seems extremely unlikely that there would be contention due to injection point stat updates. > > But, uh, the code is incorrect as-is, due to not locking the shared stats > while updating them. Which means it's entirely possible to loose stats updates > if updated by multipole backends. Am I missing something? yes, and that was going to be my next point. There is no locking while updating, which is wrong. Furthermore that flush pending callback, injection_stats_flush_cb, is not required as we have it defined. Well, it's required that we define it, but in this case it could just return true, rather than trying to flush pending data that was never accumulated. I think it's better to use ->pending here, since this is referenced as an example and most real-world cases will likely want to use ->pending for performance reasons. -- Sami
В списке pgsql-hackers по дате отправления: