Re: PostgreSQL cannot be compiled on RISC-V
От | Richard W.M. Jones |
---|---|
Тема | Re: PostgreSQL cannot be compiled on RISC-V |
Дата | |
Msg-id | 20161120184942.GP11243@redhat.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL cannot be compiled on RISC-V (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PostgreSQL cannot be compiled on RISC-V
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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
В списке pgsql-bugs по дате отправления: