Tom Lane 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 continue to think is
Bruce Momjian 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 (always possible!) a
Greg Stark 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 second f
Abhijit Menon-Sen 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 the entire
Tom Lane 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__
NetBSD: __NetBSD_
Hitoshi Harada 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) x86_64 real machi
Josh Berkus 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 (no
updates, 64
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
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.
>
> Definitel
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
> 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
>
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 p
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 quie
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
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
optio
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 pr
> 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 broadcast)
> 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 fpos_t is the same format as off_t, and
off_t and fpos_t have been 64 bit since 1994.
http://cvswe
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.)
F
> 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 rea
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 s
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, fl
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:
> 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?
>
> H
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:
[ 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
exclusiv
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 creat
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 all
> 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 C
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
[ I realise the discussion has left strxfrm(), but for the archives
if nothing else ... ]
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> We'd need to implement the strxfrm() function in SQL and the $<=$
> operator, both of which are trivial. The index would have to be in terms
> of strxfrm().
> 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.
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 broadcast)--
> 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'
> 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
> 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 lo
> Hm, I thought I had updated that before beta6. What it has now is
> The parallel regression test script (gmake check) is known to lock up
> when run under HP's default Bourne shell, at least in HPUX 10.20. This
> appears to be a shell bug, not the fault of the script. If you see that
> th
> >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 instru
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 SHELL=$HOME/bin
> 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
> 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
> 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: Ha
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
> 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
ea
> 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 alph
> 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 i
[ 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
> 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
Tom Lane wrote:
> I am not sure we can/should use gettext (possible license problems?),
> but certainly something like this could be cooked up.
http://citrus.bsdclub.org/index-en.html
I'm not sure of the current status of the code.
Regards,
Giles
---(end of broadcas
> 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
53 matches
Mail list logo
