"Richard W.M. Jones" <rjones@redhat.com> writes:
> I'm happy with the patch I previously attached, and I don't think it
> would be controversial to apply it to upstream PostgreSQL now, along
> with updating config.guess/config.sub. I didn't test spinlocks, but
> if there was a bug in the GCC builtin, then we would fix it in GCC.
> (In fact, why not use the GCC builtin every time PostgreSQL is
> compiled with GCC?)
Well, to be blunt, our experience with the GCC builtins has not been
good. The quality of implementation seems to vary drastically across
architectures, with, e.g., some word widths not working or having
very poor performance compared to others. So while we will take an
s_lock implementation based on GCC builtins, we view it as needing
to be validated for the given architecture just as much as any other
method would be. For platforms where we have already-debugged assembly
code, there's no visible upside in switching to the builtins, either.
> For the sake of full disclosure, the test suite is rather "crashy",
> with about half of the tests failing. Basic database creation,
> creating tables, etc all works, but the detailed tests fail with "test
> process exited with exit code 2" often.
> None of this is surprising as the entire toolchain is pre-alpha.
Yeah, compiler bugs would lead to that sort of thing.
> I found that dialing MAX_CONNECTIONS down to 2 or 3 helps.
Hmm, makes me wonder if the spinlock primitives actually work ...
> What would be helpful is to get more detail on how the tests fail. I
> don't even know if it is the client or server side which fails
> (although I assume the server, because `psql' will exit with code 2 if
> it loses the network connection). Is there some way to run tests with
> lots of extra verbosity?
Not directly, but I'd guess that the server processes are crashing and
leaving core dumps behind (or would be if you run under a suitable
ulimit). Assuming that you've got working core dump support and gdb,
getting stack traces from some of the crashes would be useful info.
Also, if you can't tell from the server logs which core is which,
"p debug_query_string" is a good way to see the current SQL command
that a crashed process was working on.
Given that you seem to be pretty early in this process (ie a long
way from production grade), my feeling is that we should apply RISC-V
related fixes to HEAD only, meaning that they'd reach the field with
Postgres v10 next fall. For your own purposes, you could carry the
fixes as patches against 9.6.x, or work with snapshots of our master
branch.
regards, tom lane