From: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Replace known_assigned_xids_lck by memory barrier |
Date: | 2023-08-15 10:29:24 |
Message-ID: | CANtu0ohnGXW6wfM7eXts=m23A1g9D7s1X0ms7bV3-x5oQugX5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello, Nathan.
> What sort of benefits do you see from this patch? It might be worthwhile
> in itself to remove spinlocks when possible, but IME it's much easier to
> justify such changes when there is a tangible benefit we can point to.
Oh, it is not an easy question :)
The answer, probably, looks like this:
1) performance benefits of spin lock acquire removing in
KnownAssignedXidsGetOldestXmin and KnownAssignedXidsSearch
2) it is closing 13-year-old tech depth
But in reality, it is not easy to measure performance improvement
consistently for this change.
> Are the assignments in question guaranteed to be atomic? IIUC we assume
> that aligned 4-byte loads/stores are atomic, so we should be okay as long
> as we aren't handling anything larger.
Yes, 4-bytes assignment are atomic, locking is used to ensure memory
write ordering in this place.
> This use of pg_write_barrier() looks correct to me, but don't we need
> corresponding read barriers wherever we obtain the pointers? FWIW I tend
> to review src/backend/storage/lmgr/README.barrier in its entirety whenever
> I deal with this stuff.
Oh, yeah, you're right! (1)
I'll prepare an updated version of the patch soon. I don't why I was
assuming pg_write_barrier is enough (⊙_⊙')
[1]: https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README.barrier#L125
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2023-08-15 11:09:32 | Avoid a potential unstable test case: xmlmap.sql |
Previous Message | Alvaro Herrera | 2023-08-15 10:15:32 | Re: cataloguing NOT NULL constraints |