Re: [BUGS] BUG #5722: vacuum full does not update last_vacuum statistics

2011-02-27 Thread Bruce Momjian
Tom Lane wrote:
> Jochen Erwied  writes:
> > Monday, October 25, 2010, 4:12:39 PM you wrote:
> >> "Jochen Erwied"  writes:
> >>> VACUUM FULL does not update statistics so display of pg_stat_user_tables 
> >>> is
> >>> wrong. A normal VACUUM updates the relevant information.
> 
> >> Hmm.  This is a definitional issue: what do we really mean by last_vacuum?
> >> I'm inclined to think that the current behavior is reasonable.  VACUUM
> >> FULL is (still) not intended as a routine maintenance operation, and
> >> the point of that column is to track routine maintenance operations.
> 
> > Well, when reading 
> > http://www.postgresql.org/docs/current/static/monitoring-stats.html 
> > then last_vacuum contains the last time of a user-initiated vacuum. There's 
> > no distinction made what kind of vacuum was made. And IMHO even if VACUUM 
> > FULL isn't meant for routine vacuuming, the state should be changed.
> 
> Perhaps.  The new implementation of VACUUM FULL is really more like a
> CLUSTER, or one of the rewriting variants of ALTER TABLE.  Should all
> of those operations result in an update of last_vacuum?  From an
> implementation standpoint it's difficult to say that only some of them
> should, because all of them result in a table that has no immediate
> need for vacuuming.  The only argument I can see for having only VACUUM
> FULL update the timestamp is that it's called VACUUM and the others
> aren't.  Which is an argument, but not a terribly impressive one IMO.
> 
> > Of course the easiest way to fix this bug (or better flaw) is to change the
> > documentation :-)
> 
> Yeah, that part of the docs will require editing no matter what we do.
> I'm just trying to get some clarity on what the most reasonable behavior
> is.

I have updated the documentation to say that vacuum statistics and
counts are for non-FULL vacuums;  applied patch attached.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 2dc1bfc..aaa613e 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -325,11 +325,11 @@ postgres: user database host FULL vacuumed manually,
   the last time it was vacuumed by the autovacuum daemon,
   the last time it was analyzed manually,
   the last time it was analyzed by the autovacuum daemon,
-  number of times it has been vacuumed manually,
+  number of times it has been non-FULL vacuumed manually,
   number of times it has been vacuumed by the autovacuum daemon,
   number of times it has been analyzed manually,
   and the number of times it has been analyzed by the autovacuum daemon.
@@ -781,7 +781,7 @@ postgres: user database host pg_stat_get_last_vacuum_time(oid)
   timestamptz
   
-   Time of the last vacuum initiated by the user on this table
+   Time of the last non-FULL vacuum initiated by the user on this table
   
  
 
@@ -814,7 +814,7 @@ postgres: user database host pg_stat_get_vacuum_count(oid)
   bigint
   
-   The number of times this table has been vacuumed manually
+   The number of times this table has been non-FULL vacuumed manually
   
  
 

-- 
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 #5901: Delayed Write Failed

2011-02-27 Thread Gie Rizkiadi

The following bug has been logged online:

Bug reference:  5901
Logged by:  Gie Rizkiadi
Email address:  gie05t...@yahoo.co.id
PostgreSQL version: 8.4.1
Operating system:   Microsoft Windows XP Embedded Version 2002 Service Pack
2
Description:Delayed Write Failed
Details: 

I have installed PostgreSQL 8.4.1 running on 112 Embedded PC OS Microsoft
Windows XP Embedded Version 2002 Service Pack 2 Intel(R) Atom(TM) CPU N270
@1.60 GHz 1.32 GHz, 0.99 GB of RAM and 8GB Harddisk ( 6GB Free ) which are
connected to LAN, most of that during network problems or disconnected
causes PostgreSQL services suddenly stop and cannot start anymore even
manually, the taskbar shows Windows Delayed Write Failed. Is anyone know
what cause of this and how to solve this ?


Thanks GR

-- 
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] Delayed Write Failed

2011-02-27 Thread Gie Rizkiadi
Same problem here ..

I have installed PostgreSQL 8.4.1 running on 112 Embedded PC OS Microsoft
Windows XP Embedded Version 2002 Service Pack 2 Intel(R) Atom(TM) CPU N270
@1.60 GHz 1.32 GHz, 0.99 GB of RAM and 8GB Harddisk ( 6GB Free ) which are
connected to LAN, most of that during network problem / disconnected causes
PostgreSQL services suddenly stop and cannot start anymore, the taskbar
shows Windows Delayed Write Failed. What cause of this and how to solve this
?


Thanks GR

-- 
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Delayed-Write-Failed-tp2130027p3402743.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.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] BUG #5901: Delayed Write Failed

2011-02-27 Thread John R Pierce

On 02/27/11 7:13 PM, Gie Rizkiadi wrote:

I have installed PostgreSQL 8.4.1 running on 112 Embedded PC OS Microsoft
Windows XP Embedded Version 2002 Service Pack 2 Intel(R) Atom(TM) CPU N270
@1.60 GHz 1.32 GHz, 0.99 GB of RAM and 8GB Harddisk ( 6GB Free ) which are
connected to LAN, most of that during network problems or disconnected
causes PostgreSQL services suddenly stop and cannot start anymore even
manually, the taskbar shows Windows Delayed Write Failed. Is anyone know
what cause of this and how to solve this ?


you can not run a database server on unreliable network storage.  you 
really shouldn't run a database server on any sort of network file 
shared storage (SMB/CIFS, etc).


Delayed Write means the operating system has cached data in memory that 
its unable to write to the disk, so it doesn't know what to do since it 
already told the application that it was OK to continue.




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