> > ...right now I am worried about whether we'd be able to reconfirm regress
> > results on all the currently-supported platforms before release.
>
> This would be an excellent topic for a full development cycle ;)
Oh, I see. Never mind. I was lost.
--
Bruce Momjian
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > But are they going to change the default to run the regression tests?
>
> You're barking up the wrong tree, Bruce. Hiroshi specifically said
> that he does *not* want to change the default behavior.
OK, I am confused. Can someone straighten me o
> I can't beleive that AIX finally has a convenience function that
> is missing in mainstream unix :-)
Better not report it; they'll take it out ;)
- Thomas
> ...right now I am worried about whether we'd be able to reconfirm regress
> results on all the currently-supported platforms before release.
This would be an excellent topic for a full development cycle ;)
- Thomas
Bruce Momjian <[EMAIL PROTECTED]> writes:
> But are they going to change the default to run the regression tests?
You're barking up the wrong tree, Bruce. Hiroshi specifically said
that he does *not* want to change the default behavior.
regards, tom lane
> > > same as current output format then we would have no
> > > problem with the current regress test. But there
> > > could be a choise to change default output format
> > > to have a large enough presision to distinguish
> > > float4(8).
> >
> > But are they going to change the default to run t
Bruce Momjian wrote:
>
> > > > >From the first I don't want to change the current default
> > > > output format
> > > > "%." #FLT_DIG "g" (REAL)
> > > > "%." #DBL_DIG "g" (DOUBLE PRECISION)
> > > > for 7.1 because their changes would cause a regress
> > > > test failure.
> > >
> > > Bu
> Hmm, on looking at the code, this might mean we need some configure
> pushups to extract FLT_DIG and DBL_DIG and put those into the default
> strings. Do we support any platforms where these are not 6 & 15?
In principle, yes. VAX does not use IEEE math (by default anyway) and
has less range an
> > > >From the first I don't want to change the current default
> > > output format
> > > "%." #FLT_DIG "g" (REAL)
> > > "%." #DBL_DIG "g" (DOUBLE PRECISION)
> > > for 7.1 because their changes would cause a regress
> > > test failure.
> >
> > But we run regress with the proper setti
Justin Clift <[EMAIL PROTECTED]> writes:
> How about thinking in the other direction is it possible for
> PostgreSQL to be able to recognised localised versions of SQL queries?
> i.e. For a Turkish locale it associates "ýnsert" INSERT and "unýon"
> with UNION.
Hmm. Wouldn't that mean that
Tom Lane wrote:
>
> Sezai YILMAZ <[EMAIL PROTECTED]> writes:
> > With Turkish locale it is not possible to write SQL queries in
> > CAPITAL letters. SQL identifiers like "INSERT" and "UNION" first
> > are downgraded to "ýnsert" and Then "ýnsert" and "unýon"
> > does not match as SQL identifier.
Larry Rosenman <[EMAIL PROTECTED]> writes:
> What about EBCDIC (IBM MainFrame, I.E. Linux on S/390, Z/390).
Right, that was what I meant about not wanting to hardwire assumptions
about ASCII.
We could instead code it as
if (isupper(ch))
ch = ch + ('a' - 'A');
which I believe
* Tom Lane <[EMAIL PROTECTED]> [010219 21:02]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > What about EBCDIC (IBM MainFrame, I.E. Linux on S/390, Z/390).
>
> Right, that was what I meant about not wanting to hardwire assumptions
> about ASCII.
>
> We could instead code it as
>
> if
* Tom Lane <[EMAIL PROTECTED]> [010219 20:31]:
>
> Hm. Several problems here:
>
> (1) This solution would break in other locales where isupper() may
> return TRUE for characters other than 'A'..'Z'.
>
> (2) We could fix that by gutting the isascii/isupper test as well,
> reducing it to "yytext
Bruce Momjian wrote:
>
> >
> > Tom Lane wrote:
> > >
> > > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > > Actually, you're going to have to recode the float*in() functions, using
> > > > scanf, and scanf's formats are not always equivalent to printf's.
> > >
> > > Further thought: one answer
Sezai YILMAZ <[EMAIL PROTECTED]> writes:
> With Turkish locale it is not possible to write SQL queries in
> CAPITAL letters. SQL identifiers like "INSERT" and "UNION" first
> are downgraded to "ýnsert" and "unýon". Then "ýnsert" and "unýon"
> does not match as SQL identifier.
Ugh.
>
>
> Tom Lane wrote:
> >
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Actually, you're going to have to recode the float*in() functions, using
> > > scanf, and scanf's formats are not always equivalent to printf's.
> >
> > Further thought: one answer to this is to institute four SET va
Tom Lane wrote:
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Actually, you're going to have to recode the float*in() functions, using
> > scanf, and scanf's formats are not always equivalent to printf's.
>
> Further thought: one answer to this is to institute four SET variables,
> two for
Bruce Momjian wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> Yes. Let me add some TODO items:
>
> * Add deleted bit to index tuples to reduce heap access
ISTM this isn't a bad idea. However note that there remains only
1 bit unused in IndexTupleData.
Regards,
Hiroshi Inoue
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I've been suspicious if pgbench is an (unique)
> appropiriate test case for evaluaing commit_delay.
Of course it isn't. Never trust only one benchmark.
I've asked the Great Bridge folks to run their TPC-C benchmark with both
zero and small nonzero com
I find that if one specifies, say,
configure --with-includes=/usr/local/include
one gets compiler commands like
cc -Ae -g +z -I/usr/local/include -I../../../src/include
-I../../../src/interfaces/libpq -c -o pgtcl.o pgtcl.c
because the -I commands are added to CPPFLAGS which a
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > In your test cases I always see "where bid = 1" at "update branches"
> > i.e.
> > update branches set bbalance = bbalance + ... where bid = 1
>
> > ISTM there's no multiple COMMIT in your senario-s due to
> > their lock conflicts
Tom Lane wrote:
> For the RPM installation this doesn't matter anyway (I think), but it
> would for non-RPM installs.
You would be correct, as the old version will be either overwritten
during the new version's install or removed during the previous
version's RPM uninstall. RPM is pretty good at
I notice that if the platform's template doesn't set CFLAGS, then
configure will give you -g in CFLAGS whether you ask for it or not
(courtesy of AC_PROG_CC). The --enable-debug configure switch thus does
not function as advertised. If we are going to say that --enable-debug
isn't recommended fo
Larry Rosenman <[EMAIL PROTECTED]> writes:
> AND make sure we nuke any OLD version in $(destdir)/include... Which
> will cause a file not found vs. compile errors based on redeclares...?
Hm. Good point, not only for postgres.h but also for the other include
files we no longer install by default.
* Larry Rosenman <[EMAIL PROTECTED]> [010219 15:45]:
> * Tom Lane <[EMAIL PROTECTED]> [010219 15:43]:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > I still think we need a dummy postgres.h in $(destdir)/include to
> > > catch others using it this release. PHP 4.0.4pl1 and earlier will
> >
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Seems a better solution would be to put a 'deleted' bit in the index so
> > we would have to visit those heap tuples only once for a committed
> > status. Similar to what we do with heap tuples so we don't have to
> > visit pg_log repeatedly.
>
> T
On Mon, 19 Feb 2001, Tom Lane wrote:
> I'm not quite sure how to implement this, but I wanted to toss the idea
> out for discussion. Probably we'd have to have some cooperation between
> the heap_update level (where the fact that it's an update is known, and
> where we'd have a chance to test fo
* Tom Lane <[EMAIL PROTECTED]> [010219 15:43]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > I still think we need a dummy postgres.h in $(destdir)/include to
> > catch others using it this release. PHP 4.0.4pl1 and earlier will
> > *BREAK* unless we do.
>
> If we do that, no one will ever f
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I still think we need a dummy postgres.h in $(destdir)/include to
> catch others using it this release. PHP 4.0.4pl1 and earlier will
> *BREAK* unless we do.
If we do that, no one will ever fix their code. Moreover, such an
approach would conflict w
* Sascha Schumann <[EMAIL PROTECTED]> [010219 10:57]:
> > AFAIK there is no need for you to be including in *any*
> > Postgres release --- it's supposed to be an internal header file,
> > not something that client applications need. Try it with just
>
> /home/sas/src/php4/ext/pgsql/pgsql.c: In
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I like this one - except for the OID which should IMHO read
> > INSERTED_OID.
>
> I just committed changes that make it RESULT_OID, but if you like
> INSERTED_OID better, we could change it...
Oh boy,
at your current sp
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Seems a better solution would be to put a 'deleted' bit in the index so
> we would have to visit those heap tuples only once for a committed
> status. Similar to what we do with heap tuples so we don't have to
> visit pg_log repeatedly.
That's only a p
> I'm not quite sure how to implement this, but I wanted to toss the idea
> out for discussion. Probably we'd have to have some cooperation between
> the heap_update level (where the fact that it's an update is known, and
> where we'd have a chance to test for changes in particular columns) and
>
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I like this one - except for the OID which should IMHO read
> > INSERTED_OID.
>
> I just committed changes that make it RESULT_OID, but if you like
> INSERTED_OID better, we could change it...
I think I like RESULT_OID because the standard us
Over the weekend I noticed that Tatsuo's pgbench benchmark seems to
spend an awful lot of its time down inside _bt_check_unique. This
happens because with table declarations like
create table accounts(aid int, primary key(aid), bid int,
abalance int, filler char(84))
an
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Open list updated. Looks like the list is done. Can I move "Stuck
> > btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN
> > clauses" done?
>
> I think both of those are actually done. Vadim might want to tweak
> the tim
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Open list updated. Looks like the list is done. Can I move "Stuck
> > btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN
> > clauses" done?
>
> I think both of those are actually done. Vadim might want to tweak
> the tim
Philip Warner wrote:
>
> Unfortunately, I don't have an awful lot of free time at the moment, so I
> won't be able to look at this for at *least* as week.
I'll do it as soon as we decided about the final syntax and
keywords.
Jan
--
#==
Jan Wieck <[EMAIL PROTECTED]> writes:
> I like this one - except for the OID which should IMHO read
> INSERTED_OID.
I just committed changes that make it RESULT_OID, but if you like
INSERTED_OID better, we could change it...
regards, tom lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Open list updated. Looks like the list is done. Can I move "Stuck
> btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN
> clauses" done?
I think both of those are actually done. Vadim might want to tweak
the timeouts I select
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 something
> useful, but it doesn't. I'd recom
Tom Lane wrote:
> 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 hav
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 with the spec's syn
Philip Warner wrote:
>
> P.S. Is Jan around? He's been very quiet recently...
He is,
just a little quiet. I can live with it either way. The main
problem, as said, is that we need to allow some keywords as
identifiers in PL/pgSQL like in the main parser. Actually we
added RES
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Well, this clearly is a release-stopper because we don't want to release
> > a non-standard GET DIAGNOSTICS. It will be fixed before 7.1 final by
> > someone. I have added it to the open items list.
>
> Done.
>
> I ended up using RESULT_OID for t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, this clearly is a release-stopper because we don't want to release
> a non-standard GET DIAGNOSTICS. It will be fixed before 7.1 final by
> someone. I have added it to the open items list.
Done.
I ended up using RESULT_OID for the keyword that
Philip Warner <[EMAIL PROTECTED]> writes:
> Unfortunately, I don't have an awful lot of free time at the moment, so I
> won't be able to look at this for at *least* as week.
It looks like a pretty straightforward change; I'll try to get it done
today.
regards, tom lane
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> In your test cases I always see "where bid = 1" at "update branches"
> i.e.
> update branches set bbalance = bbalance + ... where bid = 1
> ISTM there's no multiple COMMIT in your senario-s due to
> their lock conflicts.
Hmm. It looks like using a
> Hiroshi Inoue writes:
>
> > The 7.1-release seems near.
> > May I provide the followings ?
> > SET FLOAT4_PRECISION TO ..
> > SET FLOAT8_PRECISION TO ..
>
> I'd prefer names that go with the SQL type names:
>
> REAL_FORMAT
> DOUBLE_PRECISION_FORMAT
>
> Seems a bit tacky, but a lot of
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Actually, you're going to have to recode the float*in() functions, using
> scanf, and scanf's formats are not always equivalent to printf's.
Further thought: one answer to this is to institute four SET variables,
two for output and two for input; per
I did not realize how much WAL improved performance when using fsync.
> > "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > > So, is it OK to use commit_delay=0?
> >
> > Certainly. In fact, I think that's about to become the default ;-)
>
> I agree with Tom. I did some benchmarking tests using
> AFAIK there is no need for you to be including in *any*
> Postgres release --- it's supposed to be an internal header file,
> not something that client applications need. Try it with just
/home/sas/src/php4/ext/pgsql/pgsql.c: In function `php_if_pg_getlastoid':
/home/sas/src/php4/ext/pgsql/pg
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Or must we postpone to fix it ?
> Actually, you're going to have to recode the float*in() functions, using
> scanf, and scanf's formats are not always equivalent to printf's.
Hmm... that wouldn't matter, except for this %a format. Maybe we'd
bette
Matthew Kirkwood <[EMAIL PROTECTED]> writes:
> BTW, I have attached two patches which streamline log initialisation
> a little. The first (xlog-sendfile.diff) adds support for Linux's
> sendfile system call. FreeBSD and HP/UX have sendfile() too, but the
> prototype is different. If it's intere
Sascha Schumann <[EMAIL PROTECTED]> writes:
>> I don't believe you will break if that patch is applied now.
> InvalidOid is not defined otherwise.
Oh, is that the problem? Okay, do this:
#include
#ifndef InvalidOid
#define InvalidOid ((Oid) 0)
#endif
I kne
Sascha Schumann <[EMAIL PROTECTED]> writes:
> It'd be cool, if PostgreSQL and/or the C front-end would have
> a numeric version indicator which we could use to check for
> features, etc.
> #include
> #if defined(PGSQL_FE_VERSION) && PGSQL_FE_VERSION < 20010210
> # include
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> So, what was the case against using yield (2) ?
$ man 2 yield
No entry for yield in section 2 of the manual.
Lack of portability :-(
regards, tom lane
Hiroshi Inoue 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 ?
Actually, you're going to have to recode the float*in() functions, using
scanf, and scanf's formats are n
> > So, what was the case against using yield (2) ?
>
> $ man 2 yield
> No entry for yield in section 2 of the manual.
>
> Lack of portability :-(
I can't beleive that AIX finally has a convenience function that
is missing in mainstream unix :-)
$man 2 yield
Purpose
Yields the proces
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> * Add SET FLOAT4_PRECISION and SET FLOAT8_PRECISION using printf args
foo_PRECISION is not the right name if these variables will contain
printf format strings. Perhaps foo_FORMAT? Anyone have a better idea?
After further thoug
Hiroshi Inoue writes:
> The 7.1-release seems near.
> May I provide the followings ?
> SET FLOAT4_PRECISION TO ..
> SET FLOAT8_PRECISION TO ..
I'd prefer names that go with the SQL type names:
REAL_FORMAT
DOUBLE_PRECISION_FORMAT
Seems a bit tacky, but a lot of work has been put in
> 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
> l
> * 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 Uni
> At least on AIX it looks like the select with 0 timeout is a noop, and does not
> yield the processor. There was discussion, that other OS's (BSD) also does an
> immediate return in case of 0 timeout.
>
> Minimum select(2) delay is 1 msec on AIX (tested with Tom's test.c).
>
> So, what was th
On Mon, 19 Feb 2001, Matthew Kirkwood wrote:
> BTW, I have attached two patches which streamline log initialisation
> a little. The first (xlog-sendfile.diff) adds support for Linux's
> sendfile system call.
Whoops, don't use this. It looks like Linux won't sendfile()
from /dev/zero. I'll end
On Mon, 19 Feb 2001, Larry Rosenman wrote:
> * Sascha Schumann <[EMAIL PROTECTED]> [010219 07:42]:
> > > I don't believe you will break if that patch is applied now.
> > >
> >
> > InvalidOid is not defined otherwise.
> aha. Ok. PG-Hackers: Can we include a Dummy or #warning postgres.h
> in
* Sascha Schumann <[EMAIL PROTECTED]> [010219 07:42]:
> > I don't believe you will break if that patch is applied now.
> >
>
> InvalidOid is not defined otherwise.
aha. Ok. PG-Hackers: Can we include a Dummy or #warning postgres.h
in 7.1?
I.E.:
#ifndef _POSTGRES_H
#define _POSTGRES_H
#war
> I don't believe you will break if that patch is applied now.
>
InvalidOid is not defined otherwise.
- Sascha
On Sun, 18 Feb 2001, Tom Lane wrote:
> I think that there may be a performance advantage to pre-filling the
> logfile even so, assuming that file allocation info is stored in a
> Berkeley/McKusik-like fashion (note: I have no idea what ext2 or
> reiserfs actually do).
ext2 is a lot like [UF]FS.
* Sascha Schumann <[EMAIL PROTECTED]> [010219 01:37]:
> 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 unle
> We *do* need to support ROW_COUNT, but allowing
>
> GET DIAGNOSTICS Select ROW_COUNT, SQLCODE, OID Into :a,:b:,:c;
>
> is a lot friendlier than the standard:
>
> GET DIAGNOSTICS :a = ROW_COUNT;
> GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE;
> GET DIAGNOSTICS :c = OID;
>
> (not
On Sun, 18 Feb 2001, Bruce Momjian wrote:
> 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.
I've committed an autoconf check, so PHP 4.0.5 and upwards
will be compatible with existing and futu
Quoting The Hermit Hacker <[EMAIL PROTECTED]>:
> 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 h
> > The easy fix is to just set the delay to zero. Looks like that will fix
> > most of the problem.
>
> Except that Vadim had a reason for setting it to 5, and I'm loath to see
> that changed unless someone actaully understands the ramifications other
> then increasing performance ...
Vadim o
On Mon, Feb 19, 2001 at 12:26:44AM -0500, Tom Lane wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > Anyway such stuff should be documented I guess. From current
> > docs I read that it should work.
>
> Where?
And ofcourse, you are right :) I was confused of result columns
vs. table columns
Tom Lane wrote:
>
> I wrote:
> > Thus, our past arguments about whether a few microseconds of delay
> > before commit are a good idea seem moot; we do not have any portable way
> > of implementing that, and a ten millisecond delay for commit is clearly
> > Not Good.
>
> I've now finished running
77 matches
Mail list logo
