Skip site navigation (1) Skip section navigation (2)

pgsql: Seems I was too optimistic in supposing that sinval's maxMsgNum

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Seems I was too optimistic in supposing that sinval's maxMsgNum
Date: 2008-06-20 00:24:54
Message-ID: 20080620002454.1C830754595@cvs.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committers
Log Message:
-----------
Seems I was too optimistic in supposing that sinval's maxMsgNum could be
read and written without a lock.  The value itself is atomic, sure, but on
processors with weak memory ordering it's possible for a reader to see the
value change before it sees the associated message written into the buffer
array.  Fix by introducing a spinlock that's used just to read and write
maxMsgNum.  (We could do this with less overhead if we recognized a concept
of "memory access barrier"; is it worth introducing such a thing?  At the
moment probably not --- I can't measure any clear slowdown from adding the
spinlock, so this solution is probably fine.)  Per buildfarm results.

Modified Files:
--------------
    pgsql/src/backend/storage/ipc:
        sinvaladt.c (r1.71 -> r1.72)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/sinvaladt.c?r1=1.71&r2=1.72)

pgsql-committers by date

Next:From: User FxjrDate: 2008-06-22 16:21:39
Subject: npgsql - Npgsql2: [#1003400] Later type binding for DbType.Object
Previous:From: Tom LaneDate: 2008-06-19 21:32:56
Subject: pgsql: Rewrite the sinval messaging mechanism to reduce contention and

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group