Re: Strange Windows problem, lock_timeout test request - Mailing list pgsql-hackers

2013-03-18 06:47 keltezéssel, Tom Lane írta:
> Boszormenyi Zoltan <zb@cybertec.at> writes:
>>> The volatile marking shouldn't even be necessary there.
>>> The signal handler doesn't writes to it, only the main code.
> Well, (a) that's not the case in the patch as committed, and (b) even if
> it were true, the volatile marking is still *necessary*, because that's
> what tells the compiler it can't optimize away changes to the variable,
> say on the grounds of there being another store with no intervening
> fetches in the main-line code.  Without that, a compiler that had
> aggressively inlined the smaller functions could well deduce that the
> disable_alarm() assignment was useless.
>
>> Also, since the the variable assignment doesn't depend on other code
>> in the same function (or vice-versa) the compiler is still free to
>> reorder it.
>> Volatile is about not caching the variable in a CPU register since
>> it's "volatile"...
> I don't believe you understand what volatile is about at all.  Go read
> the C standard: it's about requiring objects' values to actually match
> the nominal program-specified values at sequence points.  A more
> accurate heuristic is that volatile tells the compiler there may be
> other forces reading or writing the variable besides the ones it can see
> in the current function's source code, and so it can't drop or reorder
> accesses to the variable.
>
>             regards, tom lane

After reading up on a lot of volatile and memory barriers,
I am still not totally convinced.

For the record, sig_atomit_t is a plain int without any special
treatment from the compiler. It's atomic by nature on every 32-bit
and 64-bit CPU.

How about the attached patch over current GIT? In other words,
why I am wrong with this idea?

The problem that may arise if it's wrong is that transactions are
left waiting for the lock when the interrupt triggers and the variable
is still seen as false from the interrupt handler. But this doesn't happen.

FWIW, this small patch seems to give a 0,7 percent performance
boost for my settings:

shared_buffers = 256MB
work_mem = 8MB
effective_io_concurrency = 8
wal_level = hot_standby
checkpoint_segments = 64
random_page_cost = 1.8

Everything else is the default. I tested the patch on a 8-core
AMD FX-8120 CPU with this pgbench script below. Basically, it's
the default transaction prepended with "SET lock_timeout = 1;"
I have used the attached quick-and-dirty patch to pgbench to
ignore SQL errors coming from statements. "-s 100" was used
to initialize the test database.

\set nbranches 1 * :scale
\set ntellers 10 * :scale
\set naccounts 100000 * :scale
\setrandom aid 1 :naccounts
\setrandom bid 1 :nbranches
\setrandom tid 1 :ntellers
\setrandom delta -5000 5000
BEGIN;
SET lock_timeout = 1;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid,
:delta, CURRENT_TIMESTAMP);
END;

Results of "pgbench -c 32 -j 32 -t 10000 -e -f script.sql" are
for the GIT version:

tps = 3366.844023 (including connections establishing)
tps = 3367.645454 (excluding connections establishing)

tps = 3379.784707 (including connections establishing)
tps = 3380.622317 (excluding connections establishing)

tps = 3385.198238 (including connections establishing)
tps = 3386.132433 (excluding connections establishing)

and with the barrier patch:

tps = 3412.799044 (including connections establishing)
tps = 3413.670832 (excluding connections establishing)

tps = 3389.796287 (including connections establishing)
tps = 3390.602187 (excluding connections establishing)

tps = 3405.924548 (including connections establishing)
tps = 3406.726997 (excluding connections establishing)

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
      http://www.postgresql.at/