Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
Date: 2012-02-17 15:36:58
Message-ID: 4F3E741A.2090308@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17.02.2012 07:27, Fujii Masao wrote:
> Got another problem: when I ran pg_stop_backup to take an online backup,
> it got stuck until I had generated new WAL record. This happens because,
> in the patch, when pg_stop_backup forces a switch to new WAL file, old
> WAL file is not marked as archivable until next new WAL record has been
> inserted, but pg_stop_backup keeps waiting for that WAL file to be archived.
> OTOH, without the patch, WAL file is marked as archivable as soon as WAL
> file switch occurs.
>
> So, in short, the patch seems to handle the WAL file switch logic incorrectly.

Yep. For a WAL-switch record, XLogInsert returns the location of the end
of the record, not the end of the empty padding space. So when the
caller flushed up to that point, it didn't flush the empty space and
therefore didn't notify the archiver.

Attached is a new version, fixing that, and off-by-one bug you pointed
out in the slot wraparound handling. I also moved code around a bit, I
think this new division of labor between the XLogInsert subroutines is
more readable.

Thanks for the testing!

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Attachment Content-Type Size
xloginsert-scale-9.patch text/x-diff 95.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jay Levitt 2012-02-17 15:42:11 Copyright notice for contrib/cube?
Previous Message Tom Lane 2012-02-17 15:27:35 Re: MySQL search query is not executing in Postgres DB