Re: [BUGS] server crash in very big transaction [postgresql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] server crash in very big transaction [postgresql
Date
Msg-id 15405.1093410109@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] server crash in very big transaction [postgresql  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> If we agree to never implement UNDO, there's a bunch of other code that
> could be removed.

Yeah, I've been thinking of going around and cleaning out the deadwood,
but beta is not the time for it.

> The commit xlog record also carries dropped table information, 12 bytes
> apiece (on 32 bit machines?).

Good point --- someone will eventually hit that case too, if we don't
increase the XLOG record size limit.

>>> Or we could assign an rmgr value to represent an "extension" record that
>>> is to be merged with a following "normal" record.

> I also think this is a good idea.  Would it be generalized or only
> applicable to xl_xact_{commit,abort} records?

I was envisioning it as a general mechanism --- I see no point in
restricting it to commit/abort records.  If anything it would take extra
code to restrict it to that case ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] server crash in very big transaction [postgresql 8.0beta1]
Next
From: Greg Stark
Date:
Subject: Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling