Now WAL is ON by default. make distclean + initdb are required.
Vadim
I get the following when doing a fresh build:
make[4]: Entering directory
`/home/pjw/work/postgresql-cvs/pgsql/src/interfaces/ecpg/preproc'
bison -y -d preproc.y
("preproc.y", line 2256) error: $5 of `CreatedbStmt' has no declared type
("preproc.y", line 2256) error: invalid $ value
On 20 November 2000 18:52, Philip Warner wrote:
I get the following when doing a fresh build:
Did you made distclean?
make[4]: Entering directory
`/home/pjw/work/postgresql-cvs/pgsql/src/interfaces/ecpg/preproc'
bison -y -d preproc.y
("preproc.y", line 2256) error: $5 of `CreatedbStmt'
Is it normal that a query that takes 1 sec when executed from psql
prompt
takes 15 sek when executed from a function (and takes 95% of cpu for
all that time ?
example (on 7.0.2)
UPDATE item SET id_path = '';
returns immediately (on 2000 item table)
then I create a function
CREATE FUNCTION
Configured as:
CC=cc CXX=CC ./configure --prefix=/home/ler/pg-test --enable-syslog --with-CXX
--with-perl --enable-multibyte --with-includes=/usr/local/include
--with-libs=/usr/local/lib
I get:
gmake -C doc all
gmake[1]: Entering directory `/home/ler/pg-dev/pgsql/doc'
gmake[1]: Nothing to
* Larry Rosenman [EMAIL PROTECTED] [001120 09:05]:
[snip]
more info. It seems to not like the following from
src/include/buffer/bufpage.h (line 305):
#define PageSetLSN(page, lsn) \
(((PageHeader) (page))-pd_lsn = (XLogRecPtr) (lsn))
I'm not sure what it's trying to do...
LER
--
Thomas Lockhart [EMAIL PROTECTED] writes:
as for the behavior of Linux distribution vendors who set RPM_OPT_FLAGS
differently from the way they built libc, well, words fail me...
Which distros would these be? I know that Mandrake chooses some mutually
exclusive flags (-On and -fast-math) but
"Christopher Kings-Lynne" [EMAIL PROTECTED] writes:
* I assume that the command is supposed to allow the dropping of unique,
primary, foreign key and check constraints? Should 'not null' constraints
also be included here?
Sure.
* Unique constraints are implemented as indicies, so dropping
After reading Vadim's note stating the WAL is enabled by default,
I downloaded sources from CVS to rebuild the latest version.
There are errors in ecpg's preproc.y grammar that weren't there
in the CVS sources I built yesterday.
The two rules "createdb_opt_item" and "createdb_opt_list" aren't
Hannu Krosing [EMAIL PROTECTED] writes:
Is it normal that a query that takes 1 sec when executed from psql
prompt takes 15 sek when executed from a function
No. I can't reproduce the quoted misbehavior under either 7.0.2 or
current sources; your example takes ~1 sec either way for me.
Tom Lane wrote:
"Christopher Kings-Lynne" [EMAIL PROTECTED] writes:
* I assume that the command is supposed to allow the dropping of unique,
primary, foreign key and check constraints? Should 'not null' constraints
also be included here?
Sure.
* Unique constraints are implemented
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Is it normal that a query that takes 1 sec when executed from psql
prompt takes 15 sek when executed from a function
No. I can't reproduce the quoted misbehavior under either 7.0.2 or
current sources; your example takes ~1 sec
On Mon, Nov 20, 2000 at 06:52:20PM +0200, Hannu Krosing wrote:
Dumping constraints in human-readable form (instead of CREATE CONSTRAIN
TRIGGER) would also be great.
In fact, IMHO, this would be a great place to start: we'd all love the
fuctionality, it'd have you examining almost all the
"Ross J. Reedstrom" [EMAIL PROTECTED] writes:
On Mon, Nov 20, 2000 at 06:52:20PM +0200, Hannu Krosing wrote:
Dumping constraints in human-readable form (instead of CREATE CONSTRAIN
TRIGGER) would also be great.
In fact, IMHO, this would be a great place to start: we'd all love the
Thomas Lockhart [EMAIL PROTECTED] writes:
Is the original issue support for 0x10... as the smallest integer, as
opposed to -MAX_INT? As long as we continue to map the "reserved values"
to the upper and lower range of allowed values so they are unlikely to
appear under normal circumstances,
more info. It seems to not like the following from
src/include/buffer/bufpage.h (line 305):
#define PageSetLSN(page, lsn) \
(((PageHeader) (page))-pd_lsn = (XLogRecPtr) (lsn))
I'm not sure what it's trying to do...
Just assign values to 8 bytes structure in pageheader.
Did you
* Mikheev, Vadim [EMAIL PROTECTED] [001120 12:00]:
more info. It seems to not like the following from
src/include/buffer/bufpage.h (line 305):
#define PageSetLSN(page, lsn) \
(((PageHeader) (page))-pd_lsn = (XLogRecPtr) (lsn))
I'm not sure what it's trying to do...
Just
I sent this e-mail last week but hadn't received any response. Given
Thomas' last message about seeing responses to threads he never recalled
seeing in the first place, I'm wondering whether the original message
made it to the server.
-Tony
p.s. I still can't seem to get the "DIGEST" to work
* Mikheev, Vadim [EMAIL PROTECTED] [001120 13:26]:
more info. It seems to not like the following from
src/include/buffer/bufpage.h (line 305):
#define PageSetLSN(page, lsn) \
(((PageHeader) (page))-pd_lsn = (XLogRecPtr) (lsn))
I'm not sure what it's trying to
Tom Lane wrote:
Thomas Lockhart [EMAIL PROTECTED] writes:
as for the behavior of Linux distribution vendors who set RPM_OPT_FLAGS
differently from the way they built libc, well, words fail me...
Which distros would these be? I know that Mandrake chooses some mutually
exclusive flags
Jan Wieck [EMAIL PROTECTED] writes:
Just successfully loading an old-style C function doesn't
guarantee that it works anyway. I pointed out before that the
changes due to TOAST require each function that takes
arguments of varlen types to expect toasted values.
Current sources pass regress test except for
*** ./expected/opr_sanity.out Mon Nov 13 22:59:14 2000
--- ./results/opr_sanity.outMon Nov 20 17:12:50 2000
***
*** 481,489
NOT ((p2.pronargs = 2 AND p1.aggbasetype = p2.proargtypes[1]) OR
(p2.pronargs = 1 AND
Don Baccus [EMAIL PROTECTED] writes:
All went well except for a handful of occurances of the following error:
ERROR: SS_finalize_plan: plan shouldn't reference subplan's variable
Fixed, I believe. Your test case now gives
regression=# select user_group_add('group', 'shortname',
At 07:20 PM 11/20/00 -0500, Tom Lane wrote:
Don Baccus [EMAIL PROTECTED] writes:
All went well except for a handful of occurances of the following error:
ERROR: SS_finalize_plan: plan shouldn't reference subplan's variable
Fixed, I believe. Your test case now gives
regression=# select
Tom Lane wrote:
Your procedure was fine, but ALTER TABLE RENAME was mighty flaky in
pre-7.0 releases. Even in 7.0, doing it inside a transaction block is
asking for trouble (that's finally fixed for 7.1, thank goodness).
I suspect you got bit by an ALTER bug. I'm not sure about the exact
Nope. Still fails...
*** ./expected/opr_sanity.out Tue Nov 14 13:32:58 2000
--- ./results/opr_sanity.outMon Nov 20 20:27:46 2000
***
*** 482,489
(p2.pronargs = 1 AND p1.aggbasetype = 0)));
oid | aggname | oid | proname
In fact, IMHO, this would be a great place to start: we'd all love the
fuctionality, it'd have you examining almost all the same code, and it'd
be a feature we could all test, in diverse situations. DROP CONSTRAINT
is unlikely to be as widely tested. If you can build the introspection
Got the following errors when using very recent CVS build:
On client (psql):
1: psql:./indexes_1.sql:12: pqReadData() -- backend closed the channel
unexpectedly.
2: This probably means the backend terminated abnormally
3: before or while processing the request.
4:
Philip Warner [EMAIL PROTECTED] writes:
TRAP: Failed Assertion("!(((file) 0 (file) (int) SizeVfdCache
VfdCache[file].fileName != ((void *)0))):", File: "fd.c", Line: 967)
!(((file) 0 (file) (int) SizeVfdCache VfdCache[file].fileName !=
((void *)0))) (0)
Server process (pid 7187)
At 18:57 20/11/00 +0600, Denis Perchine wrote:
On 20 November 2000 18:52, Philip Warner wrote:
I get the following when doing a fresh build:
Did you made distclean?
Yep.
Config parames were:
./configure \
--prefix=/var/lib/pgsql7.1.0b \
--with-odbc \
--with-x \
"Christopher Kings-Lynne" [EMAIL PROTECTED] writes:
Just to catch up here - does this mean that pg_dump has issues with
correctly recreating the contraints?
Well, if you examine the pg_dump output, it doesn't really try ---
you'll see no sign of any foreign-key constraint declarations in
a
Missing an #include of errno.h:
cc -O -K inline -I/usr/local/include -I../../../../src/include -c -o numeric.o
numeric.c
UX:acomp: WARNING: "numeric.c", line 1953: end-of-loop code not reached
UX:acomp: WARNING: "numeric.c", line 1991: end-of-loop code not reached
UX:acomp: WARNING:
Larry Rosenman [EMAIL PROTECTED] writes:
Missing an #include of errno.h:
Ooops, sorry about that --- errno.h gets included by some other
standard header on my system, so I tend to miss that omission :-(
Will fix shortly.
regards, tom lane
Larry Rosenman [EMAIL PROTECTED] writes:
Nope. Still fails...
You should've said that the OIDs are now just off-by-one from where they
were before, instead of off by several thousand. That I'm willing to
accept as an implementation change ;-) I've updated the expected file.
Problem is that there are 5 difference types of constraints,
implemented in
5 different ways. Do you want a unifed, central catalog of
constraints, or
just for some of them, or what?
Dunno. Maybe a unified representation would make more sense, or maybe
it's OK to treat them
At 22:38 20/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
TRAP: Failed Assertion("!(((file) 0 (file) (int) SizeVfdCache
VfdCache[file].fileName != ((void *)0))):", File: "fd.c", Line: 967)
!(((file) 0 (file) (int) SizeVfdCache VfdCache[file].fileName !=
((void
"Ross J. Reedstrom" [EMAIL PROTECTED] writes:
On Mon, Nov 20, 2000 at 06:52:20PM +0200, Hannu Krosing wrote:
Dumping constraints in human-readable form (instead of CREATE CONSTRAIN
TRIGGER) would also be great.
In fact, IMHO, this would be a great place to start: we'd all love the
At 10:49 PM 11/20/00 -0500, Tom Lane wrote:
"Christopher Kings-Lynne" [EMAIL PROTECTED] writes:
Just to catch up here - does this mean that pg_dump has issues with
correctly recreating the contraints?
Well, if you examine the pg_dump output, it doesn't really try ---
you'll see no sign of any
At 12:03 AM 11/21/00 -0500, Tom Lane wrote:
Peter has remarked that the SQL spec offers a set of system views
intended to provide exactly this info. That should be looked at;
if there's a workable standard for this stuff, we oughta follow it.
This and a BUNCH else.
- Don Baccus, Portland OR
Speaking of - I simply cannot find a standard SQL specification anywhere on
the net, without buying one from ANSI. I'm forced to rely on
vendor-specific docs - which are not standard in any way. Is anyone able to
mail me such a thing?
Check the mailing list archives for the reference to a
Christopher Kings-Lynne wrote:
I like this conversation as not a day goes by where I don't wish I could
edit the dump of a database rather than keeping structure entirely
seperate -- and actually do so in a useful manner. That said, whats the
possibility of maintaining comments if the
Philip Warner [EMAIL PROTECTED] writes:
Not at all. The call is, as you point out, defining the protocl for
enquiry. Nothing more. With 7.1, the process above is sufficient. There is
no need to call *in this version* because pg_fmgr_api_version returns
enough information when combined with
Hi,
i have a problem with REFERENCES (foreign keys). i have this table:
drop table paragraph;
create table paragraph (
id int4 PRIMARY KEY,
label varchar(512),
paragraph_next int4 CONSTRAINT paragraph_fk_next REFERENCES paragraph DEFERRABLE
INITIALLY DEFERRED,
paragraph_priv int4
Tatsuo Ishii ¼g¹D¡G
For example: If we initdb -E MULE_INTERNAL first,
SET CLIENT_ENCODING TO 'BIG5', and
INSERT INTO some_table VALUES (..., 'the last byte of some Big5 char is
backslash\',...),
then we can not successfully complete this SQL INSERT -- the prompt of
At 00:22 21/11/00 -0500, Rod Taylor wrote:
Christopher Kings-Lynne wrote:
/***
* TABLE: example
*
* Used to accomplish stuff
*/
CREATE TABLE example
( example_id serial
/* Must be a ZIP or Postal Code */
, regionvarchar(6) UNIQUE
Nope. Still fails...
I know, but looks better, eh? -:)
*** ./expected/opr_sanity.out Tue Nov 14 13:32:58 2000
--- ./results/opr_sanity.out Mon Nov 20 20:27:46 2000
***
*** 482,489
(p2.pronargs = 1 AND p1.aggbasetype = 0)));
oid | aggname | oid |
Yeah, I shoulda said off by one... Tom fixed the
expected file :-)
LER
* Vadim Mikheev [EMAIL PROTECTED] [001121 00:01]:
Nope. Still fails...
I know, but looks better, eh? -:)
*** ./expected/opr_sanity.out Tue Nov 14 13:32:58 2000
--- ./results/opr_sanity.out Mon Nov 20
Larry Rosenman [EMAIL PROTECTED] writes:
Nope. Still fails...
You should've said that the OIDs are now just off-by-one from where they
were before, instead of off by several thousand. That I'm willing to
accept as an implementation change ;-) I've updated the expected file.
Actually,
CREATE TABLE example
( example_id serial
-- Must be a ZIP or Postal Code
, regionvarchar(6)
-- Descriptive text
, description varchar(60)
);
Actually - this is something I _could_ do.
As the pg_dump is running, it shouldn't be too hard to select the comment
associated
Mikheev, Vadim writes:
more info. It seems to not like the following from
src/include/buffer/bufpage.h (line 305):
#define PageSetLSN(page, lsn) \
(((PageHeader) (page))-pd_lsn = (XLogRecPtr) (lsn))
I'm not sure what it's trying to do...
Just assign values to 8 bytes
I wrote:
Mikheev, Vadim writes:
more info. It seems to not like the following from
src/include/buffer/bufpage.h (line 305):
#define PageSetLSN(page, lsn) \
(((PageHeader) (page))-pd_lsn = (XLogRecPtr) (lsn))
I'm not sure what it's trying to do...
Just assign
Peter Eisentraut [EMAIL PROTECTED] writes:
It's because XLogRecPtr is a struct. You can't assign structs with
'='. Gotta use memcpy, etc.
Struct assignment is a required feature since ANSI C, and I'm pretty
sure we use it in other places already. I doubt that's the explanation
for Larry's
more info. It seems to not like the following from
src/include/buffer/bufpage.h (line 305):
#define PageSetLSN(page, lsn) \
(((PageHeader) (page))-pd_lsn = (XLogRecPtr) (lsn))
I'm not sure what it's trying to do...
Just assign values to 8 bytes structure in
It's because XLogRecPtr is a struct. You can't assign structs with
'='. Gotta use memcpy, etc.
Correction: It's because the compiler won't let you cast to a
struct. Assigning seems to compile okay.
Oh, ok - seems we can just get rid of casting there.
Vadim
* Mikheev, Vadim [EMAIL PROTECTED] [001120 13:29]:
It's because XLogRecPtr is a struct. You can't assign structs with
'='. Gotta use memcpy, etc.
Correction: It's because the compiler won't let you cast to a
struct. Assigning seems to compile okay.
Oh, ok - seems we can just
Is it okay now to disable the old regression test drivers and make use of
the new one throughout? It would be advantageous if we all ran the same
thing in beta.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Peter Eisentraut [EMAIL PROTECTED] writes:
Is it okay now to disable the old regression test drivers and make use of
the new one throughout?
Sure. Just point 'make runtest' at the new script ...
I do have one gripe about the new script: it suppresses error messages
from the DROP DATABASE
ISTM that
SET SESSION CHARACTERISTICS AS parameter value
is really a more SQL'ish form of the current
SET parameter =/TO value
Perhaps they should be made equivalent, in order to avoid too many subtly
different subversions of the 'SET' command.
--
Peter Eisentraut [EMAIL
I was afraid you were planning to run that way. Did you absorb the
point about shared memory keys being based (only) on the port number?
Unless something's done about that, the above configuration will NOT
work, because the different instances will try to use the same
shared memory and
Still...Regardless of what database they're running, either their
abstraction layer is shit or their queries really need optimized. Is that
perhaps why, even at 5 clients, the page views he shows never went
significantly above 10/sec?
I think this could be because they used real killer
I've wondered and am still wondering what a lot of these benchmark tests
are out to prove. I'm not sure that any PostgreSQL advocate has ever said or
implied that PostgreSQL is faster than anything, much less MySQL. While I'm
sure it's faster than some, I've just never heard the argument for
At 09:43 AM 11/13/00 -0600, [EMAIL PROTECTED] wrote:
I made it all the way through the article. I'll summarize it for you:
Postgres - hooray!
MySQL - boo!
Since this is an open source database article linked off of slashdot, I
imagine they're getting pounded.
Why is all this e-mail showing up
At 10:24 AM 11/13/00 -0800, Limin Liu wrote:
This's great. I have tested Postgres and MySQL with the benchmark shipped with mysql and (of course) MySQL out perform Postgres.
So how many simultaneous read/write processes does the MySQL benchmark fire up?
Why test a benchmark provided by
63 matches
Mail list logo
