ab.
I guess you then would have seen an error message saying that pg_dump
was not found because cron doesn't load the users environment and
therefore PATH variable isn't set.
I suggest you call pg_dump in your script by absolute path.
Greetings,
Frank Wittig
signature.asc
Description: OpenPGP digital signature
Regards,
Frank Wittig
signature.asc
Description: OpenPGP digital signature
Frank Wittig schrieb:
> 24 Hex digits means 24^16 unique file names. Assuming your server saves
> a WAL file each second (you should review your config it it does) it
> takes (24^16)/(60*60*24*365)=3.84214066×10^14 years to reach the upper
> bound.
How embarrassing - I messed up the
ll start over again. ;)
Greetings,
Frank Wittig
signature.asc
Description: OpenPGP digital signature
gs per day.
Greetings,
Frank Wittig
signature.asc
Description: OpenPGP digital signature
r the good work!
Regards,
Frank Wittig
Teodor Sigaev schrieb:
> Ooops. Patch doesn't apply cleanly. New version.
>
>
>> Attached patch fixes that deadlock bug too. And, previous version of
>> my patch has a mistake which is observable on CREATE INDEX .. USING
>>
Teodor Sigaev schrieb:
> Hope, attached patch fix that. Pls, test it.
It still happens.
The log is full of incomplete split dumps:
<2007-06-01 23:00:00.001 CEST:%> LOG: GIN incomplete splits=8
<2007-06-01 23:00:00.001 CEST:%> CONTEXT: xlog redo checkpoint: redo
D0/28020F48; undo 0/0; tli 1; xid
Hi Teodor,
Teodor Sigaev schrieb:
> Hope, attached patch fix that. Pls, test it.
The patch is running. I'll keep on reporting.
Have a nice weekend.
Greetings,
Frank Wittig
signature.asc
Description: OpenPGP digital signature
3 CEST:%> LOG: GIN incomplete split root:8
l:45303 r:111740 at redo CA/C8243C28
<2007-06-01 16:38:23.133 CEST:%> LOG: GIN incomplete split root:4269
l:102123 r:111741 at redo CA/EEAD8B80
It didnt do us the favor to produce more incomplete splits. But these
two are enough to keep the standby server from doing checkpoints.
Greetings,
Frank Wittig
signature.asc
Description: OpenPGP digital signature
I'll test that. I have an idea on how to trigger that problem on purpose
so I dont have to wait until it occures on its own.
Please feel free to let me go through any test you want to run. I really
need that WAL standby - so I will make any effort I can to help getting
it stable.
Greet
Teodor Sigaev schrieb:
> Hmm. I found that gin_xlog_cleanup doesn't reset incomplete_splits list.
> Is it possible reason of bug?
Sounds reasonable to me. Would explain why the system didn't ever
recover from that state.
I'll test your patch and report results on this list
1 13:11:29.365 CEST:%> CONTEXT: xlog redo checkpoint: redo
C9/C20DE050; undo 0/0; tli 1; xid 0/36130541; oid 241990328; multi 8;
offset 15; online
<2007-06-01 13:11:29.365 CEST:%> LOCATION: RecoveryRestartPoint,
xlog.c:5769
best regards,
Frank Wittig
signature.asc
Description: OpenPGP digital signature
the master
too as soon as I can get me a maintenance window for this.
Greetings,
Frank Wittig
signature.asc
Description: OpenPGP digital signature
what could cause this behavior of the slave server?
Could upgrading to 8.2.4 help? - I didn't find something related in the
release notes.
Could this be a bug?
Greetings,
Frank Wittig
signature.asc
Description: OpenPGP digital signature
Hi Hannes,
what type of snapshot are you referring to?
If you use LVM2, you can create writeable snapshots. You simply have
to spend some free space of your volume group (as much as the
expeted amount of data to be written).
Writes to that snapshot are deleted along with deletion of the
snapshot.
15 matches
Mail list logo