On 22 January 2014 01:23, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@2ndquadrant.com> writes: >> On 2014-01-21 18:59:13 -0500, Tom Lane wrote: >>> Another thing to think about is whether we couldn't put a hard limit on >>> WAL record size somehow. Multi-megabyte WAL records are an abuse of the >>> design anyway, when you get right down to it. So for example maybe we >>> could split up commit records, with most of the bulky information dumped >>> into separate records that appear before the "real commit". This would >>> complicate replay --- in particular, if we abort the transaction after >>> writing a few such records, how does the replayer realize that it can >>> forget about those records? But that sounds probably surmountable. > >> I think removing the list of subtransactions from commit records would >> essentially require not truncating pg_subtrans after a restart >> anymore. > > I'm not suggesting that we stop providing that information! I'm just > saying that we perhaps don't need to store it all in one WAL record, > if instead we put the onus on WAL replay to be able to reconstruct what > it needs from a series of WAL records.
I think removing excess subxacts from commit and abort records could be a good idea. Not sure anybody considered it before. We already emit xid allocation records when we overflow, so we already know which subxids have been allocated. We also issue subxact abort records for anything that aborted. So in theory we should be able to reconstruct an arbitrarily long chain of subxacts. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
