release note missing

Hi all,
I want avice you that the interactive and as well
the static documentation of postgres 7.4
is missing 7.4.1 and 7.3.5 release note.

And the documentation of 7.3 is missing
the release note 7.3.1 -> 5

Regards
Gaetano mendola

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

HELP! Passwords stuck in passwd file!

I am migrating from 7.2 -> 7.4.  I can't figure out how to move the
crypt()'ed passwords I made with pg_password utility into the pg_shadow
table.  All I can find in the documentation is (in 7.3 release notes)

 Remove secondary password file capability and pg_password utility
  (Bruce)

Any ideas besides "re-enroll your users"?

Thanks,

Michael

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org

Re: Forcing connections closed

>'kill -9' PID will force all backends to flush cache for no good reason.
>
>Note that on most unixes, a plain kill PID will send the term signal, 
>which tells the process to poltely shutdown and release resources.  kill 
>-9 is like using a sledge hammer to swat a fly for this.
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>
>  
>
 Yes, you are on the right. "kill -9", is the last try, but often you 
have to do "kill -9" for killing a procces, even sometimes, 'kill -9' 
does not work (often when the process is acceding to a hardware device - 
a CD for example -).

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

Re: HELP! Passwords stuck in passwd file!

Michael Allman wrote:
> I am migrating from 7.2 -> 7.4.  I can't figure out how to move the
> crypt()'ed passwords I made with pg_password utility into the pg_shadow
> table.  All I can find in the documentation is (in 7.3 release notes)
> 
>  Remove secondary password file capability and pg_password utility
>   (Bruce)

If I remember correctly, you can't.  We now perfer MD5, where we can
store the information encrypted in the database, and use random salt
over the wire.

We cant unencrypt the crypt values so unfortunately you have to reenter
them.  You can do it using ALTER USER now.

--

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman <at> candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org

Re: HELP! Passwords stuck in passwd file!

As a matter of fact, I was able to "hack" passwd file support back in.
It wasn't too hard, but if anyone is interested in seeing the patch,
e-mail me privately.

Michael

On Sun, 1 Feb 2004, Bruce Momjian wrote:

> Michael Allman wrote:
> > I am migrating from 7.2 -> 7.4.  I can't figure out how to move the
> > crypt()'ed passwords I made with pg_password utility into the pg_shadow
> > table.  All I can find in the documentation is (in 7.3 release notes)
> >
> >  Remove secondary password file capability and pg_password utility
> >   (Bruce)
>
> If I remember correctly, you can't.  We now perfer MD5, where we can
> store the information encrypted in the database, and use random salt
> over the wire.
>
> We cant unencrypt the crypt values so unfortunately you have to reenter
> them.  You can do it using ALTER USER now.
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman <at> candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
>

Re: HELP! Passwords stuck in passwd file!

Michael Allman wrote:
> As a matter of fact, I was able to "hack" passwd file support back in.
> It wasn't too hard, but if anyone is interested in seeing the patch,
> e-mail me privately.

Yes, sorry I make problems for you by removing it, but that whole are
needed an overhaul and keeping it in just added to the confusion.

--

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman <at> candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

$PGDATA/global hosed but database still there ... what to do?

Re: Routine maintenance - vacuum, analyse and autovacuum

> Just moving from 7.1 to 7.4 should help, since you can start using plain
> vacuum (7.1's vacuum is equivalent to vacuum full IIRC).

That old DB server has been running contnuously for 2 years they tell me.
Apparently it is also growing despite nightly vacuums and a stable data set
size (old data is purged dai.ly and monthly). Nightly delete/insert batches
and vacuums are taking longer and longer too. I suspect the vacuum isn't
doing what they think - possibly due to the FSM being at the default, and
possibly due to ghost processes holding old record versions open. It has
been stable nonetheless. Anyway, I'm sure we can do much better in 7.4.

> > If I start a VACUUM FULL, is it ok to interrupt it part way through? I
mean,
> > is a partially completed vacuum full worth anything, and is there any
danger
> > in routinely killing it?
>
> It's crash-safe but you may leave your indexes bigger than before 

OK, that's the kind of thing I wanted to know. Basically, partial runs of
vacuum full are not likely to be of any benefit. So, unless you intend to
let it run to completion, best to avoid it.

Given that our system experiences quite heavy usage during the day, and has
a nightly window for batch processing I'm wondering if the best way to go
about this is to give auto vacuum a miss and just do a standard vacuum after
the batch processes have completed. As long as the FSM is big enough to
handle the amount of data changed in 1 day, it would be OK, right?

Thanks for the input, (and Bruno too)
Iain

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Re: Routine maintenance - vacuum, analyse and autovacuum

"Iain" <iain <at> mst.co.jp> writes:
>> Just moving from 7.1 to 7.4 should help, since you can start using plain
>> vacuum (7.1's vacuum is equivalent to vacuum full IIRC).

> That old DB server has been running contnuously for 2 years they tell me.
> Apparently it is also growing despite nightly vacuums and a stable data set
> size (old data is purged dai.ly and monthly). Nightly delete/insert batches
> and vacuums are taking longer and longer too. I suspect the vacuum isn't
> doing what they think - possibly due to the FSM being at the default, and
> possibly due to ghost processes holding old record versions open. It has
> been stable nonetheless. Anyway, I'm sure we can do much better in 7.4.

Kinda sounds like index bloat to me --- have you done any looking to
determine which files are growing?

> OK, that's the kind of thing I wanted to know. Basically, partial runs of
> vacuum full are not likely to be of any benefit. So, unless you intend to
> let it run to completion, best to avoid it.

Right.

> Given that our system experiences quite heavy usage during the day, and has
> a nightly window for batch processing I'm wondering if the best way to go
> about this is to give auto vacuum a miss and just do a standard vacuum after
> the batch processes have completed. As long as the FSM is big enough to
> handle the amount of data changed in 1 day, it would be OK, right?

Yes, though plain VACUUM is not as much of a drag on performance as
VACUUM FULL (== 7.1 VACUUM).  So you might want to experiment and
see if you can get away with it during the day.  Also note there is work
afoot to reduce the VACUUM performance drag even further in 7.5.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

Re: Routine maintenance - vacuum, analyse and autovacuum

> Kinda sounds like index bloat to me --- have you done any looking to
> determine which files are growing?
>

No, I havn't. I don't actually have access to that machine, and there is a
cirtain reluctance to tamper with it. However Ithink that it will need some
attention soon. I'll keepin mind what you said.

regards
iain

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings