Hi Richard,
On Sat, Aug 19, 2006 at 09:49:41AM -0700, Richard Troy wrote:
> Hi Klaus,
>
> I must have missed the bug submitted about this, but as a student of
> German I took particular interest in your post.
>
I am sorry, I posted it with a bad sender address. I can't remember which one
i used
The following bug has been logged online:
Bug reference: 2592
Logged by: Robert Siemer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Linux
Description:ILIKE does not care about locales
Details:
Hi!
As I don't want to risk getting thin
The following bug has been logged online:
Bug reference: 2593
Logged by: Igor Urisman
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3
Operating system: Windows
Description:Improper implimentation of SQLException
Details:
The vendor error code is returned
The following bug has been logged online:
Bug reference: 2594
Logged by: Gin Indexes cause server to crash on Windows
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2 CVS-Aug 28
Operating system: Windows XP Pro
Description:Gin Indexes cause server to crash on
On Sun, Aug 27, 2006 at 12:58:00PM +, Robert Siemer wrote:
> Bug reference: 2592
> Logged by: Robert Siemer
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1.4
> Operating system: Linux
> Description:ILIKE does not care about locales
> Details:
>
> Hi!
Tino Schwarze <[EMAIL PROTECTED]> writes:
> On Sun, Aug 27, 2006 at 12:58:00PM +, Robert Siemer wrote:
>> I tried this with LC_COLLATE=C and the rest LC_...=es_ES.utf8
>>
>> dennisb from irc reported LC_everything=sv_SE.UTF-8 with version 8.1.0
>> having the same problems.
> I can confirm thi
On Tue, Aug 29, 2006 at 09:27:59AM -0400, Tom Lane wrote:
> Tino Schwarze <[EMAIL PROTECTED]> writes:
> > On Sun, Aug 27, 2006 at 12:58:00PM +, Robert Siemer wrote:
> >> I tried this with LC_COLLATE=C and the rest LC_...=es_ES.utf8
> >>
> >> dennisb from irc reported LC_everything=sv_SE.UTF-8
"Gin Indexes cause server to crash on Windows" <[EMAIL PROTECTED]> writes:
> CREATE TABLE test (
> vector tsvector NOT NULL
> );
> CREATE INDEX idx_test_vector ON test USING gin (vector);
> server closed the connection unexpectedly
It appears that building a gin index on an empty table fails on
Platform:
CentOS release 4.3 (Final) (Linux
2.6.9-34.EL)
Database version:
PostgreSQL 8.1.3 on i686-redhat-linux-gnu, compiled
by GCC gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)
Description:
One of cca 100 tables is partially corrupted.
An attempt to read or dump the data from the table i
"Filip Hrbek" <[EMAIL PROTECTED]> writes:
> dwhdb=# create temp table t_fct as select * from dwhdata_salemc.fct;
> SELECT
> dwhdb=# create temp table t_fct as select * from dwhdata_salemc.fct;
> server closed the connection unexpectedly
> This probably means the server terminated abnormall
No, I'm sure is it not a HW problem. I tested the same DB cluster on two
different machines. The error is exactly the same.
I can send you the cluster if you tell me how and where to send 30M file.
Thanks for reply
Filip Hrbek
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
"Filip Hrbek" <[EMAIL PROTECTED]> writes:
> No, I'm sure is it not a HW problem. I tested the same DB cluster on two
> different machines. The error is exactly the same.
Really?
> I can send you the cluster if you tell me how and where to send 30M file.
You can email it to me personally if you
Well, it's a corrupt-data problem all right. The tuple that's
causing the problem is on page 1208, item 27:
Item 27 -- Length: 240 Offset: 1400 (0x0578) Flags: USED
XMIN: 5213 CMIN: 140502 XMAX: 0 CMAX|XVAC: 0
Block Id: 1208 linp Index: 27 Attributes: 29 Size: 28
infomask: 0x09
Works great now - thanks for the quick fix.
Charlie
Teodor Sigaev wrote:
Fixed in HEAD, thank you
Tom Lane wrote:
"Gin Indexes cause server to crash on Windows" <[EMAIL PROTECTED]>
writes:
CREATE TABLE test (
vector tsvector NOT NULL
);
CREATE INDEX idx_test_vector ON test USING gin (vecto
Tom Lane wrote:
> The underlined word is a field length word that evidently should contain
> 8, but contains hex 8008. This causes the tuple-data decoder to step
> way past the end of the tuple and off into never-never land. Since the
> results will depend on which shared buffer the page happens
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The underlined word is a field length word that evidently should contain
>> 8, but contains hex 8008. This causes the tuple-data decoder to step
>> way past the end of the tuple and off into never-never land.
> Hmm, perhaps we could
On Sun, 27 Aug 2006, Igor Urisman wrote:
The following bug has been logged online:
Bug reference: 2593
PostgreSQL version: 8.1.3
Description:Improper implimentation of SQLException
Details:
The vendor error code is returned in getSQLState(), instead of getError().
At least this
17 matches
Mail list logo
