Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, Aug 25, 2004 at 11:21:49AM +1000, Gavin Sherry wrote:
On Tue, 24 Aug 2004, Tom Lane wrote:
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
This has just been fixed by Tom and will be in beta2.
---
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
As for extending the length of xl_len, what happens if someone now has
2^30 subtransaction IDs (as
I wrote:
What is happening of course is that more than 16K subtransaction IDs
won't fit in a commit record (since XLOG records have a 16-bit length
field). We're gonna have to rethink the representation of subxact
commit in XLOG.
After some further thought, I think there are basically two
On Tue, 24 Aug 2004, Tom Lane wrote:
I wrote:
What is happening of course is that more than 16K subtransaction IDs
won't fit in a commit record (since XLOG records have a 16-bit length
field). We're gonna have to rethink the representation of subxact
commit in XLOG.
After some further
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
Gavin Sherry [EMAIL PROTECTED] writes:
As for extending the length of xl_len, what happens if someone now has
2^30 subtransaction IDs (as unlikely as that sounds)?
They'll have run out of RAM to store the subxact-related storage before
that (not to mention most likely have exhausted the
Alvaro Herrera [EMAIL PROTECTED] 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
