Re: [BUGS] server crash in very big transaction [postgresql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [BUGS] server crash in very big transaction [postgresql
Date: 2004-08-25 05:01:49
Message-ID: 15405.1093410109@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2004-08-25 05:13:00 Re: TOAST error in 7.4.2 on frequently truncated tables
Previous Message Josh Berkus 2004-08-25 04:52:48 TOAST error in 7.4.2 on frequently truncated tables

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2004-08-25 05:32:11 Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
Previous Message Tom Lane 2004-08-25 04:30:23 Re: [BUGS] server crash in very big transaction [postgresql 8.0beta1]