Re: removing old ports and architectures - Mailing list pgsql-hackers

From Andres Freund
Subject Re: removing old ports and architectures
Date
Msg-id 20131015123303.GH5300@awork2.anarazel.de
Whole thread Raw
In response to Re: removing old ports and architectures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: removing old ports and architectures
List pgsql-hackers
On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
> More to the point for this specific case, it seems like our process
> ought to be
> (1) select a preferably-small set of gcc atomic intrinsics that we
> want to use.

I suggest:
* pg_atomic_load_u32(uint32 *)
* uint32 pg_atomic_store_u32(uint32 *)
* uint32 pg_atomic_exchange_u32(uint32 *ptr, uint32 val)
* bool pg_atomic_compare_exchange_u32(uint32 *ptr, uint32 *expected, uint32 newval)
* uint32 pg_atomic_fetch_add_u32(uint32 *ptr, uint32 add)
* uint32 pg_atomic_fetch_sub_u32(uint32 *ptr, uint32 add)
* uint32 pg_atomic_fetch_and_u32(uint32 *ptr, uint32 add)
* uint32 pg_atomic_fetch_or_u32(uint32 *ptr, uint32 add)
* u64 variants of the above
* bool pg_atomic_test_set(void *ptr)
* void pg_atomic_clear(void *ptr)

Ontop of that we can generically implement:
* pg_atomic_add_until_u32(uint32 *ptr, uint32 val, uint32 limit)
* pg_atomic_(add|sub|and|or)_fetch_u32()
* u64 variants of the above

We might also want to provide a generic implementation of the math
operations based on pg_atomic_compare_exchange() to make it easier to
bring up a new architecture.

I think we should leave 64bit support optional for now.

Opinions?

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: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Next
From: "MauMau"
Date:
Subject: Re: Auto-tuning work_mem and maintenance_work_mem