Skip site navigation (1) Skip section navigation (2)

Re: read transaction and sync rep

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: read transaction and sync rep
Date: 2012-01-13 11:44:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Jan 13, 2012 at 11:30 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> I found that even read transaction waits for sync rep when it generates
> WAL records even if XID is not assigned. For example, imagine the case
> where SELECT query does a heap clean operation and generates
> XLOG_HEAP2_CLEAN record. ISTM that such a read transaction doesn't
> need to wait for sync rep because that's not visible to the client... Can
> we skip waiting for sync rep if XID is not assigned?

Your example of XLOG_HEAP2_CLEAN records is a good one but there are
other record types and circumstances, as described in the comment near
the top of RecordTransactionCommit

		 * If we didn't create XLOG entries, we're done here; otherwise we
		 * should flush those entries the same as a commit record.	(An
		 * example of a possible record that wouldn't cause an XID to be
		 * assigned is a sequence advance record due to nextval() --- we want
		 * to flush that to disk before reporting commit.)
		if (!wrote_xlog)
			goto cleanup;

Perhaps there is a case to say that sequences don't need to be flushed
if all they did was do nextval but no change was associated with that,
I'm not sure.

So I think there is a case for optimisation using finer grained decision making.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2012-01-13 12:27:13
Subject: Re: New replication mode: write
Previous:From: Fujii MasaoDate: 2012-01-13 11:30:21
Subject: read transaction and sync rep

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group