Re: Gist Recovery testing

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

In response to

Responses

Browse pgsql-hackers by date

  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