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

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

On Wed, Aug 25, 2004 at 11:21:49AM +1000, Gavin Sherry wrote:
> On Tue, 24 Aug 2004, Tom Lane wrote:

> > 1. Allow XLOG records to be larger than 64K.
> >
> > 2. Split transaction commit into multiple XLOG records when there are
> > many subtransactions.
>
> [snip]
>
> > I'm inclined to go with #1. There are various ways we could do it
> > but the most straightforward would be to just widen the xl_len field
> > to 32 bits. This would cost either 4 or 8 bytes per XLOG record
> > (because of MAXALIGN restrictions) but we could more than buy that back
> > by eliminating the xl_prev and/or xl_xact_prev fields, which have no use
> > in the current system. (They were intended to support UNDO but it seems
> > clear that we will never do that.)

If we agree to never implement UNDO, there's a bunch of other code that
could be removed. Is there anyone that thinks we have any chance of not
doing it?

OTOH, if those fields are unused, we could just remove them for now in
any case. It's unlikely that there won't be a catalog update for some
other reason before someone implements UNDO anyway.

> As for extending the length of xl_len, what happens if someone now has
> 2^30 subtransaction IDs (as unlikely as that sounds)?

The commit xlog record also carries dropped table information, 12 bytes
apiece (on 32 bit machines?). It's unlikely that anyone will drop 2^13
tables on a single transaction, but it adds to the child xid list.

> > Or we could assign an rmgr value to represent an "extension" record that
> > is to be merged with a following "normal" record. This is kinda klugy
> > but would avoid wasting bits on xl_len in the vast majority of records.
> > Also we'd not have to force an initdb since the file format would
> > remain upward-compatible.
>
> This is a better idea, I think, as it avoids the problems above and, as
> you say, will be binary compatible.

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

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia está en otra parte" (Andre Breton)

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2004-08-25 04:30:23 Re: [BUGS] server crash in very big transaction [postgresql 8.0beta1]
Previous Message Alvaro Herrera 2004-08-25 04:10:01 Re: server crash in very big transaction [postgresql 8.0beta1]

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-08-25 04:30:23 Re: [BUGS] server crash in very big transaction [postgresql 8.0beta1]
Previous Message Alvaro Herrera 2004-08-25 04:10:01 Re: server crash in very big transaction [postgresql 8.0beta1]