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

Re: Spinlock performance improvement proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ian Lance Taylor <ian(at)airs(dot)com>
Cc: "D(dot) Hageman" <dhageman(at)dracken(dot)com>, mlw <markw(at)mohawksoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spinlock performance improvement proposal
Date: 2001-09-27 00:46:51
Message-ID: 14704.1001551611@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Ian Lance Taylor <ian(at)airs(dot)com> writes:
> (Actually, though, Postgres is already vulnerable to erratic behaviour
> because any backend process can corrupt the shared buffer pool.)

Not to mention the other parts of shared memory.

Nonetheless, our experience has been that cross-backend failures due to
memory clobbers in shared memory are very infrequent --- certainly far
less often than we see localized-to-a-backend crashes.  Probably this is
because the shared memory is (a) small compared to the rest of the
address space and (b) only accessed by certain specific modules within
Postgres.

I'm convinced that switching to a thread model would result in a
significant degradation in our ability to recover from coredump-type
failures, even given the (implausible) assumption that we introduce no
new bugs during the conversion.  I'm also *un*convinced that such a
conversion will yield significant performance benefits, unless we
introduce additional cross-thread dependencies (and more fragility
and lock contention) by tactics such as sharing catalog caches across
threads.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Karthik GuruswamyDate: 2001-09-27 00:56:14
Subject: Fragmenting tables in postgres
Previous:From: Tom LaneDate: 2001-09-27 00:26:39
Subject: Re: pg_dump bug

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