On 15.12.2011 17:34, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakan...@enterprisedb.com> writes:
I've been experimenting with different approaches to do that, but one
thing is common among all of them: you need to know the total amount of
WAL space needed for the record, including backup blocks, before you
take the lock. So, here's a patch to move things around in XLogInsert()
a bit, to accomplish that.
This patch may or may not be useful, but this description of it is utter
nonsense, because we already do compute that before taking the lock.
Nope. Without this patch, the total length including the backup blocks,
write_len, is added up in the loop that creates the rdata entries for
backup blocks. That is done while holding the lock (see code beginning
with comment "Make additional rdata chain entries for the backup blocks").
Admittedly you could sum up the total length quite easily in the earlier
loop, before we grab the lock, where we calculate the CRC of the backup
blocks ("Now add the backup block headers and data into the CRC"). That
would be a smaller patch.
Please try again to explain what you're doing?
Ok: I'm moving the creation of rdata entries for backup blocks outside
the critical section, so that it's done before grabbing the lock. I'm
also moving the CRC calculation so that it's done after all the rdata
entries have been created, including the ones for backup blocks. It's
more readable to do it that way, as a separate step, instead of
sprinkling the COMP_CRC macros in many places.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
