I am having problems creating an Ispell-based text search dictionary for
Czech language.
Issuing the following command:
create text search dictionary czech_ispell (
template = ispell,
dictfile = czech_ispell,
affFile = czech_ispell
);
ends with
ERROR: syntax error
CONTEXT: line 25
Initializing the cluster with
initdb
--locale=C
--lc-ctype=en_US.UTF-8
--lc-messages=en_US.UTF-8
--lc-monetary=en_US.UTF-8
--lc-numeric=en_US.UTF-8
--lc-time=en_US.UTF-8
--encoding=UTF8
allows me to use my text search dictionary. Now it only remains to see
whether index creation wi
On 07/01/2017 11:31 PM, rajan wrote:
Hi,
I have a cloned repository of postgres and I want to compile the source for
*REL_10_BETA1* alone.
Or just go here and grab the tarball:
https://www.postgresql.org/ftp/source/v10beta1/
Following are the steps I am planning to do,
-> git checkout -b r
twoflower writes:
> I am having problems creating an Ispell-based text search dictionary for
> Czech language.
> Issuing the following command:
> create text search dictionary czech_ispell (
> template = ispell,
> dictfile = czech_ispell,
> affFile = czech_ispell
> );
> ends with
> ERROR
Sent from my iPad
> On Jul 2, 2017, at 10:06 AM, Tom Lane wrote:
>
> twoflower writes:
>> I am having problems creating an Ispell-based text search dictionary for
>> Czech language.
>
>> Issuing the following command:
>
>> create text search dictionary czech_ispell (
>> template = ispell,
Thanks, Adrian. Able to install 10beta1 successfully.
-
--
Thanks,
Rajan.
--
View this message in context:
http://www.postgresql-archive.org/Need-help-on-compiling-postgres-source-code-from-cloned-repo-tp5969667p5969696.html
Sent from the PostgreSQL - general mailing list archive at Nabble.
> On Jul 2, 2017, at 10:06 AM, Tom Lane wrote:
>
> twoflower writes:
>> I am having problems creating an Ispell-based text search dictionary for
>> Czech language.
>
>> Issuing the following command:
>
>> create text search dictionary czech_ispell (
>> template = ispell,
>> dictfile = czec
On Sat, Jul 1, 2017 at 8:55 PM, rajan wrote:
> Thanks, Jeff. That helps understanding it 50%.
>
> *Session 2* fails to UPDATE the record which is in *(0,2)* and this tuple
> is
> marked for deletion. It means that *(0,2) never exists* when Session 2 is
> trying to perform the update.
>
That it n
Tom Lane-2 wrote
> Presumably the problem is that the dictionary file parsing functionsreject
> anything that doesn't satisfy t_isalpha() (unless it matchest_isspace())
> and in C locale that's not going to accept very much.
That's what I also guessed and the fact that setting lc-ctype=en_US.UTF-8
Hi. I currently have a two-server BDR replication setup. Apart from the two
master nodes, I have another two servers which I want to have read only
replication for some tables only.
I first had to deal with some trouble regarding CREATE EXTENSION being
replicated by BDR, and that causing the sc
Thanks everyone. Sorry for the late reply.
Do you have indexes on all the referencing columns?
I had thought so, but it turns out no, and this appears to be the main
cause of the slowness. After adding a couple of extra indexes in the bigger
tables, things are going much more smoothly.
write
Hello :
PG VERSION : PPAS 9.3 , enterprisedb
os version : 2.6.32-358.el6.x86_64
pg_basebackup job was not performed by me. But I think it was executed
regularly.
Any switch or parameter would cause this issue ???
Why I don't think not a index curruption issue ?
1. I found
On Mon, Jul 3, 2017 at 10:08 AM, Steven Chang wrote:
> Hello :
Please avoid top-posting.
>PG VERSION : PPAS 9.3 , enterprisedb
>os version : 2.6.32-358.el6.x86_64
This is EnterpriseDB's fork of Postgres. Until it can be proved that a
corruption has happened using the community c
Dear Michael,
I know what you mean. We also mail the issue to EDB.
Post here is just to reply Timokhin's case and see could anyone give a
solution.
EDB's strength is just a orafce moudule enhancement to me,
and I don't think they could adapt a lot of kernel module codes.
Regards,
St
14 matches
Mail list logo
