fdatasync() is available on Tru64 and according to the man-page behaves
as Tom expects. So it should be a win for us. What do other commercial
unixes say?
Adriaan
Hi,
There seems to be a teeny-tiny bug in the beta4 RPMS.
/etc/rc.d/init.d/postgresql contains:
# PGVERSION is:
PGVERSION=7.1beta3
Matthew.
On Sat, 17 Feb 2001, Tom Lane wrote:
> the default -B is way too small for WAL.
OK, here are some 2.4 numbers with 1K transactions/client
and -B10240.
> Huh? With the exception of the 16-user case (possibly measurement
> noise), 2.4 looks better across the board, AFAICS. But see below.
OK.
* Tom Lane <[EMAIL PROTECTED]> [010218 10:53]:
> Adriaan Joubert <[EMAIL PROTECTED]> writes:
> > fdatasync() is available on Tru64 and according to the man-page behaves
> > as Tom expects. So it should be a win for us.
>
> Careful ... HPUX's man page also claims that fdatasync does something
> us
Adriaan Joubert <[EMAIL PROTECTED]> writes:
> fdatasync() is available on Tru64 and according to the man-page behaves
> as Tom expects. So it should be a win for us.
Careful ... HPUX's man page also claims that fdatasync does something
useful, but it doesn't. I'd recommend an experiment. Does t
Larry Rosenman <[EMAIL PROTECTED]> writes:
> BTW, UnixWare 7.1.1 does *NOT* have fdatasync. What standard created
> this one?
HP's manpage quoth:
STANDARDS CONFORMANCE
fsync(): AES, SVID3, XPG3, XPG4, POSIX.4
fdatasync(): POSIX.4
regards, tom lane
Tom Lane <[EMAIL PROTECTED]> writes:
> The implication is that the only thing you can lose after fdatasync is
> the highly-inessential file mod time. However, I have been told that
> on some implementations, fdatasync only flushes data blocks, and never
> writes the inode or indirect blocks. Th
Jerome Vouillon <[EMAIL PROTECTED]> writes:
> Actually, there is also a performance reason. Indeed, fdatasync would
> not perform any better than fsync if the log file was not
> preallocated: the file length would change each time a record is
> appended, and therefore the inode would have to be up
Say Bruce, I notice that a lot of the files under src/bin still have
# Copyright (c) 1994, Regents of the University of California
and have never had a Postgres group copyright added to them. I updated
createdb just now to
# Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I see a small problem with the regression test. If PL/pgSQL has been
> already to template1, the regression scripts will fail because
> createlang fails. Probably we should create the regression database
> using template0?
Done ...
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> things appear to have quieted off nicely ... so would like to put out a
> Beta5 for testing ...
Unless Peter E. has some more commits up his sleeve, I think we're
good to go.
regards, tom lane
> Say Bruce, I notice that a lot of the files under src/bin still have
>
> # Copyright (c) 1994, Regents of the University of California
>
> and have never had a Postgres group copyright added to them. I updated
> createdb just now to
>
> # Portions Copyright (c) 1996-2001, PostgreSQL Global D
Tom Lane writes:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > things appear to have quieted off nicely ... so would like to put out a
> > Beta5 for testing ...
>
> Unless Peter E. has some more commits up his sleeve, I think we're
> good to go.
Just uploaded freshly baked man pages, inclu
On Sun, 18 Feb 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > things appear to have quieted off nicely ... so would like to put out a
> > Beta5 for testing ...
>
> Unless Peter E. has some more commits up his sleeve, I think we're
> good to go.
okay, I'll put one out M
On Sat, 17 Feb 2001, Tom Lane wrote:
[skip]
TL> Platform: HPUX 10.20 on HPPA C180, fast wide SCSI discs, 7200rpm (I think).
TL> Minimum select(2) delay is 10 msec on this platform.
[skip]
TL> I vote for commit_delay = 0, unless someone can show cases where
TL> positive delay is significantly b
On Sun, Feb 18, 2001 at 11:51:50AM -0500, Tom Lane wrote:
> Adriaan Joubert <[EMAIL PROTECTED]> writes:
> > fdatasync() is available on Tru64 and according to the man-page behaves
> > as Tom expects. So it should be a win for us.
>
> Careful ... HPUX's man page also claims that fdatasync does som
PHP 4.0.4pl1 Build dies with current CVS:
Making all in pgsql
gmake[2]: Entering directory `/home/ler/php/ext/pgsql'
gmake[3]: Entering directory `/home/ler/php/ext/pgsql'
/bin/sh /home/ler/php/libtool --silent --mode=compile cc -Xb -I.
-I/home/ler/php/ext/pgsql -I/home/ler/php/main -I/home/ler/p
> TL> I vote for commit_delay = 0, unless someone can show cases where
> TL> positive delay is significantly better than zero delay.
>
> BTW, for modern versions of FreeBSD kernels, there is HZ kernel option
> which describes maximum timeslice granularity (actually, HZ value is
> number of timesl
On Sun, 18 Feb 2001, Dmitry Morozovsky wrote:
I just done the experiment with increasing HZ to 1000 on my own machine
(PII 374). Your test program reports 2 ms instead of 20. The other side
of increasing HZ is surely more overhead to scheduler system. Anyway, it's
a bit of data to dig into, I sup
On Sun, 18 Feb 2001, Dmitry Morozovsky wrote:
DM> I just done the experiment with increasing HZ to 1000 on my own machine
DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
DM> of increasing HZ is surely more overhead to scheduler system. Anyway, it's
DM> a bit of data to
OK, I found it. PHP was including postgres.h (which we no longer
install, so we were picking up a Feb 7 version).
Changing php's ext/pgsql/php_pgsql.h to #include
fixes it.
This is a gotcha for people following CVS or not cleaning out
the $(DESTDIR)/include directory
I'll submit a patc
Just an FYI... PHP compiles with up to and including PG-Beta4..
-Mitch
- Original Message -
From: "Larry Rosenman" <[EMAIL PROTECTED]>
To: "PostgreSQL Hackers List" <[EMAIL PROTECTED]>
Sent: Sunday, February 18, 2001 3:18 PM
Subject: PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS
> PHP
Re-Sent due to bounce from ftp.postgresql.org
- Forwarded message from Larry Rosenman <[EMAIL PROTECTED]> -
From: Larry Rosenman <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS
Date: Sun, 18 Feb 2001 14:41:33 -0600
Message-ID: <[EMAIL PROTECTED]>
Us
* Tom Lane <[EMAIL PROTECTED]> [010218 16:54]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > OK, I found it. PHP was including postgres.h (which we no longer
> > install, so we were picking up a Feb 7 version).
> > Changing php's ext/pgsql/php_pgsql.h to #include
> > fixes it.
>
> Hm.
* Tom Lane <[EMAIL PROTECTED]> [010218 16:54]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > OK, I found it. PHP was including postgres.h (which we no longer
> > install, so we were picking up a Feb 7 version).
> > Changing php's ext/pgsql/php_pgsql.h to #include
> > fixes it.
>
> Hm.
* Tom Lane <[EMAIL PROTECTED]> [010218 16:54]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > OK, I found it. PHP was including postgres.h (which we no longer
> > install, so we were picking up a Feb 7 version).
> > Changing php's ext/pgsql/php_pgsql.h to #include
> > fixes it.
>
> Hm.
Larry Rosenman <[EMAIL PROTECTED]> writes:
> OK, I found it. PHP was including postgres.h (which we no longer
> install, so we were picking up a Feb 7 version).
> Changing php's ext/pgsql/php_pgsql.h to #include
> fixes it.
Hm. Should php be including either one? I would have been in le
Starting with PostgreSQL 7.1beta5 (or current CVS), PHP's pgsql
extension needs to only include to compile.
Here is a patch:
Index: php_pgsql.h
===
RCS file: /cvsroot/php/ext/pgsql/php_pgsql.h,v
retrieving revision 1.1.1.2
diff -
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>:
> :Do a
> :
> :GET DIAGNOSTICS SELECT PROCESSED INTO ;
> :
> :directly after an INSERT, UPDATE or DELETE statement and you'll know
> :how many rows have been hit.
> :
> :Also you can
I sure hope it gets more attention than some of the other PHP PostgreSQL
bugs.. I don't mean to trash anyone here but the pg_connect problem has been
around since 4.0.1 and has yet to be addressed. One of our programmers is
taking a look at that one but he's not been able to fix it yet.
*crosses
What works:
# select o.id from op o order by o.id;
# select o.id from op o union all SELECT -1 order by id;
Does not work:
# select o.id from op o union all SELECT -1 order by o.id;
ERROR: Relation 'o' does not exist
# select o.id from op o union all SELECT -1 from op o order by o.id;
ERROR:
"Mitch Vincent" <[EMAIL PROTECTED]> writes:
> Is there anything stupendously broken in PG beta 4?
Other than the bug I introduced into b4 for views containing UNION, a
quick scan of the CVS logs doesn't show any showstoppers fixed in the
backend (dunno what all Peter Mount has been doing in JDBC
Marko Kreen <[EMAIL PROTECTED]> writes:
> What works:
> # select o.id from op o union all SELECT -1 order by id;
This is valid SQL.
> # select o.id from op o union all SELECT -1 order by o.id;
> ERROR: Relation 'o' does not exist
This is not valid SQL. For one thing, the table alias "o" is no
At 18:49 18/02/01 -0500, Tom Lane wrote:
>Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> :
>> :GET DIAGNOSTICS SELECT RESULT INTO ;
>
>> May I suggest that this is the wrong syntax? It should be
>
>Hmm, that's definitely what SQL99 uses for the syntax. I wonder where
>Jan got the SELECT INT
Philip Warner <[EMAIL PROTECTED]> writes:
>> Hmm, that's definitely what SQL99 uses for the syntax. I wonder where
>> Jan got the SELECT INTO syntax --- did he borrow it from Oracle?
> Sadly, we made it up.
Ah so. Well, friendliness aside, I'd go with the spec's syntax.
> We *do* need to supp
On Sun, Feb 18, 2001 at 08:24:20PM -0500, Tom Lane wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > What works:
> > # select o.id from op o union all SELECT -1 order by id;
>
> This is valid SQL.
>
> > # select o.id from op o union all SELECT -1 order by o.id;
> > ERROR: Relation 'o' does n
* Bruce Momjian <[EMAIL PROTECTED]> [010218 21:23]:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > I sure hope it gets more attention than some of the other PHP PostgreSQL
> > bugs.. I don't mean to trash anyone here but the pg_connect problem has been
> > around since 4.0.1 and has yet t
[ Charset ISO-8859-1 unsupported, converting... ]
> I sure hope it gets more attention than some of the other PHP PostgreSQL
> bugs.. I don't mean to trash anyone here but the pg_connect problem has been
> around since 4.0.1 and has yet to be addressed. One of our programmers is
> taking a look at
At 20:40 18/02/01 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>>> Hmm, that's definitely what SQL99 uses for the syntax. I wonder where
>>> Jan got the SELECT INTO syntax --- did he borrow it from Oracle?
>
>> Sadly, we made it up.
>
>Ah so. Well, friendliness aside, I'd go
Great! Glad to see our PHP interface improving.
> FWIW, I emailed Thies about the pg_connect problems, and whis is what he
> responded with (yesterday would be Feb 13):
>
>
>
> i've commited a fix for this to PHP 4 CVS yesterday.
>
> if you don't want to live on the "bleeding edg
Just shoot it over to the PHP folks. Seems they are already on top if
it. I don't want to work around their normal system unless necessary.
> * Bruce Momjian <[EMAIL PROTECTED]> [010218 21:23]:
> > [ Charset ISO-8859-1 unsupported, converting... ]
> > > I sure hope it gets more attention than
FWIW, I emailed Thies about the pg_connect problems, and whis is what he
responded with (yesterday would be Feb 13):
i've commited a fix for this to PHP 4 CVS yesterday.
if you don't want to live on the "bleeding edge" (use PHP
from CVS) just replace the php_pgsql_set_default_l
> >> GET DIAGNOSTICS :c = OID;
> >
> >It looks to me like SQL99 allows
> >
> > GET DIAGNOSTICS :a = ROW_COUNT, :b = OID, ...;
>
> Yes, but condition information (eg. SPI RESULT or SQLCODE), needs a
> separate statement to row information (eg. ROW_COUNT). ie.
>
> GET DIAGNOSTICS :a =
* Bruce Momjian <[EMAIL PROTECTED]> [010218 22:25]:
> Just shoot it over to the PHP folks. Seems they are already on top if
> it. I don't want to work around their normal system unless necessary.
Their stuff seems to sit forever. I put it in the BugDB.
I have a couple of other UnixWare issues
Marko Kreen <[EMAIL PROTECTED]> writes:
> # select o.id from op o union all SELECT -1 order by o.id;
> ERROR: Relation 'o' does not exist
>>
>> This is not valid SQL. For one thing, the table alias "o" is not
>> visible outside the first component SELECT.
>>
>> Yes, I know 7.0 took it... but i
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> The 7.1-release seems near.
> May I provide the followings ?
> SET FLOAT4_PRECISION TO ..
> SET FLOAT8_PRECISION TO ..
> Or must we postpone to fix it ?
This seems a small enough change that I do not fear fixing it at this
late date. Howev
I wrote:
>
> > -Original Message-
> > From: Tom Lane [mailto:[EMAIL PROTECTED]]
> >
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
[snip]
>
> > Peter's idea of a SET variable to control float display format might
> > not be a bad idea, but what if anything should pg_dump do with it?
>
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The defaults
>> would be "%.7g" and "%.17g" (or thereabouts, not sure what number of
>> digits we are currently using).
> Wouldn't changing current '%.6g','%.15g'(on many platforms)
> cause the regression test failure ?
I didn't che
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > The 7.1-release seems near.
> > May I provide the followings ?
> > SET FLOAT4_PRECISION TO ..
> > SET FLOAT8_PRECISION TO ..
>
> > Or must we postpone to fix it ?
>
> This seems a small enough change that I do not fear
On Sun, 18 Feb 2001, Larry Rosenman wrote:
> * Bruce Momjian <[EMAIL PROTECTED]> [010218 22:25]:
> > Just shoot it over to the PHP folks. Seems they are already on top if
> > it. I don't want to work around their normal system unless necessary.
> Their stuff seems to sit forever. I put it in t
50 matches
Mail list logo
