On Wed, Jul 29, 2015 at 10:54 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Mon, Jul 27, 2015 at 8:47 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Sat, Jul 25, 2015 at 12:42 AM, Amit Kapila <amit.kapil...@gmail.com> >> wrote: >> > I thought that internal API will automatically take care of it, >> > example for msvc it uses _InterlockedCompareExchange64 >> > which if doesn't work on 32-bit systems or is not defined, then >> > we have to use 32-bit version, but I am not certain about >> > that fact. >> >> Instead of using pg_atomic_uint64, how about using pg_atomic_uint32 >> and storing the pgprocno rather than the pointer directly? >> > > Good Suggestion! > > I think this can work the way you are suggesting and I am working on > same. Here I have one question, do you prefer to see the code for > this optimisation be done via some LWLock interface as Pavan is > suggesting? I am not very sure if LWLock is a good interface for this > work, but surely I can encapsulate it into different functions rather than > doing everything in ProcArrayEndTransaction.
I would try to avoid changing lwlock.c. It's pretty easy when so doing to create mechanisms that work now but make further upgrades to the general lwlock mechanism difficult. I'd like to avoid that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
