I am a little stuck of a question.
In fmgr.c:1698, function InputFunctionCall at line 1718
/* Should get null result if and only if str is NULL */
if (str == NULL)
{
What are we testing to be NULL here?
Do we expect str to changed at line 1715
( result =
On Sat, 9 Sep 2006 at 15:57, Lamar Owen wrote:
[...] or annoying the small number of people who NFS mount their
datadirs?
This problem is not limited to NFS. It can happen with any FS just by
reversing (for whatever reason) the order of mounting the FS and
starting the PostgreSQL server.
At 2006-09-11 10:25:22 +0200, [EMAIL PROTECTED] wrote:
What are we testing to be NULL here?
Do we expect str to changed at line 1715
No. (Read the comment just above the function.)
The code is like this, starting from line 1703:
if (str == NULL flinfo-fn_strict)
return (Datum)
Hello,
I'm trying to put the cassowary buildfarm member back to work (it's
been inactive
for almost a month because i've moved to another project and switched
the machine).
The run_build script has trouble with sending the test results. The error is :
Status Line: 491 bad ts parameter -
On Mon, 11 Sep 2006, Adrian Maier wrote:
It's not clear to me where does that date-in-the-future come from.
The machine's
date is set correctly:
$ date
Mon Sep 11 11:00:30 PST 2006
Um, no. I am currently in the PST time zone, and I can say from
first-hand experience that the current time
On 9/11/06, Jeremy Drake [EMAIL PROTECTED] wrote:
On Mon, 11 Sep 2006, Adrian Maier wrote:
It's not clear to me where does that date-in-the-future come from.
The machine's
date is set correctly:
$ date
Mon Sep 11 11:00:30 PST 2006
Um, no. I am currently in the PST time zone, and I can
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I'm a bit confused by this and how it would be handled in your sketch. I
assumed we needed a bit pattern dedicated to 4-byte length headers because
even though it would never occur on disk it would be necessary to for
Hi, Tom,
Tom Lane wrote:
The only way we could pack stuff without alignment is to go over to the
idea that memory and disk representations are different --- where in
this case the conversion might just be a memcpy to a known-aligned
location. The performance costs of that seem pretty
I intend to play with some optimizer aspects. Just for fun. I'm a
novice in the DBMS development so I can not promise any available
results but if it can be useful even as yet another failed attempt I
will try.
That's what I want to do:
1. Replace not very useful indexCorrelation with
Tom Lane [EMAIL PROTECTED] writes:
Mark Dilger [EMAIL PROTECTED] writes:
... The argument made upthread that a
quadratic number of conversion operators is necessitated doesn't seem
right to me, given that each type could upcast to the canonical built in
type. (int1 = smallint, int3 =
Adrian Maier wrote:
On 9/11/06, Jeremy Drake [EMAIL PROTECTED] wrote:
On Mon, 11 Sep 2006, Adrian Maier wrote:
It's not clear to me where does that date-in-the-future come from.
The machine's
date is set correctly:
$ date
Mon Sep 11 11:00:30 PST 2006
Um, no. I am currently in the PST
I don't know if this changes the calculus but apparently we've already decided
to go down the route of having Emacs local variables attached to every file in
the source directory. We have things like this there:
!-- Keep this comment at the end of the file
Local variables:
mode: sgml
Albe Laurenz [EMAIL PROTECTED] writes:
Tom Lane wrote:
Applied, but without that last part. It builds OK for me on Darwin,
which is moderately picky about that sort of thing, but someone should
try AIX.
It builds fine on AIX 5.3 as long as you tell it to link with
libpq.so. Static builds
Lately there have been some buildfarm registrations for Debian
testing/unstable or similarly described machines. I have kicked back
against these, as the description seems to me to be far too open ended.
Likewise, I also have difficulty with Gentoo because a version there
seems to describe a
Martijn van Oosterhout kleptog@svana.org writes:
Static links are going to require it on every platform, not just AIX.
The question do we want to ask is how easy do we want to make static
linking, because the same treatment will have to apply to -lssl,
-lcrypto, -lkrb5, -lk5crypto and quite
Gregory Stark wrote:
I don't know if this changes the calculus but apparently we've already decided
to go down the route of having Emacs local variables attached to every file in
the source directory. We have things like this there:
!-- Keep this comment at the end of the file
Local variables:
Hi, Gevik,
Gevik Babakhani wrote:
typreceive = not supported
typsend = not supported
Any reason why you don't want to support binary transmissions?
Thanks,
Markus
--
Markus Schaber | Logical TrackingTracing International AG
Dipl. Inf. | Software Development GIS
Fight against software
Andrew Dunstan [EMAIL PROTECTED] writes:
Gregory Stark wrote:
I don't know if this changes the calculus but apparently we've already
decided
to go down the route of having Emacs local variables attached to every file
in
the source directory. We have things like this there:
!-- Keep this
Andrew Dunstan wrote:
Lately there have been some buildfarm registrations for Debian
testing/unstable or similarly described machines. I have kicked back
against these, as the description seems to me to be far too open ended.
Likewise, I also have difficulty with Gentoo because a version
Tom Lane [EMAIL PROTECTED] writes:
Also Heikki points out here that it would be nice to allow for the case for a
0-byte header.
I don't think there's enough code space for that; at least not compared
to its use case.
Well it's irrelevant if we add a special data type to handle CHAR(1).
But
Tom Lane wrote:
It builds fine on AIX 5.3 as long as you tell it to link with
libpq.so. Static builds against libpq.a will fail.
Hm. We have been assuming that AIX's problem is that dynamic
libraries
don't remember their dependencies properly, but maybe the real issue
is
that it prefers
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Also Heikki points out here that it would be nice to allow for the case
for a
0-byte header.
I don't think there's enough code space for that; at least not compared
to its use case.
Well it's irrelevant if we add a special
Albe Laurenz [EMAIL PROTECTED] writes:
Let me expand a little on some of the peculiarities of
shared libraries on AIX:
- A normal AIX shared library is called libXX.a
It is an 'ar' archive that contains the shared object(s).
Ah, so the problem really boils down to funny naming conventions.
On Mon, Sep 11, 2006 at 03:13:36PM +0100, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Also Heikki points out here that it would be nice to allow for the case
for a
0-byte header.
I don't think there's enough code space for that; at least not compared
to its use case.
Jan de Visser wrote:
On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
2a) Three input formats are supported.
example:
insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
insert into tbl (fld) values('{1dfb39af-b56a-40b8-a903-b5b31567c3ce}');
insert into tbl (fld)
On Monday 11 September 2006 11:05, Thomas Hallgren wrote:
Jan de Visser wrote:
On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
2a) Three input formats are supported.
example:
insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
insert into tbl (fld)
Michael Fuhr [EMAIL PROTECTED] writes:
contrib/xml2 currently has PG_MODULE_MAGIC in xslt_proc.c, which
results in a runtime error on systems that built the module without
support for libxslt per the comments in the Makefile. Should
PG_MODULE_MAGIC be in xpath.c instead?
[ examines
Mark Wong [EMAIL PROTECTED] writes:
Tom Lane wrote:
It would be nice to see some results from the OSDL tests with, say, 4,
8, and 16 lock partitions before we forget about the point though.
Anybody know whether OSDL is in a position to run tests for us?
Yeah, I can run some dbt2 tests in the
I forgot the mention that I did not want to support those two in my
initial version. But yesterday I started to work on those anyway :)
typreceive and typsend
On Mon, 2006-09-11 at 15:58 +0200, Markus Schaber wrote:
Hi, Gevik,
Gevik Babakhani wrote:
typreceive = not supported
Thank you for your reply.
I found my bug in the code which made the function behave strangely.
On Mon, 2006-09-11 at 14:23 +0530, Abhijit Menon-Sen wrote:
At 2006-09-11 10:25:22 +0200, [EMAIL PROTECTED] wrote:
What are we testing to be NULL here?
Do we expect str to changed at line
Alvaro Herrera [EMAIL PROTECTED] writes:
Well it's irrelevant if we add a special data type to handle CHAR(1).
In that case you should probably be using char ...
Well char doesn't have quite the same semantics as CHAR(1). If that's the
consensus though then I can work on either fixing char
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
contrib/xml2 currently has PG_MODULE_MAGIC in xslt_proc.c, which
results in a runtime error on systems that built the module without
support for libxslt per the comments in the Makefile. Should
PG_MODULE_MAGIC be in xpath.c instead?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I see this in the CVS commits for 8.2. Did we determine the proper
number of lock partitions? Should it be based on the number of buffers
or concurrent sessions allowed?
No. NUM_LOCK_PARTITIONS needs to be a compile-time constant for
On Sun, 2006-09-10 at 21:16 -0400, Tom Lane wrote:
After further thought I have an alternate proposal
(snip)
* If high order bit of datum's first byte is 0, then it's an
uncompressed datum in what's essentially the same as our current
in-memory format except that the 4-byte length word must
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I'm imagining that it would give you the same old uncompressed in-memory
representation as it does now, ie, 4-byte length word and uncompressed
data.
Sure, but how would you know? Sometimes you would get a pointer to
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Well it's irrelevant if we add a special data type to handle CHAR(1).
In that case you should probably be using char ...
Well char doesn't have quite the same semantics as CHAR(1). If that's the
consensus though then I
Andrew Dunstan wrote:
Lately there have been some buildfarm registrations for Debian
testing/unstable or similarly described machines. I have kicked back
against these, as the description seems to me to be far too open
ended.
Then again, it would be useful to actually test on Debian
Gregory Stark wrote:
I don't know if this changes the calculus but apparently we've
already decided to go down the route of having Emacs local variables
attached to every file in the source directory. We have things like
this there:
I delete them from every file I edit, but I haven't been
Gregory Stark [EMAIL PROTECTED] writes:
In any case it seems a bit backwards to me. Wouldn't it be better to
preserve bits in the case of short length words where they're precious
rather than long ones? If we make 0xxx the 1-byte case it means ...
Well, I don't find that real persuasive:
Hi!
I'm about to do some benchmarking on -HEAD one some hardware I have
available and it seems I'm hitting a rather weird issue causing the osdl
dbt3 benchmark to run very slow and eating CPU time for hours ...
it seems that the issue is caused by the following query:
(in case it gets
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
In any case it seems a bit backwards to me. Wouldn't it be better to
preserve bits in the case of short length words where they're precious
rather than long ones? If we make 0xxx the 1-byte case it means ...
Why in the world is set_pglocale_pgservice() located in src/port/path.c?
I was just trying to find out why ecpg is failing on the Darwin
buildfarm members since I modified the arrangements for pulling in extra
libraries for AIX. The answer is that ecpglib needs path.c for
last_dir_separator(),
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Lately there have been some buildfarm registrations for Debian
testing/unstable or similarly described machines. I have kicked back
against these, as the description seems to me to be far too open
ended.
Then again, it would be useful to
While I'm sitting here in New Jersey in a room with Bruce Momjian (aka
Rock Star), I figured now would be a good time to announce my new
employment. I'll be doing sales support/engineering from Austin.
--
Jim Nasby [EMAIL PROTECTED]
EnterpriseDBhttp://enterprisedb.com
Stefan Kaltenbrunner wrote:
well I think Andrew is more scared of having multiple boxes on the
buildfarm all stating to be Debian testing or Debian unstable but
without much information on how regulary those boxes are actually synced
to those moving/changing branches and causing discussions
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
well I think Andrew is more scared of having multiple boxes on the
buildfarm all stating to be Debian testing or Debian unstable but
without much information on how regulary those boxes are actually synced
to those moving/changing branches
Simon Riggs [EMAIL PROTECTED] writes:
Is this an 8.2 thing?
You are joking, no?
If not, is Numeric508 applied?
No, that got rejected as being too much of a restriction of the dynamic
range, eg John's comment here:
http://archives.postgresql.org/pgsql-general/2005-12/msg00246.php
I think a
Peter Eisentraut [EMAIL PROTECTED] writes:
I agree that the lack of a fixed version designation is unsatisfactory.
I'm not sure whether that is actually necessary, though. If PostgreSQL
doesn't work on some machine, then that's a problem anyway.
The buildfarm script already seems to record
On Mon, Sep 11, 2006 at 01:15:43PM -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
In any case it seems a bit backwards to me. Wouldn't it be better to
preserve bits in the case of short length words where they're precious
rather than long ones? If we make 0xxx the 1-byte
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I'm about to do some benchmarking on -HEAD one some hardware I have
available and it seems I'm hitting a rather weird issue causing the osdl
dbt3 benchmark to run very slow and eating CPU time for hours ...
Could we see the actual EXPLAIN ANALYZE
Tom Lane wrote:
Even more interesting would be to fix things so that xml2 gets built
as part of the regular contrib build, but I'm not sure if we're ready
to add stuff to the configure script for the sole benefit of a
contrib module.
It might be good to get the configury code out in this
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I'm about to do some benchmarking on -HEAD one some hardware I have
available and it seems I'm hitting a rather weird issue causing the osdl
dbt3 benchmark to run very slow and eating CPU time for hours ...
Could we see the
For those who don't read all the threads, I'll repeat it here. I've put
up a wiki page working out the mysterious XML support:
http://developer.postgresql.org/index.php/XML_Support
This is pretty much my talk from the conference.
The short status is that we have quite a bit of code ready and
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
btw - the hashjoin is bad was more or less based on the observation
that nearly all of the cpu is burned in hash-related functions in the
profile (when profiling over a longer period of time those accumulate
even more % of the time than in the
Tom Lane wrote:
The buildfarm script already seems to record various info such as
uname output on-the-fly. If we could get it to record compiler
version (gcc -v is easy, but equivalent incantations for vendor
compilers might be harder to find) and a few other facts on-the-fly,
I think the
Tom Lane wrote:
Here is a new patch that replaces the previous one; it adds two
macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
respectively.
I did not only add them to the Makefile for interfaces/libpq,
but also everywhere something is linked against libpq in case
somebody
On Mon, Sep 11, 2006 at 12:13:29PM +0200, Albe Laurenz wrote:
Applied, but without that last part. It builds OK for me on Darwin,
which is moderately picky about that sort of thing, but someone should
try AIX.
It builds fine on AIX 5.3 as long as you tell it to link with
libpq.so.
Here is a new patch that replaces the previous one; it adds two
macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
respectively.
I did not only add them to the Makefile for interfaces/libpq,
but also everywhere something is linked against libpq in case
somebody links static.
Tom Lane [EMAIL PROTECTED] writes:
No, that got rejected as being too much of a restriction of the dynamic
range, eg John's comment here:
http://archives.postgresql.org/pgsql-general/2005-12/msg00246.php
That logic seems questionable. John makes two points:
a) crypto applications are within
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
No, that got rejected as being too much of a restriction of the dynamic
range, eg John's comment here:
http://archives.postgresql.org/pgsql-general/2005-12/msg00246.php
That logic seems questionable. John makes two
Hello,
On Mon, 2006-09-11 at 13:11 -0500, Jim C. Nasby wrote:
While I'm sitting here in New Jersey in a room with Bruce Momjian (aka
Rock Star), I figured now would be a good time to announce my new
employment. I'll be doing sales support/engineering from Austin.
Congrats Jim.
Cheers,
--
Congrats Jim!
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
Sent: Monday, September 11, 2006 02:12 PM Eastern Standard Time
To: pgsql-hackers@postgresql.org
Subject:[HACKERS] New job
While I'm sitting here in New
Tom Lane [EMAIL PROTECTED] writes:
That's utterly irrelevant. The point is that there are standard
applications today in which people need that much precision; therefore,
the argument that 10^508 is far more than anyone could want is on
exceedingly shaky ground.
My point is those
Tom Lane wrote:
Albe Laurenz [EMAIL PROTECTED] writes:
Let me expand a little on some of the peculiarities of
shared libraries on AIX:
- A normal AIX shared library is called libXX.a
It is an 'ar' archive that contains the shared object(s).
Ah, so the problem really boils down to
Gregory Stark [EMAIL PROTECTED] writes:
At first I meant that as a reductio ad absurdum argument, but, uh,
come to think of it why *do* we have our own arbitrary precision
library? Is there any particular reason we can't use one of the
existing binary implementations?
Going over to binary
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
At first I meant that as a reductio ad absurdum argument, but, uh,
come to think of it why *do* we have our own arbitrary precision
library? Is there any particular reason we can't use one of the
existing binary
On Mon, Sep 11, 2006 at 07:05:12PM -0400, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
At first I meant that as a reductio ad absurdum argument, but, uh,
come to think of it why *do* we have our own arbitrary precision
library? Is
I have just realized that the recent patches in pgbench have altered its
behavior in a way that destroys reproducibility of results --- I'm
seeing reported TPS numbers about twice what they were before that.
I'd love to say we did something in the past month that made the backend
2X faster, but
I'll look into this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
I have just realized that the recent patches in pgbench have altered its
behavior in a way that destroys reproducibility of results --- I'm
seeing reported TPS numbers about twice what they were before that.
I'd love to say we did
Quoth [EMAIL PROTECTED] (Peter Eisentraut):
Andrew Dunstan wrote:
Lately there have been some buildfarm registrations for Debian
testing/unstable or similarly described machines. I have kicked back
against these, as the description seems to me to be far too open
ended.
Then again, it would
Christopher Browne wrote:
It seems to me that there is some value in putting together a script
that tries to identify some of the interesting bits of the toolchain.
Yeah; but why not just a bunch of commands, some of which are expected
to work on any particular machine, and save the whole
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've applied this but I'm now having some second thoughts about it,
because I'm seeing an actual *decrease* in pgbench numbers from the
immediately prior CVS HEAD code.
The attached patch requires the new row to fit, and 10% to be free
72 matches
Mail list logo
