Re: [BUGS] index bloat in 8.4-dev

[Heikki Linnakangas]

Jeff Davis wrote:

I see this problem on 8.3.3 now, too. Originally, I suppose my test was
not long enough, but now I see the problem after about 10 minutes of
running.


I ran the script for about 30 minutes on CVS HEAD, and the index didn't 
grow at all after the first three iterations. Are you sure you didn't 
have a long-running transaction open that prevented vacuum from working? 
Did the heap bloat as well, or just the index?


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] index bloat in 8.4-dev

[Jeff Davis]

On Tue, 2008-10-07 at 11:04 +0300, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > I see this problem on 8.3.3 now, too. Originally, I suppose my test was
> > not long enough, but now I see the problem after about 10 minutes of
> > running.
> 
> I ran the script for about 30 minutes on CVS HEAD, and the index didn't 
> grow at all after the first three iterations. Are you sure you didn't 
> have a long-running transaction open that prevented vacuum from working? 
> Did the heap bloat as well, or just the index?

In the VACUUM VERBOSE output I included, you can see that the heap is
only 785 pages (after 200M rows went through that table), and it
maintains that consistently. That means to me that the VACUUMs are
running and properly freeing the space in the heap. And the output seems
to indicate that it thinks it can re-use those index pages, it just
doesn't. 

This is a bit non-deterministic: the index pages will be steady for a
while, and then jump all of a sudden. Maybe it only happens when
resources are strained? I will try on a few other machines today and see
if I can identify the conditions a little more clearly.

Regards,
Jeff Davis



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #4454: LC_MESSAGES and LC_NUMERIC not working on Windows

[Rainer Bauer]

The following bug has been logged online:

Bug reference:  4454
Logged by:  Rainer Bauer
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system:   WinXPSP3
Description:LC_MESSAGES and LC_NUMERIC not working on Windows
Details: 

Hello,

This is an _ENGLISH_ Windows XPSP3 installation where the "Regional and
Language Options" have been set to "German (Germany)". The cluster was
initialized with locale "German_Germany".

The first problem is that I cannot change the messages returned from the
backend to English. Setting LC_MESSAGES has no effect. Renaming the
"~\share\locale\de" folder in the program installation was suggested here
. It
works, but this does not solve the problem that I consider to be a bug.

The next problem I am facing is that float data sent to the backend is not
accepted, because the comma separator is used in the program and the backend
expects a point separator.

I have read  and
. But
setting LC_NUMERIC has no effect: it always returns "1.3" instead of "1,3"
(see ouput from a psql console below).

So either I am doing something completely wrong or this is a bug.

Regards,

Rainer


Welcome to psql 8.3.4, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
   \h for help with SQL commands
   \? for help with psql commands
   \g or terminate with semicolon to execute query
   \q to quit

Warning: Console code page (850) differs from Windows code page (1252)
 8-bit characters might not work correctly. See psql reference
 page "Notes for Windows users" for details.

postgres=# select version();
   version
-
 PostgreSQL 8.3.4, compiled by Visual C++ build 1400
(1 row)

postgres=#   SHOW LC_MESSAGES;
  lc_messages

 German_Germany
(1 row)

postgres=#   SHOW LC_MONETARY;
  lc_monetary

 German_Germany
(1 row)

postgres=#   SHOW LC_TIME;
lc_time

 German_Germany
(1 row)

postgres=#   SHOW LC_NUMERIC;
   lc_numeric

 German_Germany
(1 row)

postgres=#   select 1.3::float;
 float8

1.3
(1 row)

postgres=#   SET LC_NUMERIC TO ''; select 1.3::float;
SET
 float8

1.3
(1 row)

postgres=#   SET LC_NUMERIC TO 'C'; select 1.3::float;
SET
 float8

1.3
(1 row)

postgres=#   SET LC_NUMERIC TO 'German_Germany'; select 1.3::float;
SET
 float8

1.3
(1 row)

postgres=#   SET LC_NUMERIC TO 'German_Germany.1252'; select 1.3::float;
SET
 float8

1.3
(1 row)

postgres=#

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] index bloat in 8.4-dev

[Jeff Davis]

On Tue, 2008-10-07 at 08:14 -0700, Jeff Davis wrote:
> In the VACUUM VERBOSE output I included, you can see that the heap is
> only 785 pages (after 200M rows went through that table), and it
> maintains that consistently. That means to me that the VACUUMs are
> running and properly freeing the space in the heap. And the output seems
> to indicate that it thinks it can re-use those index pages, it just
> doesn't. 

I think something may have been flawed in my simpler tests, so ignore
this.

I did see some kind of problem here in a more complex case, but I think
I'll have to narrow it down again.

Regards,
Jeff Davis


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs