| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: tsearch2 in PostgreSQL 8.3? |
| Date: | 2007-08-15 03:38:28 |
| Message-ID: | 46C27534.8080708@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian wrote:
>>
>> The people who actually use tsearch2 seem to all have the same opinion ...
>> so I think we can't go too far in the bullet-proofing direction.
>>
Yeah.
>> But I would like a design that is bulletproof in dump/reload scenarios,
>> and I think it's fair to question that aspect of the tsearch2 design
>> because we've seen many reports of people having trouble updating
>> databases that use tsearch2.
>>
>
> Yea, look at the trouble we are having trying to underestand it all.
True. But I wasn't too concerned about the forecast difficulties with
data only dumps. Those fail in plenty of circumstances. It is important
that there is *some* reliable dump/restore/upgrade path, though.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mike Rylander | 2007-08-15 03:46:55 | Re: default_text_search_config and expression indexes |
| Previous Message | Tom Lane | 2007-08-15 03:26:03 | Re: CVS corruption/mistagging? |