Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

On 2024-04-05 03:37, Michael Paquier wrote: (Adding Mikael Kjellstrom in CC as OpenBSD owner) My 2 OpenBSD animals (morepork OpenBSD 6.9, schnauzer

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

On 2023-07-03 20:53, Daniel Gustafsson wrote: curculio (OpenBSD 5.9) is failing with "undefined reference to `X509_get_signature_nid'", but that's OK, Mikael already supplied a modern OpenBSD system to replace it Thanks for the report! OpenBSD 5.9 was released in 2016 and is thus well

Re: Direct I/O

On 2023-04-16 20:05, Mikael Kjellström wrote: Oh wait ... this involves a switch from gcc in OpenBSD 5.9 to clang in OpenBSD 7.3, doesn't it?  That isn't something update_personality will handle; you need a new animal if the compiler product is changing. Correct. OK. I registered a new

Re: Direct I/O

On 2023-04-16 19:59, Andrew Dunstan wrote: On Apr 16, 2023, at 12:16 PM, Tom Lane wrote: Andrew Dunstan writes: On 2023-04-16 Su 10:18, Tom Lane wrote: Actually, as long as it's still OpenBSD I think you can keep using the same animal name ... Andrew, what's the policy on that?

Re: Direct I/O

On 2023-04-16 16:18, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: On 2023-04-16 00:10, Tom Lane wrote: so curculio should be the only one that's at risk here. Maybe just upgrading it is the right answer. Just let me know if I should switch curculio to OpenBSD 7.3. Yes

Re: Direct I/O

On 2023-04-16 00:10, Tom Lane wrote: so curculio should be the only one that's at risk here. Maybe just upgrading it is the right answer. Just let me know if I should switch curculio to OpenBSD 7.3. I already have a new server setup so only need to switch the "animal" and "secret" and

Re: Direct I/O

On 2023-04-14 21:33, Andres Freund wrote: Oh! I was misled by the buildfarm label on morepork, which claims it's running clang 10.0.1. But actually, per its configure report, it's running configure: using compiler=gcc (GCC) 4.2.1 20070719 Huh. I wonder if that was an accident in

Re: Direct I/O

On 2023-04-15 05:22, Tom Lane wrote: Thomas Munro writes: On Sat, Apr 15, 2023 at 7:50 AM Mikael Kjellström wrote: want me to switch to clang instead? I vote +1, that's the system compiler in modern OpenBSD. Ditto, we need coverage of that. OK. I switched to clang on morepork now

Re: Making background psql nicer to use in tap tests

On 2023-04-08 09:53, Daniel Gustafsson wrote: I recommend just setting up this one test to SKIP if IPC::Run is too old. Yes, will do that when I have a little more time at hand for monitoring the BF later today. So what do you want me to do about grison and morepork? I guess I could try

Re: conchuela doesn't like gnu_printf anymore

On 2022-08-06 18:59, Tom Lane wrote: This is seemingly an intentional configuration change, because the animal is reporting different config_env than before. However, we decide what to set PG_PRINTF_ATTRIBUTE to based on what CC likes, and if CXX doesn't like it then you'll get these

Re: recovery test failure on morepork with timestamp mystery

On 2022-05-13 22:09, Andres Freund wrote: What does sysctl kern.timecounter return? Does the problem continue if you switch kern.timecounter.hardware to something else? openbsd 5.9: $ sysctl kern.timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0

Re: recovery test failure on morepork with timestamp mystery

On 2022-05-13 04:14, Andres Freund wrote: One interesting tidbit is that the log timestamps are computed differently (with elog.c:get_formatted_log_time()) than the reset timestamp (with GetCurrentTimestamp()). Both use gettimeofday() internally. I wonder if there's a chance that somehow

Re: Time to drop plpython2?

On 2022-02-17 19:08, Andres Freund wrote: I've pinged the owners of the animals failing so far: Now also pinged: - curculio Should be fixed by now. I did install the python3-package but the binary was called: /usr/local/bin/python3.5 for some reason so configure didn't pick it up.

Re: conchuela has some SSL issues

On 2021-12-14 15:05, Mikael Kjellström wrote: I will take a look at it. At the moment I have disabled new builds until I have fixed it. Sorry for the inconvenience. Should be fixed now. /Mikael

Re: conchuela has some SSL issues

On 2021-12-13 20:53, Andrew Dunstan wrote: Any thoughts? It's also failing on REL_14_STABLE, so I think it must be an environmental change. I did an pkg update && pkg upgrade and it messed up the SSL-libraries. It had both libressl and openssl and when I upgraded it some how removed

Re: Mixing CC and a different CLANG seems like a bad idea

On 2021-11-18 17:56, Tom Lane wrote: I noticed that, a week after Michael pushed 9ff47ea41 to silence -Wcompound-token-split-by-macro warnings, buildfarm member sidewinder is still spewing them. Investigation shows that it's building with configure: using compiler=cc (nb4 20200810) 7.5.0

Re: Weird failure in explain.out with OpenBSD

On 2021-11-11 02:15, Thomas Munro wrote: I dunno. Clocks on virtualised systems and even metal seem to be a minefield of quirks and heuristics. Some discussion, may or may not be relevant: https://marc.info/?l=openbsd-tech=161657532610882=2 Just for fun I compiled and ran the test program

Re: Weird failure in explain.out with OpenBSD

On 2021-11-11 04:35, Andres Freund wrote: One quite conceivable way could be a VM migration. Which quite a few hosters can do behind ones back, to reduce downtimes in case of hardware maintenance etc. If openbsd is using the TSC, and something in the stack isn't quite dealing correctly with

Re: Weird failure in explain.out with OpenBSD

On 2021-11-11 02:15, Thomas Munro wrote: On Thu, Nov 11, 2021 at 1:15 PM Michael Paquier wrote: morepork uses 6.9 now, but it has been recently upgraded from 5.4 or a version close to that, right? I am wondering if 7.0 may help regarding this issue. Postgres is not wrong here. I dunno.

Re: Weird failure in explain.out with OpenBSD

On 2021-11-11 01:15, Michael Paquier wrote: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=morepork=2021-11-10%2020%3A51%3A32 Yeah, I have noticed this failure yesterday. morepork uses 6.9 now, but it has been recently upgraded from 5.4 or a version close to that, right? I am

Re: Time to upgrade buildfarm coverage for some EOL'd OSes?

On 2021-10-11 10:20, Magnus Hagander wrote: It was indeed supposed to, but didn't. It has now been done though, so git.postgresql.org should now be compatible with ancient OpenSSL. And curculio is back to life and shows as all green on the status page. So it's

Re: Time to upgrade buildfarm coverage for some EOL'd OSes?

On 2021-10-10 20:00, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: curculio: Is not able to connect to https://git.postgresql.org due to the Let's Encrypt expired CA. We're working on fixing things so that git.postgresql.org will advertise a cert chain that is compatible with

Re: Time to upgrade buildfarm coverage for some EOL'd OSes?

On 2021-10-08 21:40, Thomas Munro wrote: Sure I can keep curculio as is. Will just upgrade morepork to OpenBSD 6.9 then. Thanks very much for doing all these upgrades! No problem. Current status is: loach: Upgraded to FreeBSD 12.2 morepork: Upgraded to OpenBSD 6.9 conchuela: Upgraded

Re: Time to upgrade buildfarm coverage for some EOL'd OSes?

On 2021-10-08 18:12, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: Yes, it's getting long in the tooth. I will upgrade the NetBSD 7 (sidewinder) to 9.2. And I will also upgrade loach to 12.x if that's the version that is needed the most. I will upgrade conchuela to DragonFlyBSD

Re: Time to upgrade buildfarm coverage for some EOL'd OSes?

On 2021-10-08 00:15, Thomas Munro wrote: I noticed that for NetBSD we only have one animal, and it's running EOL'd release 7. To give decent visibility of relevant portability problems it'd be nice to have one of the current supported releases[1] in there. CC'ing owner; any interest in

Re: Race condition in recovery?

On 2021-06-10 01:09, Tom Lane wrote: Robert Haas writes: Got it. I have now committed the patch to all branches, after adapting your changes just a little bit. Thanks to you and Kyotaro-san for all the time spent on this. What a slog! conchuela failed its first encounter with this test

Re: backup manifests and contemporaneous buildfarm failures

On 2020-04-04 04:43, Robert Haas wrote: I think I've done about as much as I can do for tonight, though. Most things are green now, and the ones that aren't are failing because of stuff that is at least plausibly fixed. By morning it should be clearer how much broken stuff is left, although

Re: sidewinder has one failure

On 2020-01-04 01:21, Mikael Kjellström wrote: Apparently, in the environment of that TAP test, the server has more open FDs at this point than it does when running "normally".  I have no idea what the additional FDs might be. Well it's running under cron if that makes a differenc

Re: sidewinder has one failure

On 2020-01-04 01:15, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: I think Tom Lane found the "problem". It has to do with the semaphores taking up FD's. Hm, no, because: Yes, saw that after I posted my answer. Sure. I compiled pgsql 12 and this is the complete logfile

Re: sidewinder has one failure

On 2020-01-03 15:48, Amit Kapila wrote: On Fri, Jan 3, 2020 at 7:03 PM Amit Kapila wrote: I debugged on HEAD and found that we are closing all the files (like postgresql.conf, postgresql.auto.conf, etc.) that got opened before set_max_safe_fds. I think on HEAD the 3 already opened files are

Re: sidewinder has one failure

On 2020-01-03 13:01, Amit Kapila wrote: 2020-01-02 19:51:05.687 CET [24138:3] FATAL: insufficient file descriptors available to start server process 2020-01-02 19:51:05.687 CET [24138:4] DETAIL: System allows 19, we need at least 20. 2020-01-02 19:51:05.687 CET [24138:5] LOG: database

Re: scorpionfly needs more semaphores

On 2019-09-23 00:29, Thomas Munro wrote: On Wed, Sep 18, 2019 at 4:55 PM jungle boogie wrote: $ sysctl | ag kern.seminfo.semmni kern.seminfo.semmni=100 It still seems to be happening. Perhaps you need to increase semmns too? I have on my OpenBSD 6.5 /etc/sysctl.conf the following:

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-18 00:31, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: And now also the NetBSD machine failed on pgbenchCheck. Indeed, as expected. Ok. should I leave it as it is for now? Please. I'll push a fix for the broken test case in a bit --- I just wanted to

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-18 00:00, Mikael Kjellström wrote: I just started another run on sidewinder (NetBSD 7), let's see how that goes. but the OpenBSD machine went further and now fails on: pgbenchCheck instead. Is that the failure you expected to get? And now also the NetBSD machine failed

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 23:54, Mikael Kjellström wrote: But it looks like in NetBSD the options are called: netbsd7-pgbf# sysctl -a | grep semmn kern.ipc.semmni = 10 kern.ipc.semmns = 60 kern.ipc.semmnu = 30 so I will try and set that in /etc/sysctl.conf and reboot and see what happens

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 23:37, Mikael Kjellström wrote: On 2019-01-17 23:23, Tom Lane wrote: Yeah, you might've been able to get by with OpenBSD/NetBSD's default semaphore settings before, but they really only let one postmaster run at a time; and the TAP tests want to start more than one. For me

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 23:23, Tom Lane wrote: Yeah, you might've been able to get by with OpenBSD/NetBSD's default semaphore settings before, but they really only let one postmaster run at a time; and the TAP tests want to start more than one. For me it seems to work to append this to

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 22:47, Mikael Kjellström wrote: On 2019-01-17 22:42, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: It says: configure: error: Additional Perl modules are required to run TAP tests so how do I find out with Perl modules that are required? If you look

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 22:42, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: It says: configure: error: Additional Perl modules are required to run TAP tests so how do I find out with Perl modules that are required? If you look into the configure log it should say just above that, but

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 22:19, Mikael Kjellström wrote: On 2019-01-17 22:16, Tom Lane wrote: For what it's worth I've enabled tap-tests for my OpenBSD 5.9 (curculio) and NetBSD 7 (sidewinder) animals now. Oh, thanks!  I'm guessing they'll fail their next runs, but I'll wait to see confirmation

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 22:16, Tom Lane wrote: For what it's worth I've enabled tap-tests for my OpenBSD 5.9 (curculio) and NetBSD 7 (sidewinder) animals now. Oh, thanks! I'm guessing they'll fail their next runs, but I'll wait to see confirmation of that before I do anything about the test bug.

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 06:04, Tom Lane wrote: Although we've got a few NetBSD and OpenBSD buildfarm critters, none of them are doing --enable-tap-tests. If they were, we'd have noticed the pgbench regression tests falling over: For what it's worth I've enabled tap-tests for my OpenBSD 5.9 (curculio)

Re: OpenBSD versus semaphores

On 2019-01-08 07:14, Tom Lane wrote: I've been toying with OpenBSD lately, and soon noticed a seriously annoying problem for running Postgres on it: by default, its limits for SysV semaphores are only SEMMNS=60, SEMMNI=10. Not only does that greatly constrain the number of connections for a

Re: NetBSD vs libxml2

On 2018-08-12 01:32, Andrew Dunstan wrote: OpenBSD-6.3's "xml2-config --libs" doesn't contain any rpath settings, it's pretty much like the one on my (fairly old) FBSD machine, as you describ4ed above. Just FYI! My bf-animal curculio that runs OpenBSD 5.9 shows the following: $ xml2-config

Re: != should give error?

On 2017-12-21 08:16, Craig Ringer wrote: postgres=# create table tbl (col_a int, col_b int); CREATE TABLE postgres=# insert into tbl values (1,2); INSERT 0 1 postgres=# insert into tbl values (2,1); INSERT 0 1 *postgres=# select * from tbl where col_a ! = 1;