operation by the database administrator.
Therefore, we think new startup option of postmaster;
* Introduce new startup option(ex. postmaster -R).
* When postmaster can't read xlog and startup with this option,
postmaster stop startup process with "PANIC".
We will make a patch. Do you think this patch?
OKADA Satoshi
NTT Cyberspace Lab.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Tom Lane wrote:
>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
m was not properly shut down; automatic recovery in progress
LOG: record with zero length at 0/160
LOG: redo is not required
LOG: database system is ready
LOG: transaction ID wrap limit is 1073742415, limited by database "testdb"
LOG: shutting down
LOG: database system
Tom Lane wrote:
>OKADA Satoshi <[EMAIL PROTECTED]> writes:
>
>
>>I'm testing PITR using pgbench and postgresql ver.8.0bata.
>>I think that result of recovery is wrong.
>>
>>
>
>Many thanks for this bug rep
Tom Lane wrote:
>OKADA Satoshi <[EMAIL PROTECTED]> writes:
>
>>I'm testing PITR using pgbench and postgresql ver.8.0bata.
>>
>
>Is this actually the official beta1 version, or is it a snapshot from
>last week sometime?
>
I got it from
ftp.postgr
I'm testing PITR using pgbench and postgresql ver.8.0bata.
I think that result of recovery is wrong. My test procedure
is as follows:
I edited postgresql.conf for PITR and started the postmaster.
And I executed "pgbench -t 2".
% pgbench -t 2
I did backup procedur
