Hi
I've been running RC3 regression tests, starting with a FreeBSD 4.2-STABLE
and a Solaris 7 Sparc box. Both tests ran without any problems. I tried
Solaris 8 Sparc next: it still suffered from the same unix socket problems.
I had a look at the code and it seems to me that the use of unix socket
Giles Lean <[EMAIL PROTECTED]> writes:
> I'm not sure how interesting these differences are anymore -- is there
> anyone familiar enough with floating point to determine if the results
> are acceptable (although currently unexpected :-) or not?
Differences in the last couple of decimal places in
> 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
[ BCC to admin]
I have completed my PostgreSQL session monitor utility, pgmonitor. I
have recently added the ability to start/stop the postmaster.
I considered adding the ability to set postmaster/postgres command
flags, but decided they are not changed frequently enough.
It still does not wor
> > Can you use ps2pdf to generate PDF? It is a utility that comes with
> > ghostscript. I know versions >= 6.0 are fine.
>
> PDF files generated from postscript with Adobe Acrobat are usually of
> much higher quality than those generated by ghostscript. It seems that
> ghostscript encodes rend
I have no idea if what I say is true about the PG distribution by PG people, but
I have noticed than in the rpms of other distros the postgresql-devel rpms do not
include all the .h files necessary to build PG extensions. For instance the
rtree.h and itup.h and gist.h headers are missing. Could yo
On Fri, Apr 06, 2001 at 09:23:35PM -0400, Bruce Momjian allegedly wrote:
> > > Thomas, will you be doing .pdf files? I have had requests to put that
> > > in the Debian documentation package.
> >
> > afaik, I don't have the means to generate pdf directly. Pointers would
> > be appreciated, if the
On Fri, 6 Apr 2001, Bruce Momjian wrote:
> > > That strikes me as an awfully web-centric view of things. Not everyone
> > > has an always-on high-speed Internet link.
> > >
> > > If you want to make the docs and TODO.detail be a separate chunk of the
> > > split distribution, that's fine with me
> > That strikes me as an awfully web-centric view of things. Not everyone
> > has an always-on high-speed Internet link.
> >
> > If you want to make the docs and TODO.detail be a separate chunk of the
> > split distribution, that's fine with me. But I don't agree with
> > removing them from the
> > Thomas, will you be doing .pdf files? I have had requests to put that
> > in the Debian documentation package.
>
> afaik, I don't have the means to generate pdf directly. Pointers would
> be appreciated, if there are mechanisms available on Linux boxes.
>
> We have had lots of offers of hel
> Thomas, will you be doing .pdf files? I have had requests to put that
> in the Debian documentation package.
afaik, I don't have the means to generate pdf directly. Pointers would
be appreciated, if there are mechanisms available on Linux boxes.
We have had lots of offers of help for these co
> > OTOH, if Marc was only thinking of removing the pre-built docs from the
> > tarball, I don't object to that. I'm not sure why those weren't
> > distributed as separate tarballs from the get-go. I just say that the
> > doc sources are part of the source distribution...
>From the get-go, the
On Fri, 6 Apr 2001, Tom Lane wrote:
> >> At 2Meg, is there a reason why we include any of the docs as part of the
> >> standard tar ball? It shouldn't be required to compile, so should be able
> >> to be left out of the main tar ball and downloaded seperately as required
> >> .. thereby shrinkin
>> At 2Meg, is there a reason why we include any of the docs as part of the
>> standard tar ball? It shouldn't be required to compile, so should be able
>> to be left out of the main tar ball and downloaded seperately as required
>> .. thereby shrinking the distribution to <6Meg from its current
> > Can we drop TODO.detail from the tarball too? No need to include that,
> > I think. The web site has nice links to it now. Uncompressed it is
> > 1.314 megs.
>
> That strikes me as an awfully web-centric view of things. Not everyone
> has an always-on high-speed Internet link.
>
> If you
On Fri, 6 Apr 2001, Bruce Momjian wrote:
> > On Fri, 6 Apr 2001, Thomas Lockhart wrote:
> >
> > > > > The docs are ready for shipment.
> > > > Even better ...
> > > > Okay, let's let this sit as RC3 for the next week...
> > >
> > > I'll go ahead and start generating hardcopy, though I understand
Thomas Lockhart wrote:
>> > The docs are ready for shipment.
>> Even better ...
>> Okay, let's let this sit as RC3 for the next week...
>
>I'll go ahead and start generating hardcopy, though I understand that it
>is no longer allowed into the shipping tarball :(
>
>Lamar, do you pl
> On Fri, 6 Apr 2001, Thomas Lockhart wrote:
>
> > > > The docs are ready for shipment.
> > > Even better ...
> > > Okay, let's let this sit as RC3 for the next week...
> >
> > I'll go ahead and start generating hardcopy, though I understand that it
> > is no longer allowed into the shipping tarb
On Fri, 6 Apr 2001, The Hermit Hacker wrote:
> On Fri, 6 Apr 2001, Thomas Lockhart wrote:
>
> > > > The docs are ready for shipment.
> > > Even better ...
> > > Okay, let's let this sit as RC3 for the next week...
> >
> > I'll go ahead and start generating hardcopy, though I understand that it
>
On Fri, 6 Apr 2001, Thomas Lockhart wrote:
> > > The docs are ready for shipment.
> > Even better ...
> > Okay, let's let this sit as RC3 for the next week...
>
> I'll go ahead and start generating hardcopy, though I understand that it
> is no longer allowed into the shipping tarball :(
At 2Meg,
Thomas Lockhart wrote:
> I'll go ahead and start generating hardcopy, though I understand that it
> is no longer allowed into the shipping tarball :(
> Lamar, do you plan to continue to package the hardcopy somewhere in the
> RPMs? If so, I'll have them ready soon.
I didn't for 7.0, IIRC. Or m
> On Fri, 6 Apr 2001, The Hermit Hacker wrote:
>
> >
> > For those that want to get in before the rush, I'm going to do an announce
> > this evenin to -general and -announce ...
> >
> > Vince, can you make appropriate changes to the WebSite as far as linking
> > to it is concerned, so that the mi
> > The docs are ready for shipment.
> Even better ...
> Okay, let's let this sit as RC3 for the next week...
I'll go ahead and start generating hardcopy, though I understand that it
is no longer allowed into the shipping tarball :(
Lamar, do you plan to continue to package the hardcopy somewher
> If somethings happen this weekend, I *MAY* have a HP9000/433s (M68K)
> running NetBSD to play with
That would be great. I *know* that there are some m68k machines around
somewhere on this planet, and it would be a shame to not have NetBSD
tested for the release...
-
On Fri, 6 Apr 2001, Tom Lane wrote:
> On closer look, I'll bet that "brandon" and "postgres" have the
> same usesysid assigned in pg_shadow. Need to change one of them.
That was it - both were 501.
Thanks.
--
Dominic J. Eidson
"Baruk Khazad! Khazad ai
Vacuuming pg_database should make the bogus entries go away ...
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
"Dominic J. Eidson" <[EMAIL PROTECTED]> writes:
>> postgres | brandon <-- Incorrect
>> postgres | postgres
>> smc_is_neteng | dominic
>> template1 | brandon <-- Incorrect
>> template1 | postgres
>> wwwrun| brandon <-- Incorrect
>> wwwrun| postgres
>
On Fri, 6 Apr 2001, The Hermit Hacker wrote:
> On Fri, 6 Apr 2001, Vince Vielhaber wrote:
>
> > On Fri, 6 Apr 2001, The Hermit Hacker wrote:
> >
> > > On Fri, 6 Apr 2001, Peter Eisentraut wrote:
> > >
> > > > The Hermit Hacker writes:
> > > >
> > > > > baring any major blow ups, the only thing we
Matthew <[EMAIL PROTECTED]> writes:
> -- dumping out user-defined functions
> failed sanity check, type with oid 101993741 was not found
Looks like you have a function that refers to a since-deleted type.
You'll need to find and drop the function (which may mean manually
deleting its pg_proc ro
I just love to reply to myself..
On Fri, 6 Apr 2001, Dominic J. Eidson wrote:
[Snip]
> postgres | brandon <-- Incorrect
> postgres | postgres
> smc_is_neteng | dominic
> template1 | brandon <-- Incorrect
> template1 | postgres
> wwwrun| brandon <-
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Something to remember: currently we update t_infomask (set
> HEAP_XMAX_COMMITTED etc) while holding share lock on buffer -
> we have to change this before block CRC implementation.
Yeah, we'd lose some concurrency there.
rega
dominic=# \l
List of databases
Database| Owner
---+--
aleal | aleal
arivera | arivera
bbeyer| bbeyer
brandon | brandon
brandon | postgres
dominic | dominic
ds3 | agould
keystone | dominic
kperoni
On Fri, 6 Apr 2001, Vince Vielhaber wrote:
> On Fri, 6 Apr 2001, The Hermit Hacker wrote:
>
> > On Fri, 6 Apr 2001, Peter Eisentraut wrote:
> >
> > > The Hermit Hacker writes:
> > >
> > > > baring any major blow ups, the only thing we are waiting on is docs ...
> > >
> > > The docs are ready for
On Fri, 6 Apr 2001, The Hermit Hacker wrote:
> On Fri, 6 Apr 2001, Peter Eisentraut wrote:
>
> > The Hermit Hacker writes:
> >
> > > baring any major blow ups, the only thing we are waiting on is docs ...
> >
> > The docs are ready for shipment.
>
> Even better ...
>
> Okay, let's let this sit as
On Fri, 6 Apr 2001, Peter Eisentraut wrote:
> The Hermit Hacker writes:
>
> > baring any major blow ups, the only thing we are waiting on is docs ...
>
> The docs are ready for shipment.
Even better ...
Okay, let's let this sit as RC3 for the next week, as soon as someone
makes a change, I'll d
The Hermit Hacker writes:
> baring any major blow ups, the only thing we are waiting on is docs ...
The docs are ready for shipment.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 6: Have yo
> To be perfectly clear: I have actually seen bug reports trace to
> problems that I think a block-level CRC might have detected (not
> corrected, of course, but at least the user might have realized he had
> flaky hardware a little sooner). So I do not say that the upside to
> a block CRC is nil
On Fri, 6 Apr 2001, Vince Vielhaber wrote:
> On Fri, 6 Apr 2001, The Hermit Hacker wrote:
>
> >
> > For those that want to get in before the rush, I'm going to do an announce
> > this evenin to -general and -announce ...
> >
> > Vince, can you make appropriate changes to the WebSite as far as lin
On Fri, 6 Apr 2001, The Hermit Hacker wrote:
>
> For those that want to get in before the rush, I'm going to do an announce
> this evenin to -general and -announce ...
>
> Vince, can you make appropriate changes to the WebSite as far as linking
> to it is concerned, so that the mirrors pick up th
> FWIW, I confirm that horology-no-DST-before-1970 is good; it passes on
> HPUX. Can anyone confirm horology-solaris-1947?
How to test it? All default tests are Ok on my Solaris.
Vadim
---(end of broadcast)---
TIP 1: subscribe and unsubscribe com
Tom Lane wrote:
>
> It looks like you wrapped the intermediate (broken) state of
> interfaces/odbc/convert.c that Hiroshi had in there for a few hours.
> Dunno if this is important enough to re-wrap RC3 for; it might affect
> a few ODBC users ...
Just as I was getting ready to upload a quickie R
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> FWIW, I confirm that horology-no-DST-before-1970 is good; it passes on
>> HPUX. Can anyone confirm horology-solaris-1947?
> How to test it? All default tests are Ok on my Solaris.
If the horology test shows as passing, then we're set.
It looks like you wrapped the intermediate (broken) state of
interfaces/odbc/convert.c that Hiroshi had in there for a few hours.
Dunno if this is important enough to re-wrap RC3 for; it might affect
a few ODBC users ...
regards, tom lane
---(end o
My nightly dump of one of my databases started failing Wednesday night and
I'm not sure what is going on. When I pg_dump this one database (others on
this machine are fine) I get this output from pg_dump
-- last builtin oid is 17216
-- reading user-defined types
-- reading user-defined func
Ack...
All my current history keeping methods are done via triggers on tables
(generally set off by various RI_ triggers). Not real good if it
didn't set off those triggers for me.
I'm sure rules are a ditto in that case for others.
I was hoping for a way to prevent the RI trigger from failing
On Thu, Apr 05, 2001 at 07:16:49PM -0400, Rod Taylor wrote:
> CREATE TABLE junk (
> col SERIAL PRIMARY KEY
> );
>
> INSERT INTO junk (col) DEFAULT VALUES;
>
> INSERT INTO junk DEFAULT VALUES:
>
>
> Second insert works, first one fails.
>
> INSERT INTO table [ ( column [, ...] ) ]
> { DE
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> I must apologize, I was copying from one screen to another due to
> network outage and gave a bad example -- missed the most important
> part.
> There should have been an AS ON DELETE TO junk DO INSTEAD NOTHING;
> rule.
Ah so. With that in place, I see
create table junk (col SERIAL);
INSERT INTO junk (col) VALUES (DEFAULT);
ERROR: parser: parse error at or near "DEFAULT";
> INSERT INTO junk (col) VALUES (DEFAULT);
>
> Does that work for you?
>
> Ross
>
---(end of broadcast)---
TIP 2: you
For those that want to get in before the rush, I'm going to do an announce
this evenin to -general and -announce ...
Vince, can you make appropriate changes to the WebSite as far as linking
to it is concerned, so that the mirrors pick up the new links also?
Thanks ..
Marc G. Fournier
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Try using int2()/int4()/int8() instead of integer().
>> Why is that NOT documented under "Matematical functions"?
> Because we haven't received any patches to document it? ;)
Or because it's not a mathematical function. I don't think that
datatype c
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> INSERT INTO table [ ( column [, ...] ) ]
> { DEFAULT VALUES | VALUES ( expression [, ...] ) | SELECT query }
The documentation is wrong here, not the code. SQL92 defines the syntax
as
::=
INSERT INTO
::=
[]
| DEFAULT VAL
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Not quite as expected. I didn't expect deleting the 2 from the
> primary table to fail because the CASCADE DELETE wasn't able to run on
> the second (even though no values existed in that table).
But it *doesn't* fail. At least not in the versions I tr
> > > integer (float_expression) or int (float_expression) DO work on
> > RedHat6.2/PostgreSQL6.5 and DO NOT work on Mandrake/PostgreSQL7.0.2
> > Try using int2()/int4()/int8() instead of integer().
> Why is that NOT documented under "Matematical functions"?
Because we haven't received any patche
Not quite as expected. I didn't expect deleting the 2 from the
primary table to fail because the CASCADE DELETE wasn't able to run on
the second (even though no values existed in that table). I suppose
it does run properly (blocks all delete attempts) -- but I just didn't
expect it to error out
CREATE TABLE junk (
col SERIAL PRIMARY KEY
);
INSERT INTO junk (col) DEFAULT VALUES;
INSERT INTO junk DEFAULT VALUES:
Second insert works, first one fails.
INSERT INTO table [ ( column [, ...] ) ]
{ DEFAULT VALUES | VALUES ( expression [, ...] ) | SELECT query }
The column list should
> If we're in the business of expending cycles to guard against
> nil-probability risks, let's checksum our executables every time we
> start up, to make sure they're not overwritten. Actually, we'd
better
> re-checksum program text memory every few seconds, in case RAM
dropped
> a bit since we l
Found the issue. Try out the included SQL.
I had honestly expected the second delete to work properly as nothing
had to be removed that table.
The rule was added as a temporary measure to protect the data
currently in the table -- without the intent of otherwise impeding the
other information's
Einar Karttunen wrote:
>
> >
> > integer (float_expression) or int (float_expression) DO work on
> RedHat6.2/PostgreSQL6.5 and DO NOT work on Mandrake/PostgreSQL7.0.2
> Try using int2()/int4()/int8() instead of integer(). The intn()
functions
> convert the float to a integer n bytes long, in n
59 matches
Mail list logo
