> > >>Seems like someone ought to issue a call for port reports. The
> > >>"supported platforms" list hasn't been touched ...
> > > Good point. Thomas, can you take that on?
> >
> > No, at least not now. I'm not able to communicate reliably with the
> > mailing lists, and so can not coordinate
I found a message I've never seen before in VACUUM, its:
NOTICE: Too old parent tuple found - can't continue repair_frag
The version is Postgresql 7.2.1.
The problem occurs in vacuum.c, around line 1700, but the interesting part is the
comment around:
/*
* Read above about cases when
* !ItemIdI
I said:
> Peter Bierman <[EMAIL PROTECTED]> writes:
>> Perhaps the change from gcc2.x to 3.x changed floats a bit?
> Could be. We had previous reports of the same diff on OSX 10.2 with
> a G4 processor, so I was wondering if it was hardware or software
> differences (geometry-powerpc-darwin.out m
Christopher Kings-Lynne wrote:
> Hi guys,
>
> Just got back from my European vacation - 7.3 still not out? :)
Nope, we think maybe RC1 tomorrow. I was busy the past two days and am
catching up on email just now.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROT
Hi guys,
Just got back from my European vacation - 7.3 still not out? :)
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> If the normal number of digits displayed is different between two systems,
> than displaying a fixed number less digits is still going to result in
> differences.
That is, however, not the problem we have with the geometry test.
On Thu, Oct 31, 2002 at 12:58:21 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> But I think an EXTRA_DIGITS setting might be interesting. In
> particular, suppose we allowed EXTRA_DIGITS to be negative? Setting
> it to -1 or -2 would go a long way towards eliminating our problems
> with platfo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The proposed fix was to include the flex output in some other file (such
> as the corresponding grammar file) rather than to compile it separately.
Seems like a reasonable solution. Can you make that happen in the next
day or two? If not, I'll take
"Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
>> No, the code is correct, although no doubt too clever by half :-(
> How can it be correct? If the assertion checking is turned off, then
> saveState.currBucket will not be changed, but if assertion checking is
> on, it will be set to NULL. The
On Thu, 2002-10-31 at 13:03, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Found another:
> > ERROR: cannot find attribute 2 of relation pg_temp_12100_0
>
> Can you reproduce that?
>
> It could be that this just represents someone's temp table deletion
> committing while VACUUM is
Dear Tom,
>
>
> "Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
> > gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash'
> > cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include
>-I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c
What version of postgres are you using? I am using PostgreSQL 7.3b1 on
i686-pc-linux-gnu, compiled by GCC 2.96 and when I execute the following
statement:
select '{124,567,66}'::int[] + 345;
I get the error:
ERROR: cache lookup failed for type 0
Any ideas?
Thanks for your help!
-r
---
I sent an email before receiving the one below. I am happier also with
the extra_digits way (from the previous email I thought the options were
DBL_DIG or DBL_DIG+2).
I'm not happy with adding the hex-output option, since it's not
very portable and doesn't seem necessary to solve the problem any
Rod Taylor <[EMAIL PROTECTED]> writes:
> Found another:
> ERROR: cannot find attribute 2 of relation pg_temp_12100_0
Can you reproduce that?
It could be that this just represents someone's temp table deletion
committing while VACUUM is partway through trying to build a relcache
entry to open the
Tom Lane wrote:
Bottom line: if DBL_DIG=15 and the float arithmetic is binary, then
there are some double values that require 17 displayed digits to
distinguish, even though not all 16-digit numbers are distinct.
So I retract my original proposal and instead suggest that we offer
a switch to dis
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
> Have two parameters, say DOUBLE_OUTPUT and EXTRA_DIGITS. DOUBLE_OUTPUT
> would select from decimal output or normalized output. EXTRA_DIGITS
> would add the required extra digits, from 0 (default) to 3, when output
> is decimal.
I'm not happy w
Found another:
ERROR: cannot find attribute 2 of relation pg_temp_12100_0
On Thu, 2002-10-31 at 11:33, scott.marlowe wrote:
> On Thu, 31 Oct 2002, Tom Lane wrote:
>
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > Ok, fair enough -- I agree that we should treat the two cases
> > > differently.
Tom Lane wrote:
Barry Lind <[EMAIL PROTECTED]> writes:
In either case I am concerned about licensing issues. gcj is not under
a BSD style license. Depending on what you need you are either dealing
with regular GPL, LGPL, or LGPL with a special java exception.
I beleive (without giving it t
Tom Lane wrote:
I was misremembering these papers to claim DBL_DIG+1 is enough, but
actually they prove that DBL_DIG+2 is necessary and sufficient (and
give code to do it correctly, too).
Yeahh! If there's a proof its safe to implement.
I also Googled a bit and found another paper saying that 1
On Thu, Oct 31, 2002 at 11:15:31 -0500,
Rod Taylor <[EMAIL PROTECTED]> wrote:
>
> Yes, default expressions and check constraints could possibly. However,
> both revoke complex expressions (no sub-selects, etc) so there is little
> point.
I disagree. They can call functions which can do unexpec
"Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
> gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash'
> cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include
>-I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c -o
>dynahash.o
> cc-
Alessio Bragadini <[EMAIL PROTECTED]> writes:
>> Folks. start sending in those plaform reports, OS name and version
>> number please.
> DOESN'T WORK on Digital Unix/Tru64 4.0g, with both cc or gcc compiler.
Evidently main.c needs "#include " added. Please add that and
see if you get any further.
I am thinking it would be useful for debugging if elog(PANIC) were to
exit by calling abort() so that a core dump would be produced.
Going out via proc_exit(), as it now does, seems like a bad idea in any
case, since that will try to do a bunch of cleanup activity that's
probably inappropriate aft
On Thu, 31 Oct 2002, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Ok, fair enough -- I agree that we should treat the two cases
> > differently. But one thing I think we should do in any case is improve
> > the wording of the error message.
>
> Got a suggestion?
Change: Relatio
On Thu, 2002-10-31 at 10:33, Bruno Wolff III wrote:
> On Thu, Oct 31, 2002 at 10:17:26 -0500,
> Rod Taylor <[EMAIL PROTECTED]> wrote:
> > Can't necessarily run them as the table owner, as it may give
> > information to other users with the ability to ALTER that table.
>
> You have to be the tabl
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
> Its like I said before, the guys from matlab (in x86 IEEE float) go to
> DBL_BIG+3 to have 'maximum precision'.
Apparently they have not read the canonical papers in the field.
[ googles for a moment... ] See
How to read floating point numbers
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
> Zeugswetter Andreas SB SD wrote:
>> Unfortunately %A is not portable :-(
> What do you mean ?
Just what he said.
> It is C99, introduced in glibc 2.1.
> What are the requirements for PostgreSQL ?
glibc does not define the universe; nor are all
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 30 Oct 2002, Tom Lane wrote:
>> sprintf(ascii, "%.*g", DBL_DIG+1, num);
>> and similarly for float4. Given carefully written float I/O routines,
>> reading the latter output should reproduce the originally stored value.
> Well, on my system, it
I've built and run the regression tests on PostgreSQL7.3 beta 2 on
SGI Irix and found the following suspicious compiler error message:
gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash'
cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include
-I/stf/sys64/include
On Thu, Oct 31, 2002 at 10:17:26 -0500,
Rod Taylor <[EMAIL PROTECTED]> wrote:
> Can't necessarily run them as the table owner, as it may give
> information to other users with the ability to ALTER that table.
You have to be the table owner to alter a table. So it should be OK
to have the default
On Thu, 2002-10-31 at 09:54, Bruno Wolff III wrote:
> Constraints also run as the user modifying a table instead of the table
> owner.
> Again I don't see a good reason to want to execute constraints as the
> user modifying a table. But I do think there can be reasons to want to
> execute them as t
Zeugswetter Andreas SB SD wrote:
Yes agree (or double_significant_digits or format_double_digits ?),
but default to DBL_DIG and allow range between 1 and DBL_DIG + 3.
format_* could be used for all future output format tweaks.
Unfortunately %A is not portable :-(
What do you mean ?
It is C99,
Constraints also run as the user modifying a table instead of the table
owner.
Again I don't see a good reason to want to execute constraints as the
user modifying a table. But I do think there can be reasons to want to
execute them as the table owner.
To summarize, my suggestion for change is:
E
> Maybe it makes sense that in the proposal below the parameter
> EXTRA_DIGITS could be SIGNIFICANT_DIGITS with a default value
> of 15 and maximum 18.
> Its more 'documentable' and maybe easy to understand in general.
Yes agree (or double_significant_digits or format_double_digits ?),
but def
Just one more note,
Maybe it makes sense that in the proposal below the parameter
EXTRA_DIGITS could be SIGNIFICANT_DIGITS with a default value of 15 and
maximum 18.
Its more 'documentable' and maybe easy to understand in general.
Pedro M. Ferreira wrote:
Yes. I think there are several option
Tom Lane wrote:
My recollection is that other people (perhaps Peter?) were the ones
objecting before. However I'd be somewhat unhappy with the proposal
as given:
Option 'SHORT' would be default and produce the standard sprintf(ascii,...
Option 'LONG' would produce sprintf(ascii, "%25.18g", num
> Folks. start sending in those plaform reports, OS name and version
> number please.
DOESN'T WORK on Digital Unix/Tru64 4.0g, with both cc or gcc compiler.
Using Compaq C V6.4-216 (dtk) on Digital UNIX V4.0G (Rev. 1530)
Compiler Driver V6.4-013 (dtk) cc Driver:
make[3]: Entering directory
`/usr
37 matches
Mail list logo
