"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> Is there a point in checking the thread-safety of
> libpq when you can't check the thread-safety of libc?
>
Exactly :-(
Regards,
Qingqing
---(end of broadcast)---
TIP 5: don't forget to increase your free
Qingqing Zhou <[EMAIL PROTECTED]> writes:
> This is half of an item in TODO list. I patch this because now pgbench is
> threaded in Win32, so it is better to check thread safety of libpq.dll.
ISTM this was proposed once before, and rejected on the grounds that
no one could present a convincing use
This is half of an item in TODO list. I patch this because now pgbench is
threaded in Win32, so it is better to check thread safety of libpq.dll.
Patch ecpg could be done in a similar way, but I am not sure how we will
use this function there ...
Regards,
Qingqing
---
Index: fe-connect.c
=
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
Thanks for comments. I modified the patch.Tom Lane wrote:> Atsushi Ogawa <[EMAIL PROTECTED]> writes:> > (2)About processing when column identifier of SET clause is specified
> > like 'AAA.BBB'. 'AAA' is a composite column now. When an alias for> > target table is supported, 'AAA' is a composite col
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,
Attached is a proposed patch for bug #2085. It's pretty grotty because
it introduces a new TOC tag type into the pg_dump format, which makes it
incompatible with existing pg_restores; so I think we probably couldn't
back-patch this, it'd have to be treated as a new feature for 8.2.
I don't see any
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
On Fri, 2005-12-02 at 15:12 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> >
> > > OK, updated text:
> > >
> > > --with-openssl build with OpenSSL support
> > > --with-libedit-preferred prefer Libedit over Libreadline
> > > --without-readline do not use Libreadline/Li
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
Joshua D. Drake wrote:
>
> > OK, updated text:
> >
> > --with-openssl build with OpenSSL support
> > --with-libedit-preferred prefer Libedit over Libreadline
> > --without-readline do not use Libreadline/Libedit line editing
> > --without-zlib do not use Zlib
>
>
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
Last minute edit:
src/test/mb seems a little bit old. I've tested SQL files in
src/test/mb/sql with the expected results in src/test/mb/expected
manually and it worked. (Output files need a little bit editing, like
removing lines similar to "CREATE TABLE".) But it'll be better if any
EUC users will
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
> OK, updated text:
>
> --with-openssl build with OpenSSL support
> --with-libedit-preferred prefer Libedit over Libreadline
> --without-readline do not use Libreadline/Libedit line editing
> --without-zlib do not use Zlib
This all seems kind of extra... Why not j
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:
> > --with-libedit-preferred prefer libedit over readline
> > --without-readline do not use Readline
>
> Possibly
> --without-readline do not use readline or libedit
>
> In any case please be consistent about the capitalization ...
OK,
Bruce Momjian writes:
> --with-libedit-preferred prefer libedit over readline
> --without-readline do not use Readline
Possibly
--without-readline do not use readline or libedit
In any case please be consistent about the capitalization ...
regards, tom
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
Tom Lane wrote:
> Bruce Momjian writes:
> > The basic problem is that with two deterministic flags the default
> > values for those flags are unclear.
>
> That's a really good point ... the only explainable default would be
> that both are --without, which is a crummy default.
>
> I think the wa
Andrew Dunstan wrote:
> >>I trimmed it down to:
> >> --with-prefer-libedit prefer libedit over readline
> >
>
> I think it's ugly. Can't we just say --prefer-libedit ?
>
> If must be a --with-foo flag, maybe --with-libedit-preferred or
> --with-libedit-first would be better.
OK, changed:
Bruce Momjian writes:
> The basic problem is that with two deterministic flags the default
> values for those flags are unclear.
That's a really good point ... the only explainable default would be
that both are --without, which is a crummy default.
I think the way that Bruce's patch works is fi
Tom Lane wrote:
> Chris Browne <[EMAIL PROTECTED]> writes:
> > To my mind, giving BIG weight to the opinions of the relatively small
> > set of individuals that manage PostgreSQL packages for the popular
> > distributions of Linux and *BSD seems fairly appropriate.
>
> The packagers are bright eno
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
unsuscribe
pgsql-patches
Julio
César Elizondo GTI- Adm. Base Datos y SAP
Distribuidora de Gas Cuyana S.A.Distribuidora de Gas Del Centro
S.A. [EMAIL PROTECTED]
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
Julio
César Elizondo GTI- Adm. Base Datos y SAP
Distribuidora de Gas Cuyana S.A.Distribuidora de Gas Del Centro
S.A. [EMAIL PROTECTED]
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
Chris Browne <[EMAIL PROTECTED]> writes:
> To my mind, giving BIG weight to the opinions of the relatively small
> set of individuals that manage PostgreSQL packages for the popular
> distributions of Linux and *BSD seems fairly appropriate.
The packagers are bright enough to adapt to whatever we
Volkan YAZICI wrote:
> On 12/1/05, Bruce Momjian wrote:
> > Where are we on this patch? Is it to be applied?
>
> After Tom's advice (he was doubtful about the patch), while I was
> thinking about how to improve the spectrum of tests, decided to use
> src/test/mb. In the tests, patch just succeded
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
[EMAIL PROTECTED] (Tom Lane) writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> I'm concerned that this still gives nondeterministic behavior.
>> There's no way to say, "I want readline, period" or "I want
>> libedit, period". I'd prefer simple --with-readline and
>> --with-libedit, giving
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
http://projects.commandprompt.com/projects/public/pgsql/browser/trunk/pgsql
It has the additional advantage over our current CVSweb that it's
set with tabs to 4 spaces, so it looks just like our code is
supposed to ...
I need to spend some time on it to see if there is a way that I
Magnus Hagander wrote:
BTW, has anyone checked Command Prompt's Subversion
repository? It's a mirror of our anonymous CVS (AFAICT).
I'm using it for reading diffs lately, and it's much nicer to
look at the whole patch as a single diff rather than going a
single file at a time.
http://pr
Tom Lane wrote:
Bruce Momjian writes:
I trimmed it down to:
--with-prefer-libedit prefer libedit over readline
OK, I can live with that.
I think it's ugly. Can't we just say --prefer-libedit ?
If must be a --with-foo flag, maybe --with-libedit-pre
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I'm concerned that this still gives nondeterministic behavior. There's
> no way to say, "I want readline, period" or "I want libedit, period".
> I'd prefer simple --with-readline and --with-libedit, giving one turns
> off the other, giving both is
Bruce Momjian writes:
> Where are we on this patch? Was it submitted? Applied? Just an
> idea?
| This has been saved for the 8.2 release:
|
| http://momjian.postgresql.org/cgi-bin/pgpatches_hold
I tested it with 8.1RC1 and noticed the inconsistency with the \edit
command. I guess one w
On 12/1/05, Bruce Momjian wrote:
> Where are we on this patch? Is it to be applied?
After Tom's advice (he was doubtful about the patch), while I was
thinking about how to improve the spectrum of tests, decided to use
src/test/mb. In the tests, patch just succeded for unicode and failed
on big5,
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
Bruce Momjian wrote:
> I trimmed it down to:
>
> --with-bonjour build with Bonjour support
> --with-openssl build with OpenSSL support
> --with-prefer-libedit prefer libedit over readline
> --without-readline do not use Readline
> --without-zlib do not us
63 matches
Mail list logo
