Re: PostgreSQL cannot be compiled on RISC-V - Mailing list pgsql-bugs

On Sun, Nov 20, 2016 at 01:02:51PM -0500, Tom Lane wrote:
> > I found that dialing MAX_CONNECTIONS down to 2 or 3 helps.
>
> Hmm, makes me wonder if the spinlock primitives actually work ...

Yes, my thought too.

With MAX_CONNECTIONS=1 only 5 tests fail, and reliably too:

     opr_sanity               ... FAILED
test errors                   ... FAILED
     psql_crosstab            ... FAILED
     select_views             ... FAILED
     largeobject              ... FAILED (test process exited with exit code 2)

========================
 5 of 168 tests failed.
========================

> > 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).

I checked this already and I don't think the server process is
crashing, or if it is then it's not leaving coredumps around even
though /proc/sys/kernel/core_pattern and the 'ulimit -c unlimited'
ought to allow them.  Maybe the tests or server process is adjusting
ulimit?

> Assuming that you've got working core dump support and gdb,
> getting stack traces from some of the crashes would be useful info.

Agreed.  Unfortunately there's no gdb yet, and as above no core dumps
in any case.

> 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.

OK I will keep that in mind if we get gdb working.

> 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.

Yes no problems at all.

I really wouldn't want anyone to entrust precious data to PostgreSQL
on RISC-V at this point, so long schedules are fine :-/

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW