Bruce Momjian wrote:
Why aren't more people involved? Is this such a thankless task? I
am starting to think so.
I can tell you exactly what my problem is. The tools are terrible. In
projects with a useful issue tracking system I can take small chunks
out of my day to contribute to
Joshua D. Drake wrote:
http://pgbugs.commandprompt.com (still need to configure email).
Thank you for that.
I think an issue tracking system for patches and such may need to be
distinct from a bug-tracking system such as bugzilla, but let's get one
thing after another up.
--
Peter
I've rigged up a simple simulator for the scheme I described for detecting
pseudo-constant parameters to prepared statements. It withstands simple
tests, and it neatly picks up cases where some parameters are
pseudo-constants and others aren't--even if some of them are more pseudo
while others
On Sep 1, 2006, at 9:32 , Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
On Sep 1, 2006, at 9:12 , Tom Lane wrote:
I agree that this seems like an oversight in the original
months/days/seconds patch, rather than behavior we want to keep.
But is DecodeInterval the only place
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
For now, I'll summarize some results I got from randomized input data. I
used very simple traces, with 11 prepared statements, each taking a
different number of parameters (0 through 10, inclusive). All calls were
uniformly randomized. I used
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
ALL does not need this to work for 2G tables).
Already done because of bad coding. You want the TODO item removed too?
As I said, I see no
On Sun, September 3, 2006 18:41, Gregory Stark wrote:
I'm confused, what exactly are you trying to predict? Whether each
parameter
will be some cached value? Or whether the cached plan was correct?
That's described in more detail in a separate thread (prepared statements
considered harmful).
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
On Sun, September 3, 2006 18:41, Gregory Stark wrote:
I'm confused, what exactly are you trying to predict? Whether each
parameter
will be some cached value? Or whether the cached plan was correct?
That's described in more detail in a separate
Peter Eisentraut wrote:
Joshua D. Drake wrote:
http://pgbugs.commandprompt.com (still need to configure email).
Thank you for that.
I think an issue tracking system for patches and such may need to be
distinct from a bug-tracking system such as bugzilla, but let's get one
thing after
On Sat, 2 Sep 2006, Bruce Momjian wrote:
Teodor Sigaev wrote:
What does that option do? Is it practical to enable it for the entire
backend?
From docs:
Disables inline expansion of standard library or intrinsic functions.
And isn't this a straightforward compiler bug they should be
Andrew Dunstan wrote:
Tom Lane wrote:
The buildfarm script is supposed to complain about unexpected files in
the repository --- I wonder if it is fooled by the .cvsignore entries
for these files?
Yes, we do. A patch made in July 2005 has this comment:
ignore files listed in cvsignore
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I added a subxid array to Snapshot and running subxids are gathered from
PGPROC-subxids cache. There are two overflowed case; any of PGPROC-subxids
are overflowed or the number of total subxids exceeds pre-allocated buffers.
If overflowed, we cannot
Alvaro Herrera [EMAIL PROTECTED] writes:
OTOH I think we only need to store live Xids and those finished that
wrote a WAL record; we can drop subaborted and subcommitted if they
didn't.
While reviewing this thread, I see Alvaro already had the idea I just
came to...
On Sun, September 3, 2006 21:52, Gregory Stark wrote:
I read that but apparently I misunderstood it since it would not have been
doable the way I understood it. I thought you wanted the predictor bits to
correspond to particular plans. If a plan was wrong then you marked it
as a
bad guess. I
Tom Lane wrote:
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
For example I have no expertise in coding on Postgres, but I think I
would be able to collect information from this mailinglist (like specs,
url's etc.) and put them in some issue tracker or wiki. I have done
exactly the same
On Sun, September 3, 2006 23:28, Jeroen T. Vermeulen wrote:
On Sun, September 3, 2006 21:52, Gregory Stark wrote:
I read that but apparently I misunderstood it since it would not have
been
doable the way I understood it. I thought you wanted the predictor bits
to
correspond to particular
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
If multiple cached plans can be applied to a given call, we prefer the one
that optimizes away the most parameters.
What exactly do you mean by optimize away a parameter? The way you
described the mechanism, there are no parameters that are
Awhile back I complained that while all the core geometric datatypes
use operator @ to mean contained in and operator ~ to mean contains,
contrib/cube and contrib/seg switch the meanings:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01238.php
There was some followup discussion
I can see various things that we might consider doing:
1. Just flip the names of the two operators added by the GIN patch.
2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points out that contrib/intarray is out
of step too ... are there
On Sun, 3 Sep 2006, Joshua D. Drake wrote:
I can see various things that we might consider doing:
1. Just flip the names of the two operators added by the GIN patch.
2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points out that
Oleg Bartunov wrote:
On Sun, 3 Sep 2006, Joshua D. Drake wrote:
I can see various things that we might consider doing:
1. Just flip the names of the two operators added by the GIN patch.
2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points
Joshua D. Drake wrote:
I just spent 1/2 hour fixing the multi-value UPDATE
patch for the code drift caused by UPDATE/RETURNING. The patch is a
simple grammar macro. Any coder could have taken that, reviewed it, and
applied it, but no one did.
Perhaps that's because nobody but you
bruce wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter has made it pretty clear that he didn't care for the
refactorization aspect of that patch.
Peter asked why it was done, a good answer was given, and Peter did not
reply.
Au
Oleg Bartunov oleg@sai.msu.su writes:
3. Leave the existing op names as-is in core and contrib, but consider
them deprecated and add new ops with consistently-chosen names.
(The new ops introduced by GIN should only exist with the new names.)
#3 looks good to me. Too many users.
Not only
Bruce Momjian wrote:
Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the if no
one objects, I'll just commit it mode that is sometimes going on.
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
Oh, sorry--I guess I haven't been too systematic about it. In the
algorithm's current incarnation, ...
Thanks, that cleared things up enormously. I'm trying to figure how it would
react to some of the queries I've written in the past. In
On Sun, Sep 03, 2006 at 03:40:40PM -0400, Bruce Momjian wrote:
This is also an interesting example for a tracker. If we had one, all
discussion on the patch would be in one place, but I am thinking that
would require all posting to happen in a browser, or somehow have emails
tagged to attach
On Sat, Sep 02, 2006 at 11:46:12PM +0100, Dave Page wrote:
Sounds reasonable to me.
Ok, I've typed some stuff in here:
http://developer.postgresql.org/index.php/Todo:Contents
http://developer.postgresql.org/index.php/Todo:Collate
Is this the kind of thing people are expecting?
Have a nice
I see that older back branches are still using version 2.53 of autoconf,
rather than the 2.59 branch we have updated to for 8.1 and beyond. Does
that mean I need to install version 2.53 if I want to update the config
on those branches? If so, fixing the plpython problem I reported
recently
Martijn van Oosterhout kleptog@svana.org writes:
I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
The weakest of them will send a content-free email saying *something* happened
to your issue and you have to click a
Gregory Stark wrote:
Martijn van Oosterhout kleptog@svana.org writes:
I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
The weakest of them will send a content-free email saying *something* happened
to
Tom Lane wrote:
Awhile back I complained that while all the core geometric datatypes
use operator @ to mean contained in and operator ~ to mean contains,
contrib/cube and contrib/seg switch the meanings:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01238.php
There was some followup
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces, I
think Tom's recent remarks relating to the 21st century were more than
apposite.
I like web interfaces well enough for the things they're good at.
Replacing e-mail is not one
I also vote +1 for #3. Not only are there too many users, but simply
switching the sense of these operators will mean that code will still run,
but give incorrect answers and while it would be nice to think that all
client code has decent regression testing, this ain't the case.
If we are going
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
For some reason I expected this patch to correct the portability errors
and design problems identified here:
http://archives.postgresql.org/pgsql-patches/2006-07/msg00100.php
Not only has it not fixed anything, it's made things
Andrew Dunstan [EMAIL PROTECTED] writes:
How about?:
4. do 1+3, i.e. flip the GIN operators to keep core consistency, but
deprecate the operators for both contrib and core. Something more
visually like set ops would be ideal.
If we're going to adopt new preferred names, I see no reason to
Andrew Dunstan wrote:
I see that older back branches are still using version 2.53 of
autoconf, rather than the 2.59 branch we have updated to for 8.1 and
beyond. Does that mean I need to install version 2.53 if I want to
update the config on those branches?
Yes.
If so, fixing the plpython
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
information --- they're good
Tom Lane wrote:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic
-I. -I../../src/include -D_GNU_SOURCE -c -o pgstatindex.o pgstatindex.c
pgstatindex.c: In function 'bt_page_items':
pgstatindex.c:564:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
information
On Sep 3, 2006, at 20:00 , Michael Glaesemann wrote:
On Sep 1, 2006, at 9:32 , Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
On Sep 1, 2006, at 9:12 , Tom Lane wrote:
I agree that this seems like an oversight in the original
months/days/seconds patch, rather than behavior
Tom Lane wrote:
I can see various things that we might consider doing:
1. Just flip the names of the two operators added by the GIN patch.
2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points out that contrib/intarray is out
of step too
Michael Glaesemann [EMAIL PROTECTED] writes:
I realized there might be something in ecpg, and there was. I've
updated the ecpg DecodeInterval to match. However, I haven't been
able to get ecpg make check to work, so that part's untested.
This patch fails to apply --- looks like whitespace
On Sep 4, 2006, at 9:41 , Tom Lane wrote:
This patch fails to apply --- looks like whitespace got mangled in
transit. Please resend as an attachment.
Please let me know if you have any problems with this one.
Michael Glaesemann
grzm seespotcode net
10interval_input_0904T0855+0900.diff
Mark Dilger [EMAIL PROTECTED] writes:
I suggest: #4 Standardize on new names and completely drop old naming
scheme, both in core and in contrib.
Deliberately breaking code that has always worked doesn't sound very
appetizing to me. If there were simply no good alternative to it, then
maybe,
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
How about?:
4. do 1+3, i.e. flip the GIN operators to keep core consistency, but
deprecate the operators for both contrib and core. Something more
visually like set ops would be ideal.
If we're going to adopt new preferred
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
Michael Glaesemann [EMAIL PROTECTED] writes:
On Sep 4, 2006, at 9:41 , Tom Lane wrote:
This patch fails to apply --- looks like whitespace got mangled in
transit. Please resend as an attachment.
Please let me know if you have any problems with this one.
Ah, that one works --- applied. A
Tom Lane wrote:
You mentioned being unable to get the ecpg tests to run on your
machine. I'm sure Michael and Joachim would like the details. The
ecpg regression tests are pretty new and some portability problems
are to be expected, but they seem to be passing on all the machines
Michael and
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I see that older back branches are still using version 2.53 of autoconf,
rather than the 2.59 branch we have updated to for 8.1 and beyond. Does
that mean I need to install version 2.53 if I want to update the config
on those
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
The two attached patches fix contrib/pgstattuple.
Good, applied. I made some additional changes to get install/uninstall/
reinstall to work cleanly after the latest additions, and to get it to
compile without warnings on a 64-bit Fedora machine. (It
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Ideally, we would get Python to tell us the right location, because use lib64
if it exists isn't the right solution.
Is this fixed somewhere post 7.4?
Yes, but it was never backported.
Peter Eisentraut wrote:
Bruce Momjian wrote:
Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the if no
one objects, I'll just commit it mode
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sun, Sep 03, 2006 at 03:40:40PM -0400, Bruce Momjian wrote:
This is also an interesting example for a tracker. If we had one, all
discussion on the patch would be in one place, but I am thinking that
would require all posting
Gregory Stark wrote:
Martijn van Oosterhout kleptog@svana.org writes:
I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
Oh. That is bad.
The weakest of them will send a content-free email saying *something*
Satoshi Nagayasu [EMAIL PROTECTED] writes:
Tom Lane wrote:
pgstatindex.c: In function 'bt_page_items':
pgstatindex.c:564: warning: format '%d' expects type 'int', but argument 4
has type 'long unsigned int'
I guess my '%d' should be '%zd', right?
No, that sounds even less portable :-(
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
On Sep 4, 2006, at 9:41 , Tom Lane wrote:
This patch fails to apply --- looks like whitespace got mangled in
transit. Please resend as an attachment.
Please let me know if you have any problems with this one.
Ah, that one
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I do
PATH=/usr/local/autoconf-2.53/bin:$PATH autoconf
when I need to update back-branch configure scripts.
Ah! Thanks! What had failed for me was just running with
/path/to/old/autoconf - this one works however. Strange that a
[EMAIL PROTECTED] (Tom Lane) wrote:
I agree with planning to arrive at state #4 after a transitional release
or three, but to do it now with no warning will simply bring us visits
from angry pitchfork-bearing villagers...
But then we can send out Trogdor...
Trogdor!
Trogdor!
Burninating the
Bruce Momjian [EMAIL PROTECTED] writes:
Oh, so the bug is tracked by being part of the email reply list. That
is a good idea. Now, how does that get assigned for non-bugs, like
patches? Does any email sent to the lists that doesn't already have a
bug number get one? That might be really
Bruce Momjian wrote:
Oh, so the bug is tracked by being part of the email reply list. That
is a good idea. Now, how does that get assigned for non-bugs, like
patches? Does any email sent to the lists that doesn't already have a
bug number get one? That might be really valuable.
It
Andrew Dunstan [EMAIL PROTECTED] writes:
Anyway, let me reiterate: bz has at least the start of an email reply
facility, and making that work if it doesn't already should not be
beyond us.
I agree that starting from scratch seems like a good way to waste a
lot of time. I don't have a
Tom Lane wrote:
AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Oh, so the bug is tracked by being part of the email reply list. That
is a good idea. Now, how does that get assigned for non-bugs, like
patches? Does any email sent to the lists that doesn't already have a
bug number get one?
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I am assuming we would not be including
The world rejoiced as [EMAIL PROTECTED] (Joshua D. Drake) wrote:
Christopher Browne wrote:
Oops! [EMAIL PROTECTED] (Jim C. Nasby) was seen spray-painting on a wall:
On Thu, Aug 31, 2006 at 10:33:36AM -0400, Chris Browne wrote:
What's up there? It has been down all week.
We're trying to get
The *big* steps are moving email and CVS.
*big* but quite easy :) As long as we have an mbox file from the slony
lists, we can import easily into pgfoundry.
CVS is just an rsync ;)
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I am assuming we
Andrew Dunstan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I
Hello,
O.k. I have installed the stable bugzilla at:
http://pgbugs.commandprompt.com/
I would expect that this domain would change to:
http://bugs.postgresql.org/ or something
It is backed to a PostgreSQL 8.1 database and anyone can now create
accounts.
Now what I need.
I need a couple
This is not that far different from the premise upon which you built
the buildfarm: that there were people out there able to provide machine
resources and a certain amount of admin time. The resources this
project requires are not those exactly, but why shouldn't we expect
that some people
Martijn van Oosterhout said:
Ok, it looks like pages can be arranged hierarchically.
Well, a prefix like Todo: is not the incantation one needs to use to
arrange pages in hierarchies. You probably want / to indicate a subpage:
i.e. Parent/Child. See
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
3. Leave the existing op names as-is in core and contrib, but consider
them deprecated and add new ops with consistently-chosen names.
(The new ops introduced by GIN should only exist with the new names.)
You're right. I misread
[Removing -patches]
On Sep 4, 2006, at 10:33 , Tom Lane wrote:
* AFAICT the ecpg regression tests are not affected by this change.
Yeah, it doesn't look like there's any tests for interval at all. I
suppose there should be. There's a lot of duplicate code in ecpg. Is
there any way to
Michael Glaesemann [EMAIL PROTECTED] writes:
There's a lot of duplicate code in ecpg.
No kidding :-(. The parser is bad enough but the datatype library is
an order of magnitude worse. I don't have a great solution at hand
though. The backend utils/adt/ code gets to rely on the backend's
Michael Glaesemann [EMAIL PROTECTED] writes:
For the record, the error I'm getting is
Makefile:3: ../../../src/Makefile.global: No such file or directory
make: *** No rule to make target `../../../src/Makefile.global'. Stop.
From which Makefile exactly? Sounds like a pretty vanilla VPATH
On Sun, September 3, 2006 23:52, Tom Lane wrote:
What exactly do you mean by optimize away a parameter? The way you
described the mechanism, there are no parameters that are optimized
away, you've merely adjusted selectivity predictions using some assumed
values.
I'm using optimized away as
On Mon, September 4, 2006 03:56, Gregory Stark wrote:
Thanks, that cleared things up enormously. I'm trying to figure how it
would
react to some of the queries I've written in the past. In particular I'm
thinking of queries like
WHERE (? OR category = ?)
AND (? OR cost ?)
AND (? OR
79 matches
Mail list logo
