Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> So it appears that pg_md5_encrypt is not officially exported from libpq.
>> Does anyone see a problem with adding it to the export list and the
>> header file?
> Is it different to normal md5? How is this helpful to the phpPgAdmin
> proje
OKADA Satoshi <[EMAIL PROTECTED]> writes:
> The loss of log was simulated by deleting the latest xlog file.
What does that have to do with reality? Postgres is very careful not to
use an xlog file until it's been fully metadata-synced. You might as
well complain that PG doesn't recover after "r
So it appears that pg_md5_encrypt is not officially exported from libpq.
Does anyone see a problem with adding it to the export list and the
header file?
Is it different to normal md5? How is this helpful to the phpPgAdmin
project?
Chris
---(end of broadcast)-
Hi
I am testing the durability of PostgreSQL. When a part of log
was lost due to the trouble(power supply trouble etc.),
I tested about the recovery of PostgreSQL.
The loss of log was simulated by deleting the latest xlog file.
postmaster startup, it only output log message "No such file or
On Saturday 2005-12-17 16:28, Lukas Smith wrote:
> Bruce Momjian wrote:
> > * Flush cached query plans when the dependent objects change,
> > when the cardinality of parameters changes dramatically, or
> > when new ANALYZE statistics are available
>
> Wouldn't it also make sense to
Andreas Pflug wrote:
> Dave Page wrote:
> > So did you just rip it from there into psql? I don't see it in the
> > list of libpq exports so if thats not the case, on Windows at least
> > we'll need to change the api, and possibly the dll name as well to
> > avoid any compatibility issues.
>
> And
Peter Eisentraut wrote:
Letting createuser.c hash the password would be the biggest win.
Both of these things are now done, and I have sent notices to pgadmin
and phppgadmin asking for equivalent adjustments.
Um, didn't receive a notice.
I'm a little uncomfortable using an arbitrary md5 al
Christopher Browne wrote:
> > Not unless you do something that would cause the planner to make
> > different choices next time. (Such as changing the ANALYZE statistics,
> > perhaps.) The TODO item is OK as stated, it's just talking about
> > mechanism and not the things that might trigger the me
