Re: WAL status update

First, as I've already mentioned in answer to Tom about DROP TABLE, undo
logic will not be implemented in 7.1 -:( Doable for tables but for

indices we

would need either in compensation records or in xmin/cmin in index

tuples.

So, we'll still live with dust from aborted xactions in our

tables/indices.

Does it mean that there would still be inconsistency between
tables and their indexes ?

Not related. I just meant to say that tuples inserted into tables/indices by
aborted transactions will stay there till vacuum.
Redo should guarantee that index tuples will not be lost in split operation
(what's possible now), but not that an index will have correct structure
after crash - parent page may be unupdated, what could be handled
at run time.

Vadim

Vadim Mikheev writes:

WAL todo list looks like:

So what's the latest on going beta?

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

I believe that its just resting on Vadim again to give us the go ahead
... which I believe its always been on his shoulders, no? :)

Vadim?

On Mon, 30 Oct 2000, Peter Eisentraut wrote:

Vadim Mikheev writes:

WAL todo list looks like:

So what's the latest on going beta?

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

I believe that its just resting on Vadim again to give us the go ahead
... which I believe its always been on his shoulders, no? :)

Vadim?

I think that at least 1 & 2 from WAL todo (checkpoints and port to
machines without TAS) is required before beta. As well as more testing...
Did anyone else test WAL recovery?
Sorry guys but I can't do both testing and coding at the same time.
WAL is the most complex thing I've ever did in project.
MVCC was just child's game.

Tom & Bruce are in summit anyway - let's wait them. And I'll do 1 & 2 in
a few days.

Vadim

The first test did not go very well. I did a fresh compile, initdb,
started the postmaster, ran 'make installcheck' (sequential regression
tests), and sent a kill -QUIT to the postmaster during the
numeric test.
Then I restarted the postmaster and got a load of lines like

REDO @ 0/434072; LSN 0/434100: prev 0/433992; xprev 0/433992; xid
17278: Transaction - commit: 2000-10-31 23:21:29
REDO @ 0/434100; LSN 0/434252: prev 0/434072; xprev 0/0; xid
17279: Heap - insert: node 19008/1259; cid 0; tid 1/43

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Is this *the last* output just before abort?
I need to know in what stage abort occured.
Could you look at core file too?

after which it finished with

Startup failed - abort

Vadim

Vadim Mikheev writes:

WAL with rollforward logic is available for testing but yet requires
re-compiling with -DXLOG flag. Note that regress tests are passed but
it doesn't mean anything. What is required is testing how recovery
does work (just run pg_ctl -m i stop after some changes in db and test
db after restart). Also, I've tested it for single running transaction
only. xlog.c:XLOG_DEBUG is on currently and results in high output to
stderr.

The first test did not go very well. I did a fresh compile, initdb,
started the postmaster, ran 'make installcheck' (sequential regression
tests), and sent a kill -QUIT to the postmaster during the numeric test.
Then I restarted the postmaster and got a load of lines like

REDO @ 0/434072; LSN 0/434100: prev 0/433992; xprev 0/433992; xid
17278: Transaction - commit: 2000-10-31 23:21:29
REDO @ 0/434100; LSN 0/434252: prev 0/434072; xprev 0/0; xid 17279: Heap -
insert: node 19008/1259; cid 0; tid 1/43

after which it finished with

Startup failed - abort

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

The first test did not go very well. I did a fresh compile, initdb,
started the postmaster, ran 'make installcheck' (sequential
regression tests), and sent a kill -QUIT to the postmaster during the
numeric test.
Then I restarted the postmaster and got a load of lines like

REDO @ 0/434072; LSN 0/434100: prev 0/433992; xprev 0/433992; xid
17278: Transaction - commit: 2000-10-31 23:21:29
REDO @ 0/434100; LSN 0/434252: prev 0/434072; xprev 0/0; xid
17279: Heap - insert: node 19008/1259; cid 0; tid 1/43

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Is this *the last* output just before abort?
I need to know in what stage abort occured.
Could you look at core file too?

after which it finished with

Startup failed - abort

Fixed. Thanks for pointing to the problem!

Vadim

"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:

I think that at least 1 & 2 from WAL todo (checkpoints and port to
machines without TAS) is required before beta.

I'm not sure that you do need to add support for machines without TAS.
I pointed out a couple months ago that the non-TAS support code hasn't
even compiled for the past release or three, and proposed ripping it
all out rather than fixing code that clearly isn't being used.
No one objected.

I haven't got round to doing the ripping yet, but as far as I know
there is no reason to expend work on adding more code for the non-TAS
case.

I have a few other things I still need to do before 7.1 beta. Do you
think you'll be ready in, say, a week?

regards, tom lane

"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:

I think that at least 1 & 2 from WAL todo (checkpoints and port to
machines without TAS) is required before beta.

I'm not sure that you do need to add support for machines without TAS.
I pointed out a couple months ago that the non-TAS support code hasn't
even compiled for the past release or three, and proposed ripping it
all out rather than fixing code that clearly isn't being used.
No one objected.

I haven't got round to doing the ripping yet, but as far as I know
there is no reason to expend work on adding more code for the non-TAS
case.

Oh, it's great! Thanks!
one todo item is gone -:)

I have a few other things I still need to do before 7.1 beta. Do you
think you'll be ready in, say, a week?

yes.

Vadim