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:
On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
small patch to provide a new variable server_version_num, which
is almost the same as server_version but uses the handy
PG_VERSION_NUM which allows apps to do things like if ($version =
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:
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
syntax
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 doesn't
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=lionfishdt=2006-07-29%2023:30:06
The test alter_table, which is on the same parallel group as limit (the
failing test),
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 bootstrap,
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
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 early a
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 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,
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
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
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
a
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
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;
The
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 in the
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 this by
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
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 probably
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 I can
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 with { or
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 because I remember
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 WHERE key = mytab.key);
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 fixed
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?
Perhaps
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 indexes ? And what
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 figure it's
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
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
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 Mon Jul 31
31 matches
Mail list logo
