On Mon, Jan 6, 2014 at 9:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@2ndquadrant.com> writes: >> On 2014-01-06 10:35:59 +0200, Heikki Linnakangas wrote: >>> That assumes that you never hold more than one spinlock at a time, otherwise >>> you can get deadlocks. I think that assumptions holds currently, because >>> acquiring two spinlocks at a time would be bad on performance grounds >>> anyway. > >> I think that's a pretty dangerous assumption > > I think it's a fine assumption. Code that could possibly do that should > never get within hailing distance of being committed, because you are only > supposed to have short straight-line bits of code under a spinlock. > Taking another spinlock breaks both the "straight line code" and the "no > loops" aspects of that coding rule.
OK, so we could do this. But should we? If we're going to get rid of --disable-spinlocks for other reasons, then there's not much point in spending the time to make it work with dynamic shared memory segments that contain locks. In fact, even if we *aren't* going to get rid of it, it's not 100% clear to me that there's much point in supporting that intersection: a big point of the point of dsm is to enable parallelism, and the point of parallelism is to be fast, and if you want things to be fast, you should probably have working spinlocks. Of course, there are some other applications for dynamic shared memory as well, so this isn't a watertight argument, and in a quick test on my laptop, the performance of --disable-spinlocks wasn't horrible, so this argument isn't watertight. I guess the question boils down to: why are we keeping --disable-spinlocks around? If we're expecting that people might really use it for serious work, then it needs to remain and it needs to work with dynamic shared memory. If we're expecting that people might use it while porting PostgreSQL to a new platform but only as an aid to get things up and running, then it needs to remain, but it's probably OK for dynamic shared memory not to work when this option is in use. If nobody uses it at all, then we can just forget the whole thing. I guess my bottom line here is that if --disable-spinlocks is important to somebody, then I'm willing to expend some effort on keeping it working. But if it's just inertia, then I'd rather not spend a lot of time on it. -- 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
