Re: read transaction and sync rep

On Fri, Jan 13, 2012 at 3:44 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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?

I think this applies not only to sync rep, but also the xlog sync on
the master as well.
That is, the transaction could just commit asynchronously.

> 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.

I think there that that is the case. If one wants to argue that
someone could take the sequence value and do something with it outside
the database and so that sequence can't be repeated after recovery,
then the commit is the wrong place to make that argument. The flush
would have to occur before the value is handed out, not before the
transaction which obtained the value commits.

Cheers,

Jeff