Manfred Spraul wrote:
Tom Lane wrote:
Not really: it only solves the problem *if you change the application*,
which is IMHO not acceptable. In particular, why should a non-threaded
app expect to have to change to deal with this issue? But we can't
safely build a thread-safe libpq.so for
OK, either you have to own the issue or I have to add something to the
TODO list.
---
Neil Conway wrote:
On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote:
Neil, where are we on this? Should we add comments? Add a
Kris Jurka [EMAIL PROTECTED] writes:
This recent change to readline/libedit selection isn't quite right.
If you see a problem you'll have to give more details ...
It doesn't link in libtermcap with libedit which leads to:
Certainly it tries that.
checking for readline.h... no
configure:
Neil Conway [EMAIL PROTECTED] writes:
ISTM it would be reasonable to mandate that aggregate authors return one
of three things from their state transition functions:
(a) return the previous state value
(b) return the next data item value
(c) return some other value; if by a
Manfred Spraul [EMAIL PROTECTED] writes:
Tom Lane wrote:
Not really: it only solves the problem *if you change the application*,
which is IMHO not acceptable.
No. non-threaded apps do not need to change. The default is the old, 7.3
code: change the signal handler around the write calls.
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
Tom Lane wrote:
Not really: it only solves the problem *if you change the application*,
which is IMHO not acceptable.
No. non-threaded apps do not need to change. The default is the old, 7.3
code: change the signal handler
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I've raised this before, but would like to suggest again that there might be
virtue in branching earlier in the dev cycle - maybe around the time of the
first beta.
Given the amount of patching that's gone on, branching 8.1 earlier
Dear People,
I was wondering if there are any interests or plans for documenting
various functions in the code which currently are not documented.
I would like to start this discussion to see if we want to do this.
If I am the first one with this suggestion (I can't imagine) then I am
very
Tom Lane wrote:
Not really: it only solves the problem *if you change the application*,
which is IMHO not acceptable. In particular, why should a non-threaded
app expect to have to change to deal with this issue? But we can't
safely build a thread-safe libpq.so for general use if it breaks
Dear People,
I was wondering if there are any interests or plans for documenting
various functions in the code which currently are not documented.
I would like to start this discussion to see if we want to do this.
If I am the first one with this suggestion (I can't imagine) then I am
very
Neil Conway [EMAIL PROTECTED] wrote on 02.12.2004, 05:05:12:
On Wed, 2004-12-01 at 19:34 +0100, [EMAIL PROTECTED] wrote:
I regard performance testing as an essential part of the
release process of any performance critical software. Most earlier beta
releases were fixing functional problems
On Wed, Dec 01, 2004 at 10:04:43PM -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I've raised this before, but would like to suggest again that there might be
virtue in branching earlier in the dev cycle - maybe around the time of the
first beta.
Given the amount of
Hi there,
there are several new contributed docs on tsearch2 page:
# How to use tsearch2 in Japanese
# Tsearch2 and Unicode/UTF-8
# Howto write my own parser for tsearch2
Thanks to Junji TERAMOTO, Markus Wollny and Valli for their work !
Regards,
Oleg
The core committee has agreed that it's about time to advance to Release
Candidate status (which we define as code is frozen, but not docs nor
message translation work). Barring surprises, 8.0RC1 will be wrapped
tomorrow (Friday).
We never really issued a call for port reports as has been past
Neil Conway [EMAIL PROTECTED] wrote on 02.12.2004, 05:55:43:
On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote:
Neil, where are we on this? Should we add comments? Add a TODO? A patch?
I'm not sure what the right resolution is. As I said, I don't think it's
wise to apply a patch
Neil Conway wrote:
On Sat, 2004-11-27 at 23:11 -0500, Bruce Momjian wrote:
Is there a TODO here? Or a few?
Sure: you could add a TODO item like Improve psql schema behavior, and
assign it to me. I'll send in a patch that implements the behavior I
proposed for 8.1
Added to TODO:
Andrew Dunstan [EMAIL PROTECTED] writes:
John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
code.
You know, there's something twisted in postgres's naming scheme here. How is
it that trusted languages the ones that need a sandbox? and untrusted
languages the ones that
On Thu, 2004-12-02 at 02:21 -0500, Greg Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
code.
You know, there's something twisted in postgres's naming scheme here. How is
it that trusted languages the ones
Kris Jurka [EMAIL PROTECTED] writes:
This recent change to readline/libedit selection isn't quite right.
http://archives.postgresql.org/pgsql-committers/2004-11/msg00330.php
I found the reason for not linking to libtermcap --- there was an
ancient netbsd-specific hack that wasn't
Jan,
... plus that the catch-nesting automatically represents the
subtransaction nesting. I can't really see any reason why those two
should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
the long run, I still think that savepoints
Tom Lane wrote:
The core committee has agreed that it's about time to advance to Release
Candidate status (which we define as code is frozen, but not docs nor
message translation work). Barring surprises, 8.0RC1 will be wrapped
tomorrow (Friday).
We never really issued a call for port reports as
On Thu, 2 Dec 2004, Tom Lane wrote:
Reading between the lines, I wonder if your problem is that your copy of
editline puts its headers in include/readline rather than
include/editline?
Yes, this is the actual problem readline.h is indeed in
/usr/include/readline.. The missing symbols I
Kris Jurka [EMAIL PROTECTED] writes:
On Thu, 2 Dec 2004, Tom Lane wrote:
Reading between the lines, I wonder if your problem is that your copy of
editline puts its headers in include/readline rather than
include/editline?
Yes, this is the actual problem readline.h is indeed in
Patch applied. Thanks.
---
John Hansen wrote:
3 times lucky?
Last one broke utf8 G
This one works, Too tired, sorry for the inconvenience..
... John
Content-Description: cvs.diff
[ Attachment,
Patch applied. Thanks.
---
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Bruce Momjian
Sent: 27 November 2004 04:33
To: [EMAIL PROTECTED]
I have applied all outstanding patches and I think we are ready to go
for RC1. These are the open items. I think we will just have to move
them to the TODO list tomorrow, except for the documentation items.
---
I am going to discard these emails. We haven't solve the Win32 terminal
server problem and I think it needs to be moved to the TODO list instead.
---
Zeugswetter Andreas DAZ SD wrote:
o fix shared memory on Win2k
Here is an updated open items list. The first three items are the ones
that are going to be closed tomorrow and moved to the TODO list. I
already moved the terminal server issue to the TODO list.
---
On Dec 2, 2004, at 11:08 AM, Tom Lane wrote:
We never really issued a call for port reports as has been past
practice. I think that Andrew Dunstan's build farm has partially
obsoleted that custom, but if you have access to a platform that
is not represented in the build farm, please do give it a
Travis P [EMAIL PROTECTED] writes:
What platforms are covered by the build farm?
See
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Also I think there is a gborg project page for it.
regards, tom lane
---(end of
Tom Lane wrote:
Travis P [EMAIL PROTECTED] writes:
What platforms are covered by the build farm?
See
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Also I think there is a gborg project page for it.
s/gborg/pgfoundry/
http://pgfoundry.org/projects/pgbuildfarm/
I started work today
Tom Lane [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Jim Seymour) writes:
I'm kind of wondering if anybody on the dev team noticed this and
what, if anything, they planned to do with it?
Can we make it #ifdef SOLARIS7 somehow? I'm uneager to put a
performance penalty on every platform
I am going to discard these emails. We haven't solve the Win32 terminal
server problem and I think it needs to be moved to the TODO list instead.
Yes, please do that. I do not think there is a problem on TS other than some
missing permissions. The patch was only intended to avoid starting 2
Bruce Momjian [EMAIL PROTECTED] wrote:
You will be glad to know that 8.0 will use a different implementation
for thread handling of SIGPIPE, though your asynchronous handling of
SIGPIPE will still cause problems.
So-noted.
Jim
---(end of
On Dec 2, 2004, at 5:44 PM, Andrew Dunstan wrote:
http://pgfoundry.org/projects/pgbuildfarm/
I started work today on a page that lists all the members.
Ah, good. I'm not seeing it immediately, but I'll keep my eye out.
I've an AIX 5.1 system on which I could try to compile if you don't
have
On Thu, 2004-12-02 at 10:45 -0500, Tom Lane wrote:
(2) I think you lose much of the performance
benefit as soon as you have to distinguish cases (b) and (c). Ideally
you would use MemoryContextContains for this, but that doesn't work
reliably on pointers that point to fields of a tuple.
Why
I wrote:
If it bothers you that much. I'd make a flag, cleared at the start of
each COPY, and then where we test for CR or LF in CopyAttributeOutCSV,
if the flag is not set then set it and issue the warning.
I didn't realise until Bruce told me just now that I was on the hook for
this. I
Neil Conway [EMAIL PROTECTED] writes:
On Thu, 2004-12-02 at 10:45 -0500, Tom Lane wrote:
(2) I think you lose much of the performance
benefit as soon as you have to distinguish cases (b) and (c).
Why wouldn't a simple comparison work? We're passing two arguments into
the aggregate function:
Andrew Dunstan [EMAIL PROTECTED] writes:
+ if (!embedded_line_warning (c == '\n' || c == '\r') )
+ {
+ embedded_line_warning = true;
+ elog(WARNING,
+ CSV fields with embedded linefeed or carriage
Travis P wrote:
On Dec 2, 2004, at 5:44 PM, Andrew Dunstan wrote:
http://pgfoundry.org/projects/pgbuildfarm/
I started work today on a page that lists all the members.
Ah, good. I'm not seeing it immediately, but I'll keep my eye out.
I've an AIX 5.1 system on which I could try to compile if
Bruce Momjian wrote:
I have applied all outstanding patches and I think we are ready to go
for RC1.
Considering that you just added at least three new and completely
untested features, I don't think RC1 is the way to go.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Tom Lane wrote:
We never really issued a call for port reports as has been past
practice. I think that Andrew Dunstan's build farm has partially
obsoleted that custom, but if you have access to a platform that
is not represented in the build farm, please do give it a try soon.
The platform
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
+ if (!embedded_line_warning (c == '\n' || c == '\r') )
+ {
+ embedded_line_warning = true;
+ elog(WARNING,
+ CSV fields with embedded linefeed or carriage return
+ characters might not be able to be reimported);
+
Andrew Dunstan wrote:
If you have something missing from here I'm especially interested in
hearing from you.
I think Linux entries are quite useless. We need to know what
distribution (and version) it is. The kernel is actually a pretty
uninteresting part of the porting process.
--
Peter
Hi all, before I delve too deeply into this, has anyone else tried building
7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
cc -Xa -O -v -I../../../../src/include -c -o tuptoaster.o tuptoaster.c
On Fri, 3 Dec 2004, Peter Eisentraut wrote:
Bruce Momjian wrote:
I have applied all outstanding patches and I think we are ready to go
for RC1.
Considering that you just added at least three new and completely
untested features, I don't think RC1 is the way to go.
I have to agree here ... I'd do a
On Thu, 2 Dec 2004, Bruce Momjian wrote:
Here is an updated open items list. The first three items are the ones
that are going to be closed tomorrow and moved to the TODO list. I
already moved the terminal server issue to the TODO list.
'k, will watch for commits on these before doing the RC1
Marc G. Fournier wrote:
On Fri, 3 Dec 2004, Peter Eisentraut wrote:
Bruce Momjian wrote:
I have applied all outstanding patches and I think we are ready to go
for RC1.
Considering that you just added at least three new and completely
untested features, I don't think RC1 is the way
Peter Eisentraut wrote:
Andrew Dunstan wrote:
If you have something missing from here I'm especially interested in
hearing from you.
I think Linux entries are quite useless. We need to know what
distribution (and version) it is. The kernel is actually a pretty
uninteresting part of
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Fri, 3 Dec 2004, Peter Eisentraut wrote:
Bruce Momjian wrote:
I have applied all outstanding patches and I think we are ready to go
for RC1.
Considering that you just added at least three new and completely
untested features,
On Thu, 2 Dec 2004, Bruce Momjian wrote:
One more issue. Until we start RC, patches that are bug fixes will
continue to be applied. Do we want that? By going RC we are basically
saying we need to focus on docs and packaging and we perhaps can keep
fixes for 8.0.1.
critical bug fixes should
Bruce Momjian [EMAIL PROTECTED] writes:
One more issue. Until we start RC, patches that are bug fixes will
continue to be applied. Do we want that? By going RC we are basically
saying we need to focus on docs and packaging and we perhaps can keep
fixes for 8.0.1.
In my mind RC means only
Marc G. Fournier wrote:
On Thu, 2 Dec 2004, Bruce Momjian wrote:
One more issue. Until we start RC, patches that are bug fixes will
continue to be applied. Do we want that? By going RC we are basically
saying we need to focus on docs and packaging and we perhaps can keep
fixes for
Philip Yarra [EMAIL PROTECTED] writes:
Hi all, before I delve too deeply into this, has anyone else tried building
7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
cc -Xa -O -v
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One more issue. Until we start RC, patches that are bug fixes will
continue to be applied. Do we want that? By going RC we are basically
saying we need to focus on docs and packaging and we perhaps can keep
fixes for 8.0.1.
In
On Thu, 2004-12-02 at 10:58 +0100, Gevik Babakhani wrote:
I was wondering if there are any interests or plans for documenting
various functions in the code which currently are not documented.
I don't know of any systematic effort to do this. I try to document
undocumented code as necessary
I have backed out this patch. It is unclear it is a bug fix.
It will be saved for 8.1.
---
pgman wrote:
Patch applied. Thanks.
---
John
On Thu, 2004-12-02 at 19:07 -0500, Tom Lane wrote:
True, but you still have to palloc if it returns the second argument.
Is that common? In any case, I don't see how you can _ever_ avoid a
palloc if the aggregate returns the second argument. The second argument
is in a per-tuple memory context:
Neil Conway [EMAIL PROTECTED] writes:
- yours would mean that int8inc() and similar aggregates wouldn't ever
need to do palloc(); mine would require a palloc() every k calls to the
transition function.
No. The current code involves two pallocs per cycle, one inside the
aggregate function to
I think the basis in understanding how PostgreSQL works depends
on the documentation to certain extend and the level of one's programming
and database knowledge of course.
At this moment I am gathering information from anywhere I can get a hold
of regarding PostgresSQL.
I have requested a
Great. Documentation of the source code helps many developers become
more productive.
---
Gevik Babakhani wrote:
I think the basis in understanding how PostgreSQL works depends
on the documentation to certain extend and
On Thu, 2004-12-02 at 20:51 -0500, Tom Lane wrote:
No. The current code involves two pallocs per cycle, one inside the
aggregate function to construct its result value, and then one in
datumCopy to copy the result into the proper context.
Ah, true -- missed the fact that PG_RETURN_INT64()
On Thu, 2004-12-02 at 09:59 -0500, Bruce Momjian wrote:
OK, either you have to own the issue or I have to add something to the
TODO list.
Can you add it to the TODO list and assign it to me?
-Neil
---(end of broadcast)---
TIP 3: if
Neil Conway wrote:
On Thu, 2004-12-02 at 09:59 -0500, Bruce Momjian wrote:
OK, either you have to own the issue or I have to add something to the
TODO list.
Can you add it to the TODO list and assign it to me?
Done:
* Fix priority ordering of read and write light-weight locks
I've tried emailling David Fetter to no avail; anyone know who's in
charge of the torrents or anyone who can answer my original question?
- Forwarded message from Jim C. Nasby [EMAIL PROTECTED] -
Date: Tue, 23 Nov 2004 15:52:15 -0600
From: Jim C. Nasby [EMAIL PROTECTED]
To: [EMAIL
On Fri, Dec 03, 2004 at 11:31:19AM +1100, Philip Yarra wrote:
Hi all, before I delve too deeply into this, has anyone else tried building
7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
cc
On Fri, 3 Dec 2004 01:43 pm, Michael Fuhr wrote:
gcc 3.4.2 on Solaris 9 doesn't complain about this.
Yes, I found Tom's response to the issue from March here:
http://archives.postgresql.org/pgsql-ports/2004-03/msg9.php
and this on the Sun CC forum, confirming that the compiler is borked:
Mike Mascari [EMAIL PROTECTED] writes:
Will ANALYZE continue to ignore columns whose data is composed entirely
of NULL in 8.0?
I had hoped to get to this before RC, but it looks like it won't happen.
Considering I've just been beating up on Bruce for committing stuff that
wasn't clearly a bug
Tom Lane wrote:
Mike Mascari [EMAIL PROTECTED] writes:
Will ANALYZE continue to ignore columns whose data is composed entirely
of NULL in 8.0?
I had hoped to get to this before RC, but it looks like it won't happen.
Considering I've just been beating up on Bruce for committing stuff that
In case anyone is interested, I've posted 8.0.0beta5 rpms here:
http://www.joeconway.com/postgresql-8.0.0beta/
Note that these are not official PGDG rpms, just my own home brew.
Also note that there is talk of an imminent RC1 -- hopefully I'll find
time to update the rpms within a day or so
While fixing the gui for pg_dump and pg_restore, I painfully noticed
there's no option for the password.
After some tests, I found that using the PGPASSWORD environment variable
will do the job. I'm a bit irritated that it's marked deprecated in
the docs, the .pgpass solution isn't a good one
Tom,
Your patch works for my test cases. Thanks to both you and Oliver for
getting this fixed.
--Barry
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 28, 2004 2:23 PM
To: Oliver Jowett
Cc: Barry Lind; [EMAIL PROTECTED]
Subject: Re: [HACKERS]
Please ignore- seems some old mail of mine got sent waaay late...
Christopher Kings-Lynne wrote:
While fixing the gui for pg_dump and pg_restore, I painfully noticed
there's no option for the password.
After some tests, I found that using the PGPASSWORD environment
variable will do the job. I'm
73 matches
Mail list logo
