Re: Freezing without write I/O - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Freezing without write I/O
Date
Msg-id 20130923163743.GC5284@awork2.anarazel.de
Whole thread Raw
In response to Re: Freezing without write I/O  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Just some notes, before I forget them again.

On 2013-09-23 11:50:05 -0400, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 11:11 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2013-09-20 16:47:24 +0200, Andres Freund wrote:
> >> I think we should go through the various implementations and make sure
> >> they are actual compiler barriers and then change the documented policy.
> >
> > From a quick look
> > * S_UNLOCK for PPC isn't a compiler barrier
> > * S_UNLOCK for MIPS isn't a compiler barrier

Needs memory clobber looks easy enough given only gcc seems to be
supported.

> > * I don't know enough about unixware (do we still support that as a
> > platform even) to judge

Looks like another thing to remove?

> > * PA-RISCs tas() might not be a compiler barrier for !GCC
> > * PA-RISCs S_UNLOCK might not be a compiler barrier

http://h21007.www2.hp.com/portal/download/files/unprot/ddk/mem_ordering_pa_ia.pdf

_MF(); seems to work on both PA-RISC and itanic.

> > * HP-UX !GCC might not

The document linked from the source code explains how to implement it:
http://h21007.www2.hp.com/portal/download/files/unprot/itanium/spinlocks.pdf

#define COMP_FENCE _Asm_fence(_UP_MEM_FENCE|_DOWN_MEM_FENCE)

> > * Generic S_UNLOCK *NOT* necessarily a compiler barrier.

Not sure how to handle that one.


Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: record identical operator
Next
From: Robert Haas
Date:
Subject: Re: File_fdw documentation patch to clarify OPTIONS clause