Re: pgsql + qnx

Oids are 32 bits, 'unsigned int' to be precise. Support for 64 bit
integers is completely optional in PostgreSQL.
http://www.ca.postgresql.org/mhonarc/pgsql-ports/
I keep seeing these. If anyone got a clue, let us know.

F_BOOLIN should be supplied from fmgroids.h, which is built on-the-fly
by backend/utils/Gen_fmgrtab.sh. Probably what we have here is (a)
platform dependent failure of that script ('cat' not installed, or
some such), and (b) insufficient error checking in the script, so
it doesn't realize it's failed to build the file.

regards, tom lane

I just checked Gen_fmgrtab.sh and it has error checking all over the
place. I would be curious to know how it could fail and not exit with
non-zero.

The Watcom preprocessor adds a space at the start of each line. Therefore
the output of "egrep '^[0-9]' " is empty. Changing the pattern to
"egrep '^[ ]*[0-9]" generates the correct file.

Makes sense and seems safe enough. Applied.

I was under the impression that OIDs and SEQUENCEs are required to be 64 bit
and 32 bit versions are not really supported. I may have a look at using the
Watcom compiler again.

Thanks, I started at http://www.postgresql.org/search.mpl or
http://www.ca.postgresql.org/devel-corner/index.html and couldn't
find a path to the archive.


Maybe Kamil can tell us more.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it withing the next 48 hours.

[ Attachment, skipping... ]

[ Attachment, skipping... ]

I've just performed a build of a Watcom compiled version and found a couple
of bugs in the watcom specific part of that patch. Please use the attached
version instead.
The watcom version fails 3 additional regression tests, at least one (int8)
expected; I have not looked at the other ones.

Got it.

[ Attachment, skipping... ]

I don't like the Makefile.qnx4 and plpgsql/Makefile parts of this patch:

! override CXXFLAGS +=-I/usr/local/include/g++
! override CFLAGS +=-I/usr/local/include

The first line looks like a broken compiler installation. The second line
should, if at all, go into the template file. But I don't like us using
arbitrary include paths. If the compiler vendor decides to not go there
by default they had a reason. In any case there would be an equivalent
LDFLAGS setting missing. Also, -I options should go into CPPFLAGS.

The plpgsql issue should be fixed by making the ifneq
($(enable_shared),yes) sections in plpgsql/src/Makefile cover the parts
you don't want to execute. That's what it is for, it just hasn't been
exercised yet.

Could you elaborate ? I am not sure which template file you refer to.
In case you are thinking of the gcc installation, I guess they could be
scrapped. However, Watcom does not search these directories by default.
In fact, IIRC a OOB QNX4 install does not even *have* a '/usr/local'. I
have included this because TCL and zlib install their headers there.

Not really, it's because building the static library kills wlib. It is
a platform specific problem similar to the hack in backend/Makefile.
Of course I could make this dependant on enable_shared, but I don't like
using two different flags to work around the same bug.

Only if you tell them to install them there. Which is probably a
reasonable thing to do, but since /usr/local is not considered an integral
part of the system we shouldn't force it upon the user. It's just a
matter of keeping things clean.
I see. But the static lib is kind of useless in this case, so we could
turn it all off and get rid of the wlib problem at the same time?

Yes, I agree. That looks like a better place.

Well, if there is no /usr/local the flag will be silently ignored. If
someone really wants to install perl, tcl and zlib in non standard
locations he'll have to fiddle with the setup anyway. I wanted to provide
reasonable defaults that work with the rest of the binary packages mentioned
in the FAQ.
The correct way imho would be to let configure figure it out, but have I
have no idea how to implement that.

That is exactly what I wanted to achieve. There is no reason to even compile
the plpgsql sources at the moment on QNX4. I suppose I could move the hack
into the plpgsql Makefile but that is somewhat tricky because the all-lib
target for building the static lib is in $src/Makefile.shlib:

*** postgresql-7.1.1/src/pl/plpgsql/src/Makefile Fri Apr 6 16:36:36 2001
--- postgresql-7.1.1.qnx4/src/pl/plpgsql/src/Makefile Wed May 23 11:13:50 2001
***************
*** 21,32 ****

OBJS = pl_parse.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o

all: all-lib

# Shared library stuff
include $(top_srcdir)/src/Makefile.shlib
!
!
# In order to use Makefile.shlib, we allow it to build a static
# library libplpgsql.a, which we just ignore, as well as a shared
# library that it will insist on naming $(shlib). We don't want to
--- 21,37 ----

OBJS = pl_parse.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o

+ ifeq ($(PORTNAME), qnx4)
all: all-lib

# Shared library stuff
include $(top_srcdir)/src/Makefile.shlib
! else
! all:
! @echo "*****"; \
! echo "* PL/pgSQL was not built due to library manager problems."; \
! echo "*****"
! endif
# In order to use Makefile.shlib, we allow it to build a static
# library libplpgsql.a, which we just ignore, as well as a shared
# library that it will insist on naming $(shlib). We don't want to

*** postgresql-7.1.1/src/template/qnx4 Tue Oct 31 19:16:20 2000
--- postgresql-7.1.1.qnx4/src/template/qnx4 Wed May 23 11:30:55 2001
***************
*** 1,2 ****
! CFLAGS=
LIBS=-lunix
--- 1,2 ----
! CFLAGS=-I/usr/local/include
LIBS=-lunix

Hello,
I'm porting posgresql for QNX RTP. Compiling is ok, but
"/usr/local/pqsql/bin/initdb -D data" command say:

FATAL: s_lock(0x081e6029) at spin.c:162, stuck spinlock. Aborting.

FATAL: s_lock(0x081e6029) at spin.c:162, stuck spinlock. Aborting.
sed: couldn't write 86 items to {standard output}: Broken pipe
Abort (core dumped)

initdb failed.
Data directory dat will not be removed at user's reques



I review sem_'s family functions and use de QNX sem function, except
S_LOCK_FREE:

It is in src/include/storing/s_lock.h
#define S_LOCK_FREE(lock) s_lock_free_x86(lock)
#define TAS(lock) (sem_trywait((lock)) < 0)
#define S_UNLOCK(lock) sem_post((lock))
#define S_INIT_LOCK(lock) sem_init((lock), 1, 1)

It is in src/backend/port/x86/sem.c and make for my
int
s_lock_free_x86(sem_t *lock) {
int value;
sem_getvalue(lock, &value);
return value;
};

The testing program "s_lock_test" (is inside in s_lock.c) working properly.

Any idea. Sorry for my english.

Thanks,

Leandro Medina
(Ingdesi Group - R&D)

Hm. The existing QNX spinlock functions do work for some people.
Is the slock_t datatype declared correctly for your platform in the
port header file?

regards, tom lane

Just to throw in my $0.02 :

- from the source snippet it looks like it is using semaphores for
spinlocks. This is one of the quirks that my patch corrected. See
http://www.ca.postgresql.org/mhonarc/pgsql-ports/2001-05/msg00069.html
and
http://www.ca.postgresql.org/mhonarc/pgsql-ports/2001-05/msg00078.html
Without it 7.1 failed with a similar problem on QNX4.

- RTP is probably more different from QNX4 than Solaris 2 from SunOS 4,
so code that works on QNX4 may fail on RTP. It is much closer to
modern unices and supports shared libraries, elf executables, etc. .
AFAIK no SysV IPC interface, though. The RTP version could be much
more fully featured that the QNX4 version.

- QNX (both versions) is a RTOS. If you were to use RR or FIFO
scheduling, spinlocks probably won't work.

Hi Bernd,
I find the solution for one problem, but others appear. Why spinlock
doesn't works with FIFO or RR scheduling?

Thanks,

Leandro Medina
(Ingdesi Group - R&D)

----- Original Message -----
From: "Tegge, Bernd" <tegge@repas-aeg.de>
To: "Tom Lane" <tgl@sss.pgh.pa.us>; "Leandro Medina" <lmedina@ingdesi.com>
Cc: <pgsql-ports@postgresql.org>
Sent: Monday, May 28, 2001 6:37 AM
Subject: Re: [PORTS] lock in qnx rtp.

Sorry, I had a different implementation in mind, where spinlocks did not
sleep during the wait. Postgres spinlocks should be fine for RR and FIFO
scheduling.

<snip>

This was the one actually applied.

[ Attachment, skipping... ]

Patch applied, but newer version. Thanks.

[ Attachment, skipping... ]

[ Attachment, skipping... ]