Good catch!
Thanks. I have committed your fix.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> I found a buffer overflow bug in contrib/pgbench.
> This occures when -c >= 2.
>
>
>
> The type of 'state' is CState*, so we should use state+1 or &state[1],
> not state + sizeof(*state)
>
>
> *** pgbench.c
Peter Eisentraut wrote:
That rings a bell. Can we get a more precise designation on what
version of DTrace we support? And where can one get that required
update?
Peter,
The problem with static function was fixed recently and is now available
in Solaris Express (the development versio
David Fetter <[EMAIL PROTECTED]> writes:
> + #include "pg_config.h"
You should not need that. All PG code assumes that c.h and its
inclusions have already been read.
regards, tom lane
---(end of broadcast)---
TIP 6: explain
On Sun, Jul 30, 2006 at 05:40:16PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > David Fetter wrote:
> >> This patch changes the data type from unsigned int to unsigned
> >> long long, which is probably not the correct thing in order to
> >> get 64-bit arithmetic, but I fi
On Fri, Jul 28, 2006 at 12:14:49PM -0500, Jim C. Nasby wrote:
> On Thu, Jul 27, 2006 at 01:46:01PM -0400, Alvaro Herrera wrote:
> > Jim Nasby wrote:
> > > On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
> > > >Hannu Krosing <[EMAIL PROTECTED]> writes:
> >
> > > >>What would be the use-case for hash i
Robert Treat <[EMAIL PROTECTED]> writes:
> On Tuesday 25 July 2006 14:28, Josh Berkus wrote:
>> To be quite frank, current PostgreSQL can't effectively use more than
>> 256mb of work_mem anyway. We'd like to fix that, but it's not fixed yet
>> AFAIK.
> Josh, can you clarify this statement for me?
On Tuesday 25 July 2006 14:28, Josh Berkus wrote:
> Peter,
>
> > I wonder whether platforms with INT64_IS_BROKEN can address more than 2GB
> > of memory anyway.
>
> To be quite frank, current PostgreSQL can't effectively use more than
> 256mb of work_mem anyway. We'd like to fix that, but it's not
On Sun, 2006-07-30 at 20:20 -0400, Robert Treat wrote:
> On Thursday 27 July 2006 09:28, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > Tom Lane wrote:
> > > >> UPDATE mytab SET (foo, bar, baz) =
> > > >> (SELECT alpha, beta, gamma FROM othertab WHE
On Thursday 27 July 2006 09:28, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> UPDATE mytab SET (foo, bar, baz) =
> > >> (SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
> > >
> > > That UPDATE example is interesting
On Fri, Jul 28, 2006 at 10:42:49AM +0200, Pavel Stehule wrote:
> Hello,
>
> I miss better support OUT arguments in plerlu:
>
> create or replace function foo(out p varchar[]) as $$ return { p => [pavel,
> jana] }; $$ language plperlu;
> postgres=# select foo();
> ERROR: array value must start w
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> David Fetter wrote:
>> This patch changes the data type from unsigned int to unsigned long
>> long, which is probably not the correct thing in order to get 64-bit
>> arithmetic, but I figure it's good enough to get a discussion started.
> The only thing
David Fetter wrote:
Hi,
> I just ran across an issue where in psql, people can get the line
> number in the file so long as it is under 2^32-1 lines long, but once
> it gets larger than that, it's hosed.
>
> This patch changes the data type from unsigned int to unsigned long
> long, which is pro
Folks,
I just ran across an issue where in psql, people can get the line
number in the file so long as it is under 2^32-1 lines long, but once
it gets larger than that, it's hosed.
This patch changes the data type from unsigned int to unsigned long
long, which is probably not the correct thing in
I wrote:
> ... This means the only thing stopping us from
> taking lock before we invoke relcache is lack of knowledge about the
> rel's relisshared status. Given that the set of shared relations is
> pretty small, and fixed in any given backend version, it wouldn't be
> unreasonable to handle thi
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I see the very strange behaviour with the following set of queries:
> wsdb=# select na,nb, na::double precision as da, nb::double precision as db
> from ( select random()::numeric as na,random()::numeric as nb from
> generate_series(1,2)) as xx;
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Knew I should have taken time to review that patch before it went in ...
> Which one? The one I applied doesn't have this change.
Never mind --- I misunderstood the context of the discussion and thought
you had made larger changes i
Is there a way to tell if there is support for 64 bits bitwise operations
since c.h apparently defines BUSTED for no support for 64 bits variables.
10x.
--
Regards,
Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS: see at
I wrote:
> I bet Alvaro's spotted the problem. ALTER INDEX RENAME doesn't seem to
> take any lock on the index's parent table, only on the index itself.
> That means that a query on "onek" could be trying to read the pg_class
> entries for onek's indexes concurrently with someone trying to commit
Hello Hackers,
I see the very strange behaviour with the following set of queries:
wsdb=# select na,nb, na::double precision as da, nb::double precision as db
from ( select random()::numeric as na,random()::numeric as nb from
generate_series(1,2)) as xx;
na |nb
Tom Lane wrote:
So what I'm currently thinking is
1. Implement ValuesScan.
2. Convert all existing uses of Result without a child node into
ValuesScan.
3. Rename Result to Filter and rip out whatever code is only used for
the no-child-node case.
Steps 2 and 3 are just in the nature of hou
On Sat, 29 Jul 2006, Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
... From a mathematician's point of view, however, some of these
functions normally produce irrational numbers anyway, so it seems
unlikely that numeric will be useful. But looking at the definition
of, say, regr
I wrote:
> I still dislike the way you're doing things in the executor though.
> I don't see the point of using the execScan.c machinery; most of the
> time that'll be useless overhead. As I said before, I think the right
> direction here is to split Result into two single-purpose node types
> and
On Sun, Jul 30, 2006 at 12:17:57PM -0400, Jonah H. Harris wrote:
> On 7/30/06, David Fetter <[EMAIL PROTECTED]> wrote:
> >Failure to parse means the transaction bails out, which is just
> >what I want in my case, as it disallows people attempting to run
> >the programs--they're for DBI-Link--on too
On 7/30/06, David Fetter <[EMAIL PROTECTED]> wrote:
Failure to parse means the transaction bails out, which is just what I
want in my case, as it disallows people attempting to run the
programs--they're for DBI-Link--on too early a version of PostgreSQL.
As there are some subtleties to the implem
On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
> >> The correct solution is for client-side libraries to provide the
> >> feature.
>
> > Not if the app is written in SQL, as the boot
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Stefan Kaltenbrunner wrote:
>> FYI: lionfish just managed to hit that problem again:
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfish&dt=2006-07-29%2023:30:06
> The test alter_table, which is on the same parallel group as limit (the
> faili
David Fetter <[EMAIL PROTECTED]> writes:
> On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
>> The correct solution is for client-side libraries to provide the
>> feature.
> Not if the app is written in SQL, as the bootstrap, regression test,
> etc. code for modules frequently is.
SQL do
Hi,
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
I am working on adding a new column contraint,
namely the GENERATED [ALWAYS | BY DEFAULT ] AS
[ IDENTITY ( sequence_options ) | ( expression )]
Doesn't this still have the issue that we're taking over spec-defined
synta
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
>> Tom Lane wrote:
>>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
FWIW: lionfish had a weird make check error 3 weeks ago which I
(unsuccessfully) tried to reproduce multiple times after that:
http://www.pgbuildfarm.org/cgi-bi
29 matches
Mail list logo
