| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
| Cc: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, reshkekirill <reshkekirill(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Slow standby snapshot |
| Date: | 2022-11-15 23:06:29 |
| Message-ID: | 1249332.1668553589@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
BTW, while nosing around this code I came across this statement
(procarray.c, about line 4550 in HEAD):
* ... To add XIDs to the array, we just insert
* them into slots to the right of the head pointer and then advance the head
* pointer. This wouldn't require any lock at all, except that on machines
* with weak memory ordering we need to be careful that other processors
* see the array element changes before they see the head pointer change.
* We handle this by using a spinlock to protect reads and writes of the
* head/tail pointers. (We could dispense with the spinlock if we were to
* create suitable memory access barrier primitives and use those instead.)
* The spinlock must be taken to read or write the head/tail pointers unless
* the caller holds ProcArrayLock exclusively.
Nowadays we've *got* those primitives. Can we get rid of
known_assigned_xids_lck, and if so would it make a meaningful
difference in this scenario?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Juan José Santamaría Flecha | 2022-11-15 23:08:56 | Meson add host_system to PG_VERSION_STR |
| Previous Message | Simon Riggs | 2022-11-15 22:59:34 | Re: SUBTRANS: Minimizing calls to SubTransSetParent() |