On Mon, May 16, 2011 at 11:20 AM, Leonardo Francalanci <m_li...@yahoo.it> wrote: > > following the conversation at > > http://postgresql.1045698.n5.nabble.com/switch-UNLOGGED-to-LOGGED-tp4290461p4382333.html > > > I tried to remove some bytes from xl_xact_commit. > > The way I did it needs palloc+memcpy. I guess it could be done > reusing the memory for smgrGetPendingDeletes. But I don't > think it's that important. > > I guess there are other ways of doing it; let me know what > you think.
I don't think there's much point to the xl_xact_commit_opt structure; it doesn't really do anything. What I would do is end the xl_xact_commit structure with something like: int counts[1]; /* variable-length array of counts, xinfo flags define length of array and meaning of counts */ Then, I'd make macros like this: #define XactCommitNumberOfDroppedRelFileNodes(xlrec) \ ((xlref->xinfo & XACT_COMMIT_DROPPED_RELFILENODES) ? xlrec->counts[0] : 0) #define XactCommitNumberOfCommittedSubXids(xlrec) \ ((xlref->xinfo & XACT_COMMITED_SUBXDIDS) ? xlrec->counts[(xlrec->xinfo & XACT_COMMIT_DROPPED_RELFILENODES) ? 1 : 0] : 0) ...etc... ...and a similar set of macros that will return a pointer to the beginning of the corresponding array, if it's present. I'd lay out the record like this: - main record - array of counts (might be zero-length) - array of dropped relfilnodes (if any) - array of committed subxids (if any) - array of sinval messages (if any) Also, it's important not to confuse xact completion with xact commit, as I think some of your naming does. Completion could perhaps be thought to include abort. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
