Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. If we were to go with Greg's suggestion of inventing a separate
is_relative_to_cwd test function, I'd expect that to insist on no ..
while it was at it.
So it's now two problems, and I think this is my final comment:
1. is_relative_to_cwd() I
Greg Stark gsst...@mit.edu wrote:
/* NOTE: these two functions aren't complementary under windows,
* be sure to use the right one */
/* Check path always means the same thing regardless of cwd */
is_absolute_path()
/* Check that path is under cwd */
is_relative_path()
Um ... isn't that
Bruce Momjian br...@momjian.us wrote:
is_relative_to_cwd()?
../../../../some/other/place/not/under/cwd
Names are hard, but if I understood the original post, the
revised function is intended to check that the directory is
below the current working directory.
If my understanding is wrong
Abhijit Menon-Sen a...@toroid.org wrote:
Unless you explicitly declare and fetch from an SQL-level cursor, your
many GBs of data are going to be transmitted to libpq, which will eat
lots of memory. (The wire protocol does have something like cursors,
but libpq does not use them, it retrieves
Tom Lane t...@sss.pgh.pa.us wrote:
I suppose that at least some of the *BSD herd really do predefine some
of the symbols being attributed to them here, but I would like to see
something authoritative about which and what.
Documentation follows, but first the summary:
FreeBSD: __FreeBSD__
Hitoshi Harada umi.tan...@gmail.com wrote:
Just note, I rebooted the guest VM today and retried but things are as
before. The host reboot doesn't affect either.
Bad luck. :-(
I also tried another CentOS5.4 VM on the same VirtualBox and succeeded
to build. Another RHEL Server 5.2 (Tikanga)
Josh Berkus j...@agliodbs.com wrote:
Could this be an issue with VirtualBox? Have you used this VM for
testing before?
As I've hit a few bugs in VirtualBox, this is a definite
possibility. (So is Tom's suggestion of inconsistent
sources.)
Because I could, I just installed a new CentOS 5.4
Tom Lane wrote:
On HPUX 10.20, flock doesn't seem to exist (hasn't got a man page nor
any mention in /usr/include).
Correct. Still isn't there in later releases.
lockf says
All locks for a process are released upon
the first close of the file, even if the process still has
Curt Sampson [EMAIL PROTECTED] wrote:
On Sun, 2 Feb 2003, Tom Lane wrote:
This all doesn't look good for using file locks in the way I had in
mind :-( ... but considering that all these man pages seem pretty vague,
maybe some direct experimentation is called for.
Definitely. I wonder
Curt Sampson [EMAIL PROTECTED] wrote:
At any rate, it seems to me highly unlikely that, since the child has
the *same* descriptor as the parent had, that the lock would
disappear.
It depends on the lock function. After fork():
o with flock() the lock continues to be held, but will be
This could be cleaned up rather dramatically if we were to use one of
the file locking primitives supplied by the OS to grab an exclusive
lock on the file, ...
...
The first question for the group is: is it worth doing that?
In the past it has been proposed and declined -- there is some
Tom Lane writes:
Right. Portably was the key word in my comment (sorry for not
emphasizing this more clearly). The real problem here is how to know
what is the actual behavior of each platform? I'm certainly not
prepared to trust reading-between-the-lines-of-some-man-pages. And I
can't
Tom Lane wrote:
Any other arguments out there?
Per-release tags make it easier to see quickly if some code has
changed in -current or not. As the CVS tree is available via anoymous
CVS (I think?), CVSup, and via the web so there are many potential
users who are not active developers and who
I wrote:
o so far I've only tested with the HP ANSI C compiler on 11.11, not
with gcc or on other HP-UX releases.
I can test other releases and probably with gcc, but if someone gets
to it before me that would be just fine. I probably won't until the
new year.
Today is quiet so
Hi all,
I'm planning an upgrade from 7.2.3 to 7.3.1 on some HP-UX systems.
With the major number bump in 7.3.1 I was expecting to be able to do
this upgrade without a flag day to re-compile clients, however due to
misnaming of the PostgreSQL shared libraries on HP-UX I can't.
A summary of the
Tom Lane wrote:
Probably so. I had not realized that HP's linker is affected by which
way the symlinks run, but it appears that it is.
I've just spoken to someone who knows more about the HP-UX toolchain
than I do.
The situation is that the library can have an internal name if the +h
option
I wrote:
My recommendation (with a pinch of salt, since I'm still not a HP-UX
toolchain guru) is to add
+h lib$(NAME)$(DLSUFFIX).$SO_MAJOR_VERSION)
to the HP-UX LINK.shared line in src/Makefile.shlib, and to change the
way the symlinks run as well, so that libpq.sl is a link to the
I'd be interested to hear results of testing CVS tip (now 7.4devel)
on other platforms. Does geometry pass cleanly for you?
Yes for NetBSD-1.5.1/i386, where it previously didn't due to processor
specific math libraries on this platform.
Giles
---(end of
Bruce Momjian [EMAIL PROTECTED] writes:
OK, well BSD/OS now works, but I wonder if there are any other quad
off_t OS's out there without fseeko.
NetBSD prior to 1.6, released September 14, 2002. (Source: CVS logs.)
OpenBSD prior to 2.7, released June 15, 2000. (Source: release notes.)
OK, does pre-1.6 NetBSD have fgetpos/fsetpos that is off_t/quad?
Yes:
int
fgetpos(FILE *stream, fpos_t *pos);
int
fsetpos(FILE *stream, const fpos_t *pos);
Per comments in stdio.h fpos_t is the same format as off_t, and
off_t and fpos_t have been 64 bit since 1994.
Well, this is not related to postgresql exactly but to summerise the
problem, with libc patch PHCO_19090 or compatible upwards, on
HP-UX11, isspace does not work correctly if input value is 127.
o isspace() and such are defined in the standards to operate on characters
o for historic C
Tom Lane writes:
$ man flock
No manual entry for flock.
$
HPUX has generally taken the position of adopting both BSD and SysV
features, so if it doesn't exist here, it's not portable to older
Unixen ...
If only local locking is at issue then finding any one of fcntl()
locking, flock(),
Curtis Faith writes:
I'm no Unix filesystem expert but I don't see how the OS can handle
multiple writes and fsyncs to the same file descriptors without
blocking other processes from writing at the same time.
Why not? Other than the necessary synchronisation for attributes such
as file
Philip Warner writes:
Yes, but there is no guarantee that off_t is implemented as such, nor would
we be wise to assume so (most docs say explicitly not to do so).
I suspect you're reading old documents, which is why I asked what you
were referring to. In the '80s what you are saying would
Philip Warner writes:
My limited reading of off_t stuff now suggests that it would be brave to
assume it is even a simple 64 bit number (or even 3 32 bit numbers).
What are you reading?? If you find a platform with 64 bit file
offsets that doesn't support 64 bit integral types I will not
Tom Lane wrote:
[ discussion of new startup interlock ]
This is not quite ready for prime time yet, because it's not very
bulletproof against the scenario where two would-be postmasters are
starting concurrently.
A solution to this is to require would-be postmasters to obtain an
exclusive
Tom lane wrote:
True, but I think we'll have to deal with that anyway. Even if the
physical database upgrade were trivial, people are going to find
application compatibility problems due to schemas and other 7.3 changes.
More reasons:
a) learning curve -- I want to use 7.3 and gain some
Tom Lane wrote:
Giles Lean [EMAIL PROTECTED] writes:
Is there some reason that file locking is not acceptable? Is there
any platform or filesystem supported for use with PostgreSQL which
doesn't have working exclusive file locking?
How would we know? We have never tried to use
Tom Lane writes:
Rod Taylor [EMAIL PROTECTED] writes:
SunOS control.shared2 5.7 Generic_106541-20 sun4u sparc SUNW,Ultra-5_10
shows an error in ALTER TABLE tests:
ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references
pktable(ptest1);
NOTICE: ALTER TABLE will create implicit
Bruce Momjian [EMAIL PROTECTED] wrote:
From postmaster startup, by default, could we try larger amounts of
buffer memory until it fails then back off and allocate that? Seems
like a nice default to me.
So performance would vary depending on the amount of shared memory
that could be
I know it can have an adverse effect on a mail server, is syslog going
to give us any performance hits?
Yes. On some platforms (HP-UX at least) applications can stall ~2s
retrying if syslogd is not reading the messages written to its pipe.
syslogd also has a reputation for using too much
Hi Peter,
I've been playing with a little program I wrote whose sole purpose is to
write its stdin to a file and close and reopen that file when it receives
a signal. I figured this could work well when integrated transparently
into pg_ctl.
So, is log rotation a concern? Is this a
On 30 Jul 2001 Tom Lane wrote:
[EMAIL PROTECTED] writes:
gcc2.95; hppa2.0-hp-hpux10.20, postgresql 7.1.2
make check checks the first group all right (tests check out ok and
a process postgres: shows up in the process list.
When make check displays parallel group (18 tests): point
At 1:50 AM -0400 4/6/01, Tom Lane wrote:
"Henry B. Hotz" [EMAIL PROTECTED] writes:
Bottom line: 7.1RC1 passes most of the regression tests on
NetBSD/macppc.
The only thing that surprised me here was all of the warnings from
libreadline calls:
tab-complete.c: In function
As the subject says, PostgreSQL 7.1RC3 passes 'make check' when built
as a 64 bit application on HP-UX 11.00.
Yes Vince, I've added it to your results page too:
http://www.postgresql.org/~vev/regress/report.php?50
Regards,
Giles
---(end of
Thanks! I'm not too worried about 1.4.2, but be sure to let us know what
the problem was; it may help out someone else...
NetBSD-1.4.2/i386 passes all tests with 7.1RC3.
My previous test failure on this platform was due to the timezone
information on the test system not being standard; once
Okay, here are my results:
Box 1: C180 (2.0 PA8000), HPUX 10.20
Compile with gcc: all tests pass
Compile with cc: two lines of diffs in geometry (attached)
Box 2: 715/75 (1.1 PA7100LC), HPUX 10.20
Compile with gcc: all tests pass
Compile with cc: all tests pass
I haven't had time
what's the postgresql equivalent of
mysql_real_escape_string()
to escape strings that are going to be passed to queries?
There doesn't seem to be a function to do this in libpq, which I find
slightly odd.
DBD::Pg has quote() function as per usual for perl's DBI, but that's
not a lot of
Hi all,
I've built 7.1beta6 on a number of different HP-UX platforms (11.00 32
bit, 11.00 64 bit, 11i 32 bit).
1. On all these platforms 'make check' hung. Since that's not
critical to whether PostgreSQL works or not I worked around it by
using a different shell:
gmake
I'll look at this next week. If someone can confirm that
/usr/bin/sh works for make check on HP-UX 10.20 that would be
useful.
It does not work. See FAQ_HPUX.
I'm confused: I don't see anything about shells or make check hanging
in doc/FAQ_HPUX. There is clear instruction
Results of 'make check':
NetBSD-1.5/i386 one spurious floating point test failure
(mail sent to postgresql-bugs with details)
NetBSD_1.5/alphaall tests passed
NetBSD-1.4.2/i386 four tests fail
timestamp... FAILED
PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the
above difference is only for i386 + fpu.
It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is
correct.
Regards,
Giles
---(end of broadcast)---
TIP 6:
NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean
Correction: NetBSD-1.5/alpha.
Ciao,
Giles
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Seems that following patch is needed. Now It Works For Me (tm).
Giles, does the regress test now succed for you?
Yes, but I don't like that it is 1.5 specific. I expect that later
NetBSD/i386 releases will also have the "new" floating point behaviour
by default, subject to /etc/ld.so.conf
Thomas Lockhart [EMAIL PROTECTED] writes:
HPUX 10.20 (HP-PA architecture)
Time to drop 9.2 from the list?
I don't have it running here anymore. Is there anyone on the list
who can test on HPUX 9?
HP haven't supported 9.X since the end of 1999 on servers, and since
earlier than
[ Drifting off topic ... ]
Well, that guy might know all about Linux, but he doesn't know anything
about HPUX (at least not any version I've ever run). O_SYNC is
distinctly different from O_DSYNC around here.
There is a HP_UX kernel flag 'o_sync_is_o_dsync' which will cause
O_DSYNC to be
There is a HP_UX kernel flag 'o_sync_is_o_dsync' which will cause
O_DSYNC to be treated as O_SYNC. It defaults to being off -- it
... other way around there, of course. Trying to clarify and
adding confusion instead. :-(
is/was a backward compatibility "feature" since HP-UX 9.X (which is
Just to get some evidence at hand - could some owners of
different platforms compile and run the attached little C
source please?
$ uname -srm
FreeBSD 4.1.1-STABLE
$ ./jan
Pipe buffer is 16384 bytes
Sys-V message queue buffer is 2048 bytes
$ uname -srm
NetBSD 1.5 alpha
When you mmap, you don't use write() ! mlock actualy locks page in
memory and as long as the page is locked the OS doesn't attempt to
store the dirty page. It is intended also for security app to
ensure that sensitive data are not written to unsecure storage
(hdd). It is definition of
Sounds quite unreliable to me. Unless there's some interlock ... like,
say, the second sync not being able to advance past a buffer page that's
as yet unwritten by the first sync. But would all Unixen share such a
strange detail of implementation?
I heard Kirk McKusick tell this story in
50 matches
Mail list logo
