On Tue, Jul 30, 2024 at 12:39 PM Thomas Munro wrote:
> On Tue, Jul 30, 2024 at 11:16 AM Heikki Linnakangas wrote:
> > I think we should do:
> >
> > #ifdef _M_AMD64
> > #define __x86_64__
> > #endif
> >
> > somewhere, perhaps in src/include/port/win32.h.
I suppose we could define our own
PG_ARCH_
On Thu, Aug 1, 2024 at 10:38 AM Andres Freund wrote:
> On 2024-08-01 10:09:07 +1200, Thomas Munro wrote:
> > On Thu, Aug 1, 2024 at 7:07 AM Andres Freund wrote:
> > > Note that I would like to add a user for S_LOCK_FREE(), to detect repeated
> > > SpinLockRelease():
> > > https://postgr.es/m/2024
Hi,
On 2024-08-01 10:09:07 +1200, Thomas Munro wrote:
> On Thu, Aug 1, 2024 at 7:07 AM Andres Freund wrote:
> > Note that I would like to add a user for S_LOCK_FREE(), to detect repeated
> > SpinLockRelease():
> > https://postgr.es/m/20240729182952.hua325647e2ggbsy%40awork3.anarazel.de
>
> What
On Thu, Aug 1, 2024 at 7:07 AM Andres Freund wrote:
> Note that I would like to add a user for S_LOCK_FREE(), to detect repeated
> SpinLockRelease():
> https://postgr.es/m/20240729182952.hua325647e2ggbsy%40awork3.anarazel.de
What about adding a "magic" member in assertion builds? Here is my
atte
Hi,
On 2024-07-31 22:32:19 +1200, Thomas Munro wrote:
> > That old comment means that both SpinLockAcquire() and SpinLockRelease()
> > acted as full memory barriers, and looking at the implementations, that
> > was indeed so. With the new implementation, SpinLockAcquire() will have
> > "acquire se
Hi,
On 2024-07-30 23:08:36 +1200, Thomas Munro wrote:
> On Tue, Jul 30, 2024 at 12:39 PM Thomas Munro wrote:
> > On Tue, Jul 30, 2024 at 11:16 AM Heikki Linnakangas wrote:
> > > Looks good to me.
> >
> > Thanks. I'll wait just a bit longer to see if anyone else has comments.
>
> And pushed.
Y
Hi,
On 2024-07-31 17:52:34 +1200, Thomas Munro wrote:
> 2. The pg_atomic_unlocked_test_flag() function was surprising to me:
> it returns true if it's not currently set (according to a relaxed
> load). Most of this patch was easy, but figuring out that I had
> reverse polarity here was a multi-c
On Wed, Jul 31, 2024 at 8:47 PM Heikki Linnakangas wrote:
> On 31/07/2024 08:52, Thomas Munro wrote:
> The old __i386__ implementation of TAS() said:
>
> >* When this was last tested, we didn't have separate TAS() and
> > TAS_SPIN()
> >* macros. Nowadays it probably would be bett
On 31/07/2024 08:52, Thomas Munro wrote:
On Tue, Jul 30, 2024 at 9:50 AM Thomas Munro wrote:
I guess we should also consider reimplementing the spinlock on the
atomic API, but I can see that Andres is poking at spinlock code right
now so I'll keep out of his way...
Here is a first attempt at
On Tue, Jul 30, 2024 at 9:50 AM Thomas Munro wrote:
> I guess we should also consider reimplementing the spinlock on the
> atomic API, but I can see that Andres is poking at spinlock code right
> now so I'll keep out of his way...
Here is a first attempt at that. I haven't compared the generated
On Tue, Jul 30, 2024 at 12:39 PM Thomas Munro wrote:
> On Tue, Jul 30, 2024 at 11:16 AM Heikki Linnakangas wrote:
> > Looks good to me.
>
> Thanks. I'll wait just a bit longer to see if anyone else has comments.
And pushed.
I am aware of a couple of build farm animals that will now fail
becaus
On Tue, Jul 30, 2024 at 11:16 AM Heikki Linnakangas wrote:
> On 30/07/2024 00:50, Thomas Munro wrote:
> > On Wed, Jul 3, 2024 at 8:09 PM Tom Lane wrote:
> >> Thomas Munro writes:
> > OK, part on ice for now. Here's an update of the rest,
> > this time also removing the barrier fallbacks as dis
On 30/07/2024 00:50, Thomas Munro wrote:
On Wed, Jul 3, 2024 at 8:09 PM Tom Lane wrote:
Thomas Munro writes:
Here are some experimental patches to try out some ideas mentioned
upthread, that are approximately unlocked by that cleanup.
FWIW, I'm good with getting rid of --disable-spinlocks a
On Wed, Jul 3, 2024 at 8:09 PM Tom Lane wrote:
> Thomas Munro writes:
> > Here are some experimental patches to try out some ideas mentioned
> > upthread, that are approximately unlocked by that cleanup.
>
> FWIW, I'm good with getting rid of --disable-spinlocks and
> --disable-atomics. That's a
Thomas Munro writes:
> Here are some experimental patches to try out some ideas mentioned
> upthread, that are approximately unlocked by that cleanup.
FWIW, I'm good with getting rid of --disable-spinlocks and
--disable-atomics. That's a fair amount of code and needing to
support it causes probl
On Tue, Jul 2, 2024 at 5:56 AM Tom Lane wrote:
> Done at commit edadeb0710.
Here are some experimental patches to try out some ideas mentioned
upthread, that are approximately unlocked by that cleanup.
1. We could get rid of --disable-spinlocks. It is hard to imagine a
hypothetical new port th
Noah Misch writes:
> On Sat, Oct 21, 2023 at 02:18:19AM -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> IMO a single person looking at HPPA code for a few minutes is a cost that
>>> more
>>> than outweighs the potential benefits of continuing "supporting" this dead
>>> arch. Even code that d
On Sat, Oct 21, 2023 at 02:18:19AM -0400, Tom Lane wrote:
> Andres Freund writes:
> > It'd be one thing to continue supporting an almost-guaranteed-to-be-unused
> > platform, if we expected it to become more popular or complete enough to be
> > usable like e.g. risc-v a few years ago. But I doubt
Andres Freund writes:
> On October 20, 2023 11:18:19 PM PDT, Tom Lane wrote:
>> Indeed. I would have bet that Postgres on HPPA was extinct in the wild,
>> until I noticed this message a few days ago:
>> https://www.postgresql.org/message-id/BYAPR02MB42624ED41C15BFA82DAE2C359BD5A%40BYAPR02MB4262.
Hi,
On October 20, 2023 11:18:19 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> It'd be one thing to continue supporting an almost-guaranteed-to-be-unused
>> platform, if we expected it to become more popular or complete enough to be
>> usable like e.g. risc-v a few years ago. But I doubt we
Andres Freund writes:
> It'd be one thing to continue supporting an almost-guaranteed-to-be-unused
> platform, if we expected it to become more popular or complete enough to be
> usable like e.g. risc-v a few years ago. But I doubt we'll find anybody out
> there believing that there's a potential
Hi,
On 2023-10-20 22:06:55 -0400, Tom Lane wrote:
> Noah Misch writes:
> > If the next thing is a patch removing half of the fallback atomics, that is
> > a
> > solid reason to remove hppa.
>
> Agreed, though I don't think we have a clear proposal as to what
> else to remove.
>
> > The code re
Noah Misch writes:
> If the next thing is a patch removing half of the fallback atomics, that is a
> solid reason to remove hppa.
Agreed, though I don't think we have a clear proposal as to what
else to remove.
> The code removed in the last proposed patch was
> not that and was code that never
On Fri, Oct 20, 2023 at 12:40:00PM -0700, Andres Freund wrote:
> On 2023-10-19 17:23:04 -0700, Noah Misch wrote:
> > On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:
> > > We removed support for the HP-UX OS in v16, but left in support
> > > for the PA-RISC architecture, mainly because I t
Hi,
On 2023-10-20 17:46:59 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-10-20 15:59:42 -0400, Tom Lane wrote:
> >> Hmm, are you saying there's more of port/atomics/ that could be
> >> removed? What exactly?
>
> > I was thinking we could remove the whole fallback path for atomic
>
Andres Freund writes:
> On 2023-10-20 15:59:42 -0400, Tom Lane wrote:
>> Hmm, are you saying there's more of port/atomics/ that could be
>> removed? What exactly?
> I was thinking we could remove the whole fallback path for atomic operations,
> but it's a bit less, because we likely don't want t
Hi,
On 2023-10-20 15:59:42 -0400, Tom Lane wrote:
> Andres Freund writes:
> > In addition to the point Tom has made, I think it's also not correct that
> > hppa
> > doesn't impose a burden: hppa is the only of our architectures that doesn't
> > actually support atomic operations, requiring us to
Andres Freund writes:
> In addition to the point Tom has made, I think it's also not correct that hppa
> doesn't impose a burden: hppa is the only of our architectures that doesn't
> actually support atomic operations, requiring us to have infrastructure to
> backfill atomics using spinlocks. This
Hi,
On 2023-10-19 17:23:04 -0700, Noah Misch wrote:
> On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:
> > We removed support for the HP-UX OS in v16, but left in support
> > for the PA-RISC architecture, mainly because I thought that its
> > spinlock mechanism is weird enough to be a goo
I wrote:
> Noah Misch writes:
>> On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:
>>> Hence, the attached removes the remaining support for HPPA.
>> I wouldn't do this. NetBSD/hppa still claims to exist, as does the OpenBSD
>> equivalent. I presume its pkgsrc compiles this code. The c
On Fri, Oct 20, 2023 at 4:21 AM Tom Lane wrote:
> We removed support for the HP-UX OS in v16, but left in support
> for the PA-RISC architecture, mainly because I thought that its
> spinlock mechanism is weird enough to be a good stress test
> for our spinlock infrastructure. It still is that, bu
Noah Misch writes:
> On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:
>> Hence, the attached removes the remaining support for HPPA.
> I wouldn't do this. NetBSD/hppa still claims to exist, as does the OpenBSD
> equivalent. I presume its pkgsrc compiles this code. The code is basicall
On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:
> We removed support for the HP-UX OS in v16, but left in support
> for the PA-RISC architecture, mainly because I thought that its
> spinlock mechanism is weird enough to be a good stress test
> for our spinlock infrastructure. It still is
Michael Paquier writes:
> On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:
>> Hence, the attached removes the remaining support for HPPA.
>> Any objections?
> Would a refresh of config/config.guess and config/config.sub be
> suited? This stuff still has references to HPPA.
AFAIK we jus
On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:
> We removed support for the HP-UX OS in v16, but left in support
> for the PA-RISC architecture, mainly because I thought that its
> spinlock mechanism is weird enough to be a good stress test
> for our spinlock infrastructure. It still is
35 matches
Mail list logo
