On Mon, Jan 6, 2014 at 1:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > OTOH, the LWLock mechanism has been stable for long enough now that > we can probably suppose this struct is no more subject to churn than > any other widely-known one, so maybe that consideration is no longer > significant.
On the whole, I'd say it's been more stable than most. But even if we do decide to change it, I'm not sure that really matters very much. We whack widely-used data structures around fairly regularly, and I haven't observed that to cause many problems. Just as one concrete example, PGPROC changes pretty regularly, and I'm not aware of much code that's been broken by that. > Should we get rid of RequestAddinLWLocks() and LWLockAssign(), in > favor of telling extensions to just allocate some space and do > LWLockInit() on it? I don't really see any reason to deprecate that mechanism - it'll just make it harder for people who want to write code that works on multiple PostgreSQL releases to do so easily, and it's my belief that there's a decent amount of third-party code that uses those APIs. EnterpriseDB has some, for example. Broadly, I don't see any problem with presuming that most code that uses lwlocks will be happy to keep those lwlocks in the main array while allowing them to be stored elsewhere in those cases where that's not convenient. Perhaps in the long run that won't be true, but then again perhaps it will. Either way, I don't see a real reason to rush into a change in policy. -- 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
