From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Gist Recovery testing |
Date: | 2005-06-10 16:46:32 |
Message-ID: | 23513.1118421992@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> Ok, I already realized WAL in GiST and tested with online backup. It works.
> Now I need test it on recovery after crash (power loss etc) and there is a
> problem in GiST with incompleted inserts, I hope, I resolved it, but this
> problem, I think, has the same nature as incompleted splits in btree code. For
> solving, btree xlog code uses stack of incompleted splits and if they leaves
> incompleted, btree_xlog_cleanup function completes them. I make use similar
> idea, but I can't reproduce situation when xlog_cleanup makes some useful work
> except just looks at void stack. So question: how is it possible to reproduce
> desired behaviour?
It's not very easy; you have to arrange for the WAL history to end
between the two action records that you are interested in. What I'd
suggest is
- run test backend under GDB, set breakpoint between
making log entry for first split step and entry for second.
- let it reach the breakpoint
- in another backend, commit some unrelated transaction to
force XLOG buffers to disk
- in GDB, "kill -9" to prevent test backend from proceeding
If you want to trace through the recovery as well, the best bet might be
to temporarily add a "sleep(30)" near the beginning of StartupXlog so
that you have time to reattach to the recovery process.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2005-06-10 16:56:25 | Re: Concrete proposal for large objects and MVCC |
Previous Message | Jon Jensen | 2005-06-10 16:42:57 | Re: psql: \x and slash commands |