"Chad Wagner" <[EMAIL PROTECTED]> writes:
> Just a heads up, not sure if you guys are aware of it. But one of the
> Makefile's (src/backend/tsearch/Makefile) added by this patch breaks the
> "build out of source tree" feature of autoconf/automake. The problem is
> pretty straightforward, and afte
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I'm not sure if this is a sane way to set up a dictionary, but surely
> seg faulting is not the right thing to do. Should we throw an error on
> an empty dict file, or should we swallow it without crashing?
Offhand I'd say that an empty file is a le
On Tue, 21 Aug 2007, Tom Lane wrote:
After starting to document this stuff I'm wondering whether it really
makes sense to change the parser associated with a tsearch
configuration. The problem is that the new parser might have an
unrelated set of token types, but we don't do anything about upda
On Tue, 21 Aug 2007, Chris Browne wrote:
[EMAIL PROTECTED] (Tom Lane) writes:
The main thing that is lacking at the moment is documentation. The
stuff Bruce has been working on will be good introductory material,
but we've got basically zip in reference material. I'll do some work
on that ove
On Tue, 21 Aug 2007, Tom Lane wrote:
When you look at it, this is downright silly. Why don't we flatten
the two levels together and write something like
CREATE TEXT SEARCH DICTIONARY swedish (
TEMPLATE = snowball,
LANGUAGE = swedish,
STOPWORDS = swedish
);
Dictionary is a program w
Tom Lane wrote:
> There are a couple of naming issues that I left untouched while
> reviewing the tsearch patch, but wanted to bring up for discussion.
>
> One thing that had me confused for awhile is that the patch uses
> the word "template" in two different ways. The main use is that a
> "templ
Tom Lane wrote:
> After starting to document this stuff I'm wondering whether it really
> makes sense to change the parser associated with a tsearch
> configuration. The problem is that the new parser might have an
> unrelated set of token types, but we don't do anything about updating
> the confi
After starting to document this stuff I'm wondering whether it really
makes sense to change the parser associated with a tsearch
configuration. The problem is that the new parser might have an
unrelated set of token types, but we don't do anything about updating
the configuration's mappings.
Ensu
On 8/21/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> OTOH, if we do it as a compat package, we need to set a firm end-date on
> it, so we don't have to maintain it forever. Given the issues always at
> hand for doing such an upgrade, my vote is actually for ripping it out
> completely and take
Just a heads up, not sure if you guys are aware of it. But one of the
Makefile's (src/backend/tsearch/Makefile) added by this patch breaks the
"build out of source tree" feature of autoconf/automake. The problem is
pretty straightforward, and after adding $(srcdir) everything seems to be
fine.
I
Oleg Bartunov wrote:
> On Mon, 20 Aug 2007, Tom Lane wrote:
>
> > I've applied version 0.58 of the patch with a lot of further
> > editorializing. I feel fairly confident now in the code that interfaces
>
> Great ! Just checked and most things after trivial changes are working !
> We need to sum
[EMAIL PROTECTED] (Tom Lane) writes:
> The main thing that is lacking at the moment is documentation. The
> stuff Bruce has been working on will be good introductory material,
> but we've got basically zip in reference material. I'll do some work
> on that over the next couple of days, but there'
[EMAIL PROTECTED] ("Joshua D. Drake") writes:
> Alvaro Herrera wrote:
>> Joshua D. Drake wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Heikki Linnakangas wrote:
Joshua D. Drake wrote:
>
>>> I guess my point is, if the patch looks good and does not appear
>>> to hurt anyt
Version 0.4 of libpq param put and PGresult get functions.
Added support for inet and cidr, couple bug fixes. If you compile the
test file, make sure you link with the patched libpq.so.
Andrew
pg_param.tgz
Description: application/compressed
---(end of broadcast)---
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> I havn't any objections. "with map" was introduced when another options
> was existed - locale and default flag.
OK, I'll make that happen.
>> The other thing that was bugging me was that a lot of the dictionary
>> types have init options that are na
Version 0.4 of libpq param put and PGresult get functions.
Added support for inet and cidr, couple bug fixes. If you compile the
test file, make sure you link with the patched libpq.so.
Andrew
pg_param.tgz
Description: application/compressed
---(end of broadcast)---
I'm fooling around with tsearch, and bumped into a segfault, when using
a custom ispell dictionary with DictFile pointing to an empty file.
NISortDictionary assumes there's at least one word in the dictionary,
and crashes on line 941:
> Conf->AffixData[1] = pstrdup(Conf->Spell[0]->p.flag);
"COPY" instead of "TEMPLATE". Another thought here is that I'm
inclined to drop the "with map" option and just always copy the
source configuration exactly. If you don't want the map, the
only other information the source can provide is a parser name,
which you might as well just give directly.
>>> On Tue, Aug 21, 2007 at 1:12 PM, in message
<[EMAIL PROTECTED]>, Greg Smith
<[EMAIL PROTECTED]> wrote:
>
> The other thing I realized you haven't mentioned yet is what operating
> system you're using.
Linux version 2.6.5-7.286-bigsmp ([EMAIL PROTECTED]) (gcc version 3.3.3 (SuSE
Linux)) #
On Tue, 21 Aug 2007, Kevin Grittner wrote:
shared_buffers = 160MB
effective_cache_size = 5GB
bgwriter_lru_percent = 20.0
bgwriter_lru_maxpages = 200
bgwriter_all_percent = 10.0
bgwriter_all_maxpages = 600
checkpoint_segments = 10
The other thing I realized you haven't mentioned yet is what ope
Hello
>
> The other thing that was bugging me was that a lot of the dictionary
> types have init options that are named things like DictFile, AffFile,
> etc. As I mentioned before, I dislike the fact that these things are
> out in the filesystem rather than inside the database, and hope that
> th
Tom Lane wrote:
>> The memory management of the init functions looks weird. In spell.c,
>> there's this piece of code:
>
> I saw that and didn't care for it much, but didn't look into exactly
> what would be needed to get rid of it. (I did clean up another place
> that had a *global* magic contex
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I'm skimming through tsearch code, trying to understand it. I'd like to
> see more comments, at least function-comments explaining what each
> function does, what the arguments are etc. I can try to add them as I go
> as well, and send a patch.
Yes,
On 21-aug-2007, at 10:55, Alvaro Herrera wrote:
It might go in if it's correct. If you have an answer to all the
objections then there's no reason not to include it. But I must
admit I
didn't understand what was your answer to the above objection; care to
rephrase?
sorry, egg on my face,
There are a couple of naming issues that I left untouched while
reviewing the tsearch patch, but wanted to bring up for discussion.
One thing that had me confused for awhile is that the patch uses
the word "template" in two different ways. The main use is that a
"template" is an object encapsulat
Tom Lane wrote:
> I've applied version 0.58 of the patch with a lot of further
> editorializing. I feel fairly confident now in the code that interfaces
> between tsearch and the rest of the system, but a lot of the
> lowest-level "guts" of tsearch (mainly in src/backend/tsearch/*.c and
> src/back
Hi,
On Tue, 2007-08-21 at 20:04 +0400, Oleg Bartunov wrote:
> It was really hard task for all of us. It's pity I don't drink at all,
> but Teodor will drink the health of "text search in PostgreSQL"
> today .
Haha :) I'd drink Vodka today, with some of my friends. (I'll drink
Absolut, and I know
On Mon, 20 Aug 2007, Tom Lane wrote:
I've applied version 0.58 of the patch with a lot of further
editorializing. I feel fairly confident now in the code that interfaces
Great ! Just checked and most things after trivial changes are working !
We need to summarize changes and provide upgraide
On Tue, Aug 21, 2007 at 10:59:52AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> I get awarning from the following line in bison generated parse.h:
> >> #define TEXT 577
>
> > That's easy, change the terminal to TEXT_P on gram.y and keywords.c
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> I get awarning from the following line in bison generated parse.h:
>> #define TEXT 577
> That's easy, change the terminal to TEXT_P on gram.y and keywords.c.
Yeah, I was wondering if we'd have to do that with any of the new
k
Lodewijk Vöge escribió:
> On 19-aug-2007, at 12:38, Tom Lane wrote:
>
>> An additional problem with your proposal is that it fails to consider
>> other changes that might be happening concurrently -- eg, what if some
>> other backend deletes a source row after you copy it, and commits before
>> you
Magnus Hagander wrote:
> On Mon, Aug 20, 2007 at 09:23:25PM -0400, Tom Lane wrote:
> I get awarning from the following line in bison generated parse.h:
> #define TEXT 577
That's easy, change the terminal to TEXT_P on gram.y and keywords.c.
--
Alvaro Herrerahttp:
On Mon, Aug 20, 2007 at 09:23:25PM -0400, Tom Lane wrote:
> I've applied version 0.58 of the patch with a lot of further
> editorializing. I feel fairly confident now in the code that interfaces
> between tsearch and the rest of the system, but a lot of the
> lowest-level "guts" of tsearch (mainly
On 19-aug-2007, at 12:38, Tom Lane wrote:
An additional problem with your proposal is that it fails to consider
other changes that might be happening concurrently -- eg, what if some
other backend deletes a source row after you copy it, and commits
before
you do?
then the patch indeed faile
>>> On Tue, Aug 21, 2007 at 2:36 AM, in message
<[EMAIL PROTECTED]>, Greg Smith
<[EMAIL PROTECTED]> wrote:
> On Mon, 20 Aug 2007, Kevin Grittner wrote:
>
>> The problem went away completely when we used a very aggressive
>> background writer configuration, to put the dirty pages in front of the
Gabor Szabo wrote:
Hi,
I am writing a set of articles about Automated Testing in Open Source Software
http://www.szabgab.com/blog/2007/07/1183825266.html
As I would like to write about PostgreSQL as well I tried to setup the
BuildFarm client.
Here is the output:
$ ./run_build.pl --test
[16:44
Hi,
I am writing a set of articles about Automated Testing in Open Source Software
http://www.szabgab.com/blog/2007/07/1183825266.html
As I would like to write about PostgreSQL as well I tried to setup the
BuildFarm client.
Here is the output:
$ ./run_build.pl --test
[16:44:34] checking out sou
On Mon, Aug 20, 2007 at 10:50:49PM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > You broke my shiny new MinGW and Cygwin buildfarm members too :-)
>
> Yeah, I was just looking at that. I seem to recall that the
> fu01.o(.idata$3+0xc): undefined reference to `l
Tom Lane wrote:
> This patch was originally submitted before we realized that pg_stats
> failed to distinguish the effects of committed vs rolled-back
> transactions (which was fixed about three months ago); and we also
> recently fixed several other bugs such as losing stats data for shared
> cata
On Mon, 20 Aug 2007, Kevin Grittner wrote:
The problem went away completely when we used a very aggressive
background writer configuration, to put the dirty pages in front of the
OS file system right away, so that its algorithms and the controller
cache could deal with things before they got o
40 matches
Mail list logo
