From: | "Richard W(dot)M(dot) Jones" <rjones(at)redhat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: PostgreSQL cannot be compiled on RISC-V |
Date: | 2016-11-20 18:49:42 |
Message-ID: | 20161120184942.GP11243@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2016-11-20 18:56:41 | Re: PostgreSQL cannot be compiled on RISC-V |
Previous Message | Tom Lane | 2016-11-20 18:02:51 | Re: PostgreSQL cannot be compiled on RISC-V |