On Thu, 10 Apr 2008 23:26:28 -0400
Aidan Van Dyk [EMAIL PROTECTED] wrote:
And then anybody asking a question about the status of something gives
you a pedestal to show how nicely your tracker works.
If you think that is what I am after you obviously have no idea who are
you replying to. I
On Thu, 10 Apr 2008 23:23:20 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
I'm not saying Bruce is doing a bad job, far from it. I'm saying
the job is impossible.
I just wanted to correct the apparent impression that patches don't
get ignored here. Patches
Joshua D. Drake wrote:
On Thu, 10 Apr 2008 23:23:20 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
I'm not saying Bruce is doing a bad job, far from it. I'm saying
the job is impossible.
I just wanted to correct the apparent impression that patches
Hi!
i'm using a module for postgresql (8.2 and 8.3) which links with a
3rd-party library and calls a function from there which returns a
malloc()'ed string.
[it's a libunac, and unac_string() but the question is general]
there was a pg_unac-8.2.tar.gz tarball distributed on the net, which has
On Thu, Apr 10, 2008 at 07:28:29PM -0700, Vladimir Volovich wrote:
it worked fine with postgresql 8.2; with 8.3 it started segfaulting, and
it appeared that the reason is because in postgresql 8.3, the free is
a macro defined in
snowball/header.h:
#define free(a) pfree(a)
It does seem wrong.
... The really serious problem I've got with it is that
it'd foreclose the possibility of returning actual index keys from
btree
indexes, thus basically killing the usefulness of that idea. I'm
not
convinced it would offer enough gain to be worth paying that price.
I do not see the
Bernd Helmle [EMAIL PROTECTED] writes:
What happens to aliases when you change the encoding in the middle of
running one? Actually, come to think of it, what *does* happen to aliases
when the encoding changes??
Hmm? What happens if you are going to change your encoding within multiple
--On Donnerstag, April 10, 2008 22:48:24 +0100 Gregory Stark
[EMAIL PROTECTED] wrote:
Well I feel like storing a query and resending it later is something
predictable which will work reliably. Storing a psql input line and
reinterpreting it later is surely going to cause weird things to
On Fri, 2008-04-11 at 10:57 +0200, Hans-Juergen Schoenig wrote:
Hannu Krosing wrote:
A question to all pg hackers
Is anybody working on adding pipelining to set returning functions.
How much effort would it take ?
Where should I start digging ?
i asked myself basically the
On Fri, Apr 11, 2008 at 01:00:04PM +0300, Hannu Krosing wrote:
i asked myself basically the same question some time ago.
pipelining seems fairly impossible unless we ban joins on those
plugins completely.
Not really, just they have to be materialized before joins, or
streaming node has
It seems my fix for stat() broke cygwin, because it doesn't have
dosmaperr() available. The way I see it there are two ways to fix this:
1) Don't apply the stat fix for cygwin.
2) Make our dosmaperr() function be used on cygwin.
I don't know if the fix is actually needed on cygwin. Can someone
Hannu Krosing wrote:
BTW, I'm pretty sure I have figured out the method for storing minimal
required binary tree as an array, where adding each page adds exactly
one upper node. The node added is often not the immediate parent, but is
always the one needed for covering all nodes.
I just have to
Hannu Krosing wrote:
A question to all pg hackers
Is anybody working on adding pipelining to set returning functions.
How much effort would it take ?
Where should I start digging ?
i asked myself basically the same question some time ago.
pipelining seems fairly impossible unless we ban
On Fri, Apr 11, 2008 at 1:32 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
The apache group seems to say the patches are indeed ignored, rather
then just delayed --- for us, every patch does get a reply, however
delayed.
Bruce, I think that this comes back to the perception
Teodor, do you have any thoughts about exactly how you'd fix @@@ ?
I suppose that the recheck-need is not really a property of specific
tuples, but of a particular query, for that case. Where would you
want to detect that?
tsquery may include restriction by weight of search terms: 'sea
Tom Dunstan [EMAIL PROTECTED] writes:
The reason a tracker is better imo than a wiki is that a wiki still
needs someone to maintain an index page (or multiple index pages for
different queues), so there's still an opportunity for something to
fall through.
For the umpteenth time bug
On Fri, 11 Apr 2008 15:44:43 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
Proposing specific tools without a consensus on what that process is
putting the cart before the horse. You pick the tools to fit what you
want to do. We haven't decided what we want to do yet.
Personally I don't
Gregory Stark escribió:
Personally I don't think we *know* what we want to do and that's why the wiki
is a good interim tool. We'll see what info we need there and who needs to
fill it in and find out what tool will fit our needs.
+1. Let's learn what we need first, and find an appropriate
Gregory Stark [EMAIL PROTECTED] writes:
Personally I don't think we *know* what we want to do and that's why the wiki
is a good interim tool.
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with tracking commit-fest issues.
A year from now, we
Magnus Hagander [EMAIL PROTECTED] writes:
It seems my fix for stat() broke cygwin, because it doesn't have
dosmaperr() available.
Are you sure you aren't just missing an #include? The other places
where we call _dosmaperr don't seem to be protected by anything more
than #ifdef WIN32.
Teodor Sigaev [EMAIL PROTECTED] writes:
So, I planned to add pointer to bool to consistent method, so signature will
be
bool consistent( bool check[], StrategyNumber n, Datum query, bool
*needRecheck)
Returning value of needRecheck should be ignored for operation not marked by
RECHECK
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Personally I don't think we *know* what we want to do and that's why the
wiki
is a good interim tool.
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with tracking commit-fest
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In the projects I'm involved in, tends to be for used for both purposes ...
one
central location for everything ...
Yea, good point. I think our big question is what justification do we
have for doing things
Tom Lane wrote:
Perhaps it would be better to initialize needRecheck to the opclass
RECHECK flag value? If the consistent function does nothing, the
behavior is the same as before, but it can flip the flag in either
direction if it wants.
I remember that last spring, in the context of GIT,
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Perhaps it would be better to initialize needRecheck to the opclass
RECHECK flag value? If the consistent function does nothing, the
behavior is the same as before, but it can flip the flag in either
direction if it wants.
I
Well, I realized the idea of global prepared statements actually sucked,
so I set on another approach thanks to ideas from this list, this is
caching query plans.
First, let's see if there is low hanging fruit with the typical small,
often-executed queries that are so frequent on
(I've already said that I think the wiki is a great step forward,
FWIW, and I'm not in any way suggesting that we should just drop it
and pick my favorite issue tracker or anything. However, for those
interested in discussion about theoretical benefits and cons of the
different systems...)
On
Perhaps it would be better to initialize needRecheck to the opclass
RECHECK flag value? If the consistent function does nothing, the
behavior is the same as before, but it can flip the flag in either
direction if it wants.
I have not any objections. In this case (and preparing of rechecking
PFC wrote:
So, where to go from that ? I don't see a way to implement this without
a (backwards-compatible) change to the wire protocol, because the clients
will want to specify when a plan should be cached or not. Since the user
should not have to name each and every one of the
Tom Lane [EMAIL PROTECTED] writes:
The bug trackers I've dealt with haven't got much flexibility in this
respect either --- the sorts of global views you can get are entirely
determined by the tool. I'm fairly certain that a tracker designed around
the assumption that different entries are
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with tracking commit-fest issues.
A year from now, we might have enough experience to decide that some
more-rigidly-structured tool will do what we need, but we don't have
it today. We spent enough
On Sat, Apr 12, 2008 at 3:13 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
The bug trackers I've dealt with haven't got much flexibility in this
respect either --- the sorts of global views you can get are entirely
determined by the tool. I'm fairly
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with tracking commit-fest issues.
A year from now, we might have enough experience to decide that some
more-rigidly-structured tool will do what we need, but we don't have
it today. We spent enough
I wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I remember that last spring, in the context of GIT, you were worried
about the performance implication of preparing to recheck rows when no
rechecks are needed. I didn't quite buy that back then, but this would
have the same issue.
As
On Apr 11, 2008, at 9:30 AM, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Personally I don't think we *know* what we want to do and that's
why the wiki
is a good interim tool.
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with
[ Changing subject to draw people's attention ... ]
Teodor Sigaev [EMAIL PROTECTED] writes:
RECHECK flag could be removed.
Hmm, that's slightly more radical than I was considering, but it would
simplify matters wouldn't it? The only strong argument against it that
I can think of is that it'd
Alvaro Herrera [EMAIL PROTECTED] writes:
PFC wrote:
So, where to go from that ? I don't see a way to implement this without
a (backwards-compatible) change to the wire protocol, because the clients
will want to specify when a plan should be cached or not. Since the user
should not have to
Brendan Jurd [EMAIL PROTECTED] writes:
In Trac, if I just want to loosely associate several tickets together
I'd use *keywords*, e.g., put index am in the keywords list for
several tickets, and then they'll show up prominently when I search
for those terms.
As an aside, you've reminded me
On Fri, 11 Apr 2008 18:46:18 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
I would think an interface which presents you with *all* unclosed
bugs by default, perhaps organized in some way (keywords, milestones,
etc) would be more conducive to getting attention to everything.
I'm sure you can
Brendan Jurd [EMAIL PROTECTED] writes:
In Trac, if I just want to loosely associate several tickets together
I'd use *keywords*, e.g., put index am in the keywords list for
several tickets, and then they'll show up prominently when I search
for those terms.
Assuming you know what to search
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
RECHECK flag could be removed.
Hmm, that's slightly more radical than I was considering, but it would
simplify matters wouldn't it? The only strong argument against it that
I can think of is that it'd break user-defined opclasses ...
Gregory Stark wrote:
As an aside, you've reminded me about another thing that bothers me about
Bugzilla and RT. In both cases they seem to put a lot of focus around the idea
of searching bugs. I don't really get why.
Maybe it makes sense if you plan to be like Mozilla and have 8-year-old bugs
Alvaro Herrera [EMAIL PROTECTED] writes:
PFC wrote:
So, where to go from that ? I don't see a way to implement this without
a (backwards-compatible) change to the wire protocol, because the clients
will want to specify when a plan should be cached or not. Since the user
should not
I can think of is that it'd break user-defined opclasses ... but it's
not like we don't change the API for GIST/GIN support functions from
time to time anyway. Does anyone have any idea how many people are
Hmm. The biggest breakage of interface to indexes was a removing
pg_am.amconcurrent flag
Hi all,
I don't know if I can post a patch here (I did subscribe to
psql-patches but without success).
Well, working in the latest revision from CVS I added a feature for
psql to the command \d+, now it shows the object size as like as
\l+ show the database size.
I will be pretty glad with
Don't we need to change the GiST/GIN support function interface anyway,
to be able to return the recheck flag?
Now we choose - save compatibility or not.
We can save flag RECHECK and introduce optional needRecheck argument for
consistent function and new opclass can use new interface, old ones
Dickson dos Santos Guedes escribió:
Well, working in the latest revision from CVS I added a feature for
psql to the command \d+, now it shows the object size as like as
\l+ show the database size.
Added to May commitfest page, thanks.
--
Alvaro Herrera
Slightly offtopic. How to get benefit on tuple level ? For example,
we mark GiST tsearch index as lossy, while for not very big documents it's
actually exact and we could save a lot not rechecking them.
Oleg
On Fri, 11 Apr 2008, Teodor Sigaev wrote:
Teodor, do you have any thoughts about
What's left on Bruce's patch queue page is:
* Finishing out Heikki's patch to allow runtime determination of the
need to recheck an index condition. What's committed so far doesn't
yet have any actual use :-(. Although I intend to keep working on
that, it's clearly new development and hence not
On Fri, Apr 11, 2008 at 7:41 PM, Tom Lane [EMAIL PROTECTED] wrote:
Offhand I suspect
only the PostGIS project would be affected.
Just wanted to point out that I personnally use the capability to
remove the RECHECK of PostGIS opclass (I define a similar opclass
without the recheck) when I
Teodor Sigaev [EMAIL PROTECTED] writes:
Now we choose - save compatibility or not.
We can save flag RECHECK and introduce optional needRecheck argument for
consistent function and new opclass can use new interface, old ones will work
with RECHECK. Or we remove RECHECK and force opclasses to
Oleg Bartunov [EMAIL PROTECTED] writes:
Slightly offtopic. How to get benefit on tuple level ? For example,
we mark GiST tsearch index as lossy, while for not very big documents it's
actually exact and we could save a lot not rechecking them.
Won't that just fall out of this? Assuming the
On Apr 10, 2008, at 4:48 PM, Gregory Stark wrote:
Well I feel like storing a query and resending it later is something
predictable which will work reliably. Storing a psql input line and
reinterpreting it later is surely going to cause weird things to
happen.
Just for some examples off the
Guillaume Smet [EMAIL PROTECTED] writes:
Just wanted to point out that I personnally use the capability to
remove the RECHECK of PostGIS opclass (I define a similar opclass
without the recheck) when I enforce the SRID in the application:
To be blunt, that seems like a really bad idea, and I
On Fri, Apr 11, 2008 at 06:46:18PM +0100, Gregory Stark wrote:
As an aside, you've reminded me about another thing that bothers me about
Bugzilla and RT. In both cases they seem to put a lot of focus around the
idea of searching bugs. I don't really get why.
To be fair to RT, it's really
On Apr 11, 2008, at 12:54 PM, Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
In Trac, if I just want to loosely associate several tickets together
I'd use *keywords*, e.g., put index am in the keywords list for
several tickets, and then they'll show up prominently when I search
for
MvO == Martijn van Oosterhout writes:
it worked fine with postgresql 8.2; with 8.3 it started segfaulting,
and it appeared that the reason is because in postgresql 8.3, the
free is a macro defined in snowball/header.h: #define free(a)
pfree(a)
MvO It does seem wrong. Do you include that
On Fri, 11 Apr 2008, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
Slightly offtopic. How to get benefit on tuple level ? For example,
we mark GiST tsearch index as lossy, while for not very big documents it's
actually exact and we could save a lot not rechecking them.
Won't that
Tom Lane wrote:
What's left on Bruce's patch queue page is:
* Finishing out Heikki's patch to allow runtime determination of the
need to recheck an index condition. What's committed so far doesn't
yet have any actual use :-(. Although I intend to keep working on
that, it's clearly new
On Fri, Apr 11, 2008 at 9:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
To be blunt, that seems like a really bad idea, and I have not the
slightest hesitation about breaking your ability to do it. How
do you know that the recheck-need corresponds to what you are testing
on the application
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
In short, I think it's time to declare our first commit fest done.
OK, todo updated, but what about the Maintaining cluster order on
insert idea?
http://momjian.us/cgi-bin/pgpatches
The last item I see in the thread is some
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
In short, I think it's time to declare our first commit fest done.
OK, todo updated, but what about the Maintaining cluster order on
insert idea?
http://momjian.us/cgi-bin/pgpatches
The last item I see in
I'm leaning towards removing RECHECK because it'll allow simplification
I vote to do it.
I seem to recall that you had some plans for other incompatible changes
in the call conventions for GIST/GIN support functions, too. If
Right now we suggest only new feature which just extent interface.
Added to TODO:
* Allow functions to control the transaction state
http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php
---
Pavel Stehule wrote:
Hello,
I found lot of discus about this topic.
Vladimir Volovich [EMAIL PROTECTED] writes:
but please remove the #define free from snowball/header.h because, as
you said, it's wrong.
It's not wrong and it won't be removed. Please note the header comment
in that file:
* NOTE: this file should not be included into any non-snowball sources!
TL == Tom Lane writes:
TL It's not wrong and it won't be removed. Please note the header
TL comment in that file:
TL * NOTE: this file should not be included into any non-snowball
TL sources!
ok, i'll just include snowball/libstemmer/api.h or snowball/libstemmer/header.h
instead.
in
Alvaro Herrera wrote:
To implement this I propose keeping track of four additional pointers in
SnapshotData: next and prev in the registered list, and next and
prev in the active stack.
FWIW this does not work as proposed because one snapshot can be stored
as active more than once
[EMAIL PROTECTED] (Tom Lane) writes:
In short, I think it's time to declare our first commit fest done.
Congratulations!
As a pure observer in the matter, it has clearly been a somewhat
painful process, which must be tempered by the consideration that what
was being reviewed was pretty much a
We use RT here for our trouble ticket system and the dashboard
can easily be configured to display tickets based on any search
criteria and you can have multiple views on the same screen.
The search functionality can be viewed as the tool for configuring
your views into the system, for whatever
I think what he's referring to is persistently caching plans so that new
connections can use them. That makes a lot more sense if you have lots of
short-lived connections like a stock php server without persistent
connections
turned on or a connection pooler. You can prepare queries but they
PFC [EMAIL PROTECTED] writes:
And it is very easy to recognize a query we've seen before,
It's not so easy as all that. Consider search_path. Consider temp
tables.
The real problem here is entirely on the client side:
But, using prepared statements with persistent connections is
PFC [EMAIL PROTECTED] writes:
But, using prepared statements with persistent connections is messy,
because you never know if the connection is new or not, if it contains
already
prepared statements or not, you'd have to maintain a list of those statements
(named) for every query in
Heikki Linnakangas wrote:
* GIT (Grouped Index Tuple) indexes, which achieve index space savings
in btrees by having a single index tuple represent multiple heap tuples
[...]
Another issue is that we'd need to check how much of the use-case for
GIT has been taken over by HOT.
There is,
On Sat, Apr 12, 2008 at 3:46 AM, Gregory Stark [EMAIL PROTECTED] wrote:
As an aside, you've reminded me about another thing that bothers me about
Bugzilla and RT. In both cases they seem to put a lot of focus around the
idea
of searching bugs. I don't really get why.
Er, because pretty
74 matches
Mail list logo
