Bruce Momjian writes:
> Tom Lane wrote:
>> Done ... let me know whether the back branches still pass regression
>> for you ;-)
> I checked back to 7.3 and everything passed. I did a cvs update,
> configure, gmake, and regression run for each branch.
[ digs a bit deeper... ] Actually, it appears
Tom Lane wrote:
> I wrote:
> > Hm. One of the main problems I found was incorrect results for
> > LONGLONG_MIN (-2^63). I'm rather tempted to add a test case for
> > that to the int8 regression test and see if any platforms fail ;-)
>
> Done ... let me know whether the back branches still pass r
I wrote:
> Hm. One of the main problems I found was incorrect results for
> LONGLONG_MIN (-2^63). I'm rather tempted to add a test case for
> that to the int8 regression test and see if any platforms fail ;-)
Done ... let me know whether the back branches still pass regression
for you ;-)
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, snprintf.c fixed. I added a 'stream' and outlen parameter to all
> > the calls, and cleaned up the switch() statement that was outputing
> > twice. When we were outputing just to a string, it didn't matter, but
> > now that we are also outputting t
Bruce Momjian writes:
> Tom Lane wrote:
>> The problems are sufficiently bad that it might be a good idea to
>> backport the fixes into 8.0 and before as well --- but I note that
>> the ABI is different (pg_snprintf vs snprintf, etc) so this requires
>> a bit of investigation rather than just comm
Bruce Momjian writes:
> OK, snprintf.c fixed. I added a 'stream' and outlen parameter to all
> the calls, and cleaned up the switch() statement that was outputing
> twice. When we were outputing just to a string, it didn't matter, but
> now that we are also outputting to a stream, it does.
I fo
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I think it'd be a lot cleaner with the struct. Mind if I take another
> >> pass at it?
>
> > OK, you want my patch or want me to apply and then you can modify?
>
> You sent out your patch already --- I've been working from that.
Bruce Momjian writes:
> Tom Lane wrote:
>> I think it'd be a lot cleaner with the struct. Mind if I take another
>> pass at it?
> OK, you want my patch or want me to apply and then you can modify?
You sent out your patch already --- I've been working from that.
regards,
Tom Lane wrote:
> Bruce Momjian writes:
> > (I could have done the struct but that seemed too invasive.)
>
> I think it'd be a lot cleaner with the struct. Mind if I take another
> pass at it?
OK, you want my patch or want me to apply and then you can modify?
--
Bruce Momjian
Bruce Momjian writes:
> (I could have done the struct but that seemed too invasive.)
I think it'd be a lot cleaner with the struct. Mind if I take another
pass at it?
regards, tom lane
---(end of broadcast)---
TIP 4: Have
Tom Lane wrote:
> Bruce Momjian writes:
> > Yep, I am digging through snprintf.c now to try find a solution.
>
> The cleanest solution is probably to fix things so that dopr_outch is
> aware of whether it's working for sprintf or fprintf, and can dump the
> buffer directly to the file when it get
Bruce Momjian writes:
> Yep, I am digging through snprintf.c now to try find a solution.
The cleanest solution is probably to fix things so that dopr_outch is
aware of whether it's working for sprintf or fprintf, and can dump the
buffer directly to the file when it gets full in the fprintf case.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> So this is a psql bug?
Not here. Do you see it?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Bruce Momjian writes:
> Tom Lane wrote:
>> Doh. OK, we gotta fix it then. But what are you going to do when you
>> can't malloc enough memory? You can't ereport in a client environment,
>> and there's no API for printf to report failure.
> Yep, I am digging through snprintf.c now to try find a
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> That would only affect a standalone backend, however, not normal
> >> operation.
>
> > Ah, psql itself is using the same buggy snprintf.c.
>
> Doh. OK, we gotta fix it then. But what are you going to do when you
> can't malloc en
Bruce Momjian writes:
> Tom Lane wrote:
>> That would only affect a standalone backend, however, not normal
>> operation.
> Ah, psql itself is using the same buggy snprintf.c.
Doh. OK, we gotta fix it then. But what are you going to do when you
can't malloc enough memory? You can't ereport in
Bruce Momjian wrote:
> > If you run the query that fails in a standalone backend, do you get
> > something like "(typeid = 1700, len = -1, typmod = -1, byval = f)"
> > at the end of the line, or is that part truncated too?
>
> I found the cause. I traced into printf then realized I was not in lib
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Uh, how is control getting to snprintf? I don't see that used either
> >> in numeric.c or in printtup.c.
>
> > I am seeing it in the standalone backend here:
>
> > debugtup (slot=0x856e0b0, self=0x84306d0) at printtup.c:548
>
Bruce Momjian writes:
> Tom Lane wrote:
>> Uh, how is control getting to snprintf? I don't see that used either
>> in numeric.c or in printtup.c.
> I am seeing it in the standalone backend here:
> debugtup (slot=0x856e0b0, self=0x84306d0) at printtup.c:548
> 548
Tom Lane wrote:
> Bruce Momjian writes:
> > I found the cause. I traced into printf then realized I was not in libc
> > but port/snprintf.c, and I see 4096 defined for those buffers.
>
> Uh, how is control getting to snprintf? I don't see that used either
> in numeric.c or in printtup.c.
I am
Bruce Momjian writes:
> I found the cause. I traced into printf then realized I was not in libc
> but port/snprintf.c, and I see 4096 defined for those buffers.
Uh, how is control getting to snprintf? I don't see that used either
in numeric.c or in printtup.c.
regards,
Michael Fuhr wrote:
> On Fri, Dec 02, 2005 at 04:30:54PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Wow, check this out:
> > > test=> SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)
> > > It works fine! I have all the digits, and the trailing 1.0:
> > > 01.
>
On Fri, Dec 02, 2005 at 04:30:54PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Wow, check this out:
> > test=> SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)
> > It works fine! I have all the digits, and the trailing 1.0:
> > 01.
> > while SELECT pow(10::nume
Bruce Momjian writes:
> Wow, check this out:
> test=> SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)
> It works fine! I have all the digits, and the trailing 1.0:
> 01.
> while SELECT pow(10::numeric, 1) fails.
That's just about as wacky as can be, because
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> If that gives the right answer then the NUMERIC code is off the hook,
> >> and what you've got is a strange limitation on output column length.
>
> > test=> select length((pow(10::numeric, 131071))::text);
> > length
> >
Bruce Momjian writes:
> Tom Lane wrote:
>> If that gives the right answer then the NUMERIC code is off the hook,
>> and what you've got is a strange limitation on output column length.
> test=> select length((pow(10::numeric, 131071))::text);
>length
>
>131089
Simon Riggs wrote:
> On Fri, 2005-12-02 at 14:09 -0500, Bruce Momjian wrote:
>
> > I ran your SELECT pow(10::numeric, 131071), and gain, 4096 0's are
> > displayed on my screen. SELECT pow(10::numeric, 7000) and SELECT
> > pow(10::numeric, 1) generate identical displays on my screen.
>
> Are
On Fri, 2005-12-02 at 14:09 -0500, Bruce Momjian wrote:
> I ran your SELECT pow(10::numeric, 131071), and gain, 4096 0's are
> displayed on my screen. SELECT pow(10::numeric, 7000) and SELECT
> pow(10::numeric, 1) generate identical displays on my screen.
Are you saying there is a bug with o
Tom Lane wrote:
> Bruce Momjian writes:
> > I just tested from a standalone backend:
> > backend> select pow(10::numeric, 131071) + 1
> > and got 4095 zeros and no trailing '1' (wrong), so it isn't psql, it
> > must be something in the backend.
>
> If the backend is truncating the result leng
Bruce Momjian writes:
> I just tested from a standalone backend:
> backend> select pow(10::numeric, 131071) + 1
> and got 4095 zeros and no trailing '1' (wrong), so it isn't psql, it
> must be something in the backend.
If the backend is truncating the result length, I don't see why psql
wou
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Actually, no. If I cut'n paste the number from psql to
> > > cat > foo
> > >
> > > then only 4096 chars are copied. (Amusingly, I can't add a newline to
> > > ^D and close the file. I must delete one c
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Actually, no. If I cut'n paste the number from psql to
> > cat > foo
> >
> > then only 4096 chars are copied. (Amusingly, I can't add a newline to
> > ^D and close the file. I must delete one char to do that.)
>
> Hmm, cut buffe
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Actually, no. If I cut'n paste the number from psql to
> cat > foo
>
> then only 4096 chars are copied. (Amusingly, I can't add a newline to
> ^D and close the file. I must delete one char to do that.)
Hmm, cut buffer limitation in X or someplace?
Please try Tom's \g test:
test=> select factorial(4000)
test-> \g /tmp/x
test=> \q
$ wc -c /tmp/x
20881 /tmp/x
Do you see a number greater than 20881, something like 3?
---
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So this is a psql bug?
>
> Not here. Do you see it?
Actually, no. If I cut'n paste the number from psql to
cat > foo
then only 4096 chars are copied. (Amusingly, I can't add a newline to
^D and close the file. I must delete
Bruce Momjian wrote:
> I tried your \g test and the file size difference is the length of the
> dashed line in the file, not the number of digits display, which are
> both 4096. One has 12550 dashes, the other 19950 dashes.
So this is a psql bug? I can count the correct number of chars with
SPI
Bruce Momjian writes:
> Both are 4096 characters.
You forgot the part that scrolled off the screen. Or else your
installation is broken.
I get this for factorial(4000)
18288019515140650133147431755739190442173777107304392197064526954208959797973177364850370286870484107336443041569285571754672
Uh, I tried factorial(4000) and for display I got:
182880195151406501331474317557391904421737771073043921970645269542089597979731773648503702868704841073364430415692855717546724618615435573339426156179569967167452848315973174988187609374828049804195765129487206105589281297880978006205934
Bruce Momjian writes:
> Sorry, I am confused. If our computational range is that high, why does
> SELECT factorial(4000) and SELECT factorial(6000) produce the same
> number of digits on my screen.
Are you counting correctly?
regression=# select log(factorial(4000));
log
-
Tom Lane wrote:
> Bruce Momjian writes:
> > I am confused by your use of the term "dynamic" range. From what you
> > say above that we are just moving from 1000 to 508 for storage, and that
> > computational range would still be 4096?
>
> No, computational range would still be on the order of 10
Bruce Momjian writes:
> I am confused by your use of the term "dynamic" range. From what you
> say above that we are just moving from 1000 to 508 for storage, and that
> computational range would still be 4096?
No, computational range would still be on the order of 10^16G ... in the
computationa
Tom Lane wrote:
> Bruce Momjian writes:
> > So we are really decreasing the specified precision from 1000 to 508,
> > and the computational precision from 4096 to 508.
>
> The internal computational precision isn't any less, the limit is only
> on the result of a function (ie, partial results wit
Bruce Momjian writes:
> So we are really decreasing the specified precision from 1000 to 508,
> and the computational precision from 4096 to 508.
The internal computational precision isn't any less, the limit is only
on the result of a function (ie, partial results within one of the
numeric.c rou
Bruce Momjian wrote:
> OK, seems all objections have been dealt with so it goes into the patch
> queue. I will ask on 'general'.
>
> The only downside I see is that I can't impress people by doing:
>
> SELECT factorial(4000);
>
> I don't suppose the _impression_ factor is worth two bytes
Simon Riggs wrote:
>
> Now we're into 8.2devel mode, its time to submit the previously
> discussed patch that:
>
> - reduces Numeric storage format by 2 bytes
> - limits scale to +/- 508 decimal places
>
> This is sufficient to allow Numeric to continue to be used as the
> default numeric repres
On Thu, 2005-12-01 at 23:34 -0500, Bruce Momjian wrote:
> Where are we on this patch? It is ready for the patch queue?
It's good to be applied, AFAIK.
> Simon Riggs wrote:
> > As previously agreed, reviewing this is a 2 stage process:
> > 1. review/possibly agree OK to commit
> > 2. check with e
Where are we on this patch? It is ready for the patch queue?
---
Simon Riggs wrote:
>
> Now we're into 8.2devel mode, its time to submit the previously
> discussed patch that:
>
> - reduces Numeric storage format by 2 byt
Bruce Momjian wrote:
Let's go ahead and apply the patch. While this change isn't very
significant, I bet there will be other changes in 8.2 where we will want
to change the database for a significant benefit, like reducing the
tuple header by 4 bytes by recompressing the four xid/cid fields
Andreas Pflug wrote:
> Alvaro Herrera wrote:
> >
> > Is anybody working or considering to work on pg_upgrade, or is all this
> > hypothetical? Our past history has seen lots of people offering to work
> > on pg_upgrade, and none has produced a working version. Is it fair or
> > useful to impose
Alvaro Herrera wrote:
Is anybody working or considering to work on pg_upgrade, or is all this
hypothetical? Our past history has seen lots of people offering to work
on pg_upgrade, and none has produced a working version. Is it fair or
useful to impose restrictions on development just because
Andreas Pflug wrote:
> Tom Lane wrote:
> >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> >>However, I don't think we can promise never to change the ondisk
> >>representation of data, nor the page layout. Sometimes an inplace
> >>upgrade just won't work, ISTM.
> >
> >We have talked about batchi
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
However, I don't think we can promise never to change the ondisk
representation of data, nor the page layout. Sometimes an inplace
upgrade just won't work, ISTM.
We have talked about batching on-disk changes so that they'd only occu
They're not exactly easy to setup for the casual user (well, I assume
replicator isn't but it's not relevant to the majority of our users
anyway).
Well FYI any half way competent person can set up replicator in 30
minutes or less ;), that said
in place upgrades are a feature that will take u
Simon Riggs <[EMAIL PROTECTED]> writes:
> If the patch is accepted technically, in can be applied at any time,
> right up to code freeze for this or the next release. It's a fairly
> independent patch.
> I'd suggest we check it out now, then put it in a holding pen for awhile
> to see if an upgrad
On Thu, 2005-11-17 at 11:20 -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > However, I don't think we can promise never to change the ondisk
> > representation of data, nor the page layout. Sometimes an inplace
> > upgrade just won't work, ISTM.
>
> We have talked about b
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> However, I don't think we can promise never to change the ondisk
> representation of data, nor the page layout. Sometimes an inplace
> upgrade just won't work, ISTM.
We have talked about batching on-disk changes so that they'd only occur
once every fe
Joshua D. Drake wrote:
With Slony and Replicator I don't really see the need for in place
upgrades.
Maintaining a replica is hardly a cost-free exercise.
However, I don't think we can promise never to change the ondisk
representation of data, nor the page layout. Sometimes an inplace
up
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Joshua D. Drake
> Sent: 17 November 2005 15:58
> To: Andreas Pflug
> Cc: Tom Lane; Simon Riggs; pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] Numeric 508 datatype
Hm, so if this patch is applied now, and in 5 months or so somebody
implements pg_upgrade, this numeric storage patch would be rolled back?
OTOH, an upgrade mechanism that's compatible for future 8.3+ versions
only seems not too attractive.
With Slony and Replicator I don't really see the nee
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Simon Riggs wrote:
Now we're into 8.2devel mode, its time to submit the previously
discussed patch that:
- reduces Numeric storage format by 2 bytes
This makes the often discussed binary upgrade impossible, so I wonder if
two bytes
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Now we're into 8.2devel mode, its time to submit the previously
>> discussed patch that:
>> - reduces Numeric storage format by 2 bytes
> This makes the often discussed binary upgrade impossible, so I wonder if
> two bytes savings
Simon Riggs wrote:
Now we're into 8.2devel mode, its time to submit the previously
discussed patch that:
- reduces Numeric storage format by 2 bytes
This makes the often discussed binary upgrade impossible, so I wonder if
two bytes savings are worth the trouble.
Regards,
Andreas
--
62 matches
Mail list logo
