The following bug has been logged online:
Bug reference: 4306
Logged by: Yishai Lerner
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: RHEL5 and MacOSX 10.4
Description:TSearch2 stemming, stop words and lexize behaviour
inconsistent
Detail
Hi,
Thank you for your kind answers and for not having killed me despite
the fact that I report a bu^H^H documented feature. It had no impact
on me since there's an easy workaround to this behaviour (like you
reported), I just really thought it was a bug...
Sorry guys,
Thibauld
2008/7/8 Tom Lane
Dnia poniedziałek, 14 lipca 2008, Tom Lane napisał:
> =?iso-8859-2?q?Micha=B3_Szel=B1g?= <[EMAIL PROTECTED]> writes:
> > the crash occurs by this command in my dump:
> >
> > COPY users_history (users_history_id, users_id, uh_date,
> > uh_php_session_id, uh_gpsc, uh_ip, uh_browser, uh_referer, uh_ur
=?iso-8859-2?q?Micha=B3_Szel=B1g?= <[EMAIL PROTECTED]> writes:
> Dnia poniedzia³ek, 14 lipca 2008, Tom Lane napisa³:
>> You still haven't given anywhere near enough information to identify the
>> bug. I wonder though if any of these tables involve non-built-in
>> datatypes? An out-of-date .so fil
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Thomas H. wrote:
> >> so at least that explains the "changed" behaviour. nevertheless,
> >> LC_MESSAGES seems to be defunct - with the "locale" folder present,
> >> pg always picks the os' language and ignores the lc_message value.
Hi,
Environment used:
Postgres 8.3.1
psqlODBC 08.03.0200
Testcase:
In the postgres database there is table 'COUNTER_TABLE' with column
integer type 'COUNTER'. The test application attached in this mail, will
start a transaction, gets the current value in the COUNTER, increments
the value and
Hi,
I am running PostgreSQL 8.3.3 on Linux 2.6.18
[EMAIL PROTECTED]:~/z$ uname -a
Linux io.mills.lan 2.6.18-6-vserver-k7 #1 SMP Sat Jun 7 01:10:29 UTC
2008 i686 GNU/Linux
Short version of the problem:
When I run a full-text search that requires a full scan of the table,
an error is returned (GIN
The following bug has been logged online:
Bug reference: 4307
Logged by: Oskars Ozols
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: SuSE Linux Enterprise Server
Description:INSERT fails with primary key contraint
Details:
I have followin
"K, Niranjan (NSN - IN/Bangalore)" <[EMAIL PROTECTED]> writes:
> In the postgres database there is table 'COUNTER_TABLE' with column
> integer type 'COUNTER'. The test application attached in this mail, will
> start a transaction, gets the current value in the COUNTER, increments
> the value and up
"Oskars Ozols" <[EMAIL PROTECTED]> writes:
> I have noticed that during high load Postgre starts to use old free sequence
> values (like 156112 in my sample). Sometimes it's ok, but sometimes it fails
> with error above.
This is fairly hard to believe; the sequence code was debugged years
ago. Pa
"Oskars Ozols" <[EMAIL PROTECTED]> writes:
> id bigint NOT NULL DEFAULT
> nextval(('public.event_log_id_seq'::text)::regclass),
> 2008-07-15 12:32:03 EEST STATEMENT: INSERT INTO public.event_log
> (date_time, ip_address, action_type, severity, parameters, web_address,
> server, user_id, id)
Currently the test application or the psql will unblock after ~15
minutes. This is a very huge time to realize for programs this situation
which do database updates.
As far as I have debugged, I see that the execution is waiting on
'poll()' system call in the function pqSocketPoll() which is called
12 matches
Mail list logo
