Re: Spinlock performance improvement proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Spinlock performance improvement proposal
Date
Msg-id 14704.1001551611@sss.pgh.pa.us
Whole thread Raw
In response to Re: Spinlock performance improvement proposal  (Ian Lance Taylor <ian@airs.com>)
List pgsql-hackers
Ian Lance Taylor <ian@airs.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump bug
Next
From: Vince Vielhaber
Date:
Subject: Re: casting for dates