Re: Thomas Munro
> I randomly remembered this topic after seeing an s390x announcement
> from Christoph[1], and figured he or someone else might be interested
> in the same observation about that platform. That is, we finally got
> around to defining this for ARM, but I bet one internet point that
On Wed, Nov 3, 2021 at 11:55 AM Thomas Munro wrote:
> 1. Even though we're using generic built-ins for atomics, I guess we
> could still use a src/include/port/atomics/arch-riscv.h file so we
> have a place to define PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY when
> building for 64 bit. We'd need to fi
On Wed, Nov 3, 2021 at 5:41 PM Thomas Munro wrote:
> 'generic' is not a recognized processor for this target (ignoring processor)
I still don't know what's wrong but I spent 20 minutes searching for
more clues this morning...
First, 'generic' is coming from LLVMGetHostCPUName(), and yet it's not
On Wed, Nov 3, 2021 at 5:13 PM Andres Freund wrote:
> Any chance you could enable jit_dump_bitcode and manually try a failing
> query? That should dump. bc files in the data directory. That'd might allow
> debugging this outside the emulated environment.
>
> I don't see where the undef is origin
Hi,
On November 2, 2021 3:55:58 PM PDT, Thomas Munro wrote:
>2. When configured with all options on FreeBSD 13, everything looks
>good so far except LLVM JIT, which fails with various "Cannot select"
>errors. Clang works fine for compiling PostgreSQL itself. Tested
>with LLVM 12 (LLVM has sup
On Wed, Sep 1, 2021 at 9:22 PM Christoph Berg wrote:
> Re: Tom Lane
> > I did not like confusing the RISC-V case with the ARM case: duplicating
> > the code block seems better, in case there's ever reason to add
> > arch-specific stuff like SPIN_DELAY. So I split it off to its own
> > code block
Re: Tom Lane
> I did not like confusing the RISC-V case with the ARM case: duplicating
> the code block seems better, in case there's ever reason to add
> arch-specific stuff like SPIN_DELAY. So I split it off to its own
> code block and pushed it.
Fwiw I can report success on Debian's riscv port
Daniel Gustafsson writes:
> There didn’t seem to be anything left here (at least until there is hardware
> in
> the buildfarm) so I took the liberty to close it as committed in the CF app.
Ah, sorry, I did not realize there was a CF entry.
regards, tom lane
> On 13 Aug 2021, at 20:09, Tom Lane wrote:
> ..I split it off to its own code block and pushed it.
There didn’t seem to be anything left here (at least until there is hardware in
the buildfarm) so I took the liberty to close it as committed in the CF app.
--
Daniel Gustafsson ht
Andres Freund writes:
> On 2021-08-13 13:37:02 -0400, Tom Lane wrote:
>> so it seems like someday we might want to expend some effort on native
>> atomics. I agree that that day need not be today, though. This patch
>> seems sufficient until we get to the point of (at least) having some
>> RISC-
Hi,
On 2021-08-13 13:37:02 -0400, Tom Lane wrote:
> "Andres Freund" writes:
> > On Fri, Aug 13, 2021, at 19:25, Tom Lane wrote:
> >> I now have looked at the patch, and it seems good as far as it goes,
> >> but I wonder whether some effort ought to be expended in
> >> src/include/port/atomics/.
>
"Andres Freund" writes:
> On Fri, Aug 13, 2021, at 19:25, Tom Lane wrote:
>> I now have looked at the patch, and it seems good as far as it goes,
>> but I wonder whether some effort ought to be expended in
>> src/include/port/atomics/.
> That should automatically pick up the intrinsic. I think we
Hi,
On Fri, Aug 13, 2021, at 19:25, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> Should we backpatch this? It's not like we're going to break existing
> >> risc-v systems by enabling spinlock support...
>
> > Yeah, why not? If you were building with --disable-spinlocks before,
> >
I wrote:
> Andres Freund writes:
>> Should we backpatch this? It's not like we're going to break existing
>> risc-v systems by enabling spinlock support...
> Yeah, why not? If you were building with --disable-spinlocks before,
> this shouldn't change anything for you.
> (I haven't actually looke
Andres Freund writes:
> On 2021-08-13 11:09:04 -0400, Tom Lane wrote:
>> Marek Szuba writes:
>>> Tested against PostgreSQL 13.3 on a physical rv64gc system (BeagleV
>>> Starlight beta board) - builds and installs fine, all tests pass.
> Should we backpatch this? It's not like we're going to brea
Hi,
On 2021-08-13 11:09:04 -0400, Tom Lane wrote:
> Marek Szuba writes:
> > Tested against PostgreSQL 13.3 on a physical rv64gc system (BeagleV
> > Starlight beta board) - builds and installs fine, all tests pass.
Seems like a good idea to me.
> Cool ... I had hoped to acquire one of those myse
Marek Szuba writes:
> Tested against PostgreSQL 13.3 on a physical rv64gc system (BeagleV
> Starlight beta board) - builds and installs fine, all tests pass.
Cool ... I had hoped to acquire one of those myself, but I didn't
make the cut.
regards, tom lane
Hello,
The attached patch adds native spinlock support to PostgreSQL on RISC-V
systems. As suspected by Richard W.M. Jones of Red Hat back in 2016, the
__sync_lock_test_and_set() approach applied on arm and arm64 works here
as well.
Tested against PostgreSQL 13.3 on a physical rv64gc system
18 matches
Mail list logo
