Re: Analysis of ganged WAL writes - Mailing list pgsql-hackers

From Curtis Faith
Subject Re: Analysis of ganged WAL writes
Date
Msg-id DMEEJMCDOJAKPPFACMPMKEGCCEAA.curtis@galtair.com
Whole thread Raw
In response to Re: Analysis of ganged WAL writes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Analysis of ganged WAL writes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > Since in your case all transactions A-E want the same buffer written,
> > the memory (not it's content) will also be the same.
>
> But no, it won't: the successive writes will ask to write different
> snapshots of the same buffer.

Successive writes would write different NON-OVERLAPPING sections of the
same log buffer. It wouldn't make sense to send three separate copies of
the entire block. That could indeed cause problems.

If a separate log writing process was doing all the writing, it could
pre-gang the writes. However, I'm not sure this is necessary. I'll test the
simpler way first.

> > The problem I can see offhand is how the kaio system can tell which
> > transaction can be safely notified of the write,
>
> Yup, exactly.  Whose snapshot made it down to (stable) disk storage?

If you do as above, it can inform the transactions when the blocks get
written to disk since there are no inconsistent writes. If transactions A,
B and C had commits in block 1023, and the aio system writes that block to
the disk, it can notify all three that their transaction write is complete
when that block (or partial block) is written to disk.

It transaction C's write didn't make it into the buffer, I've got to assume
the aio system or the disk cache logic can handle realizing that it didn't
queue that write and therefore not inform transaction C of a completion.

- Curtis



pgsql-hackers by date:

Previous
From: "Curtis Faith"
Date:
Subject: Re: Analysis of ganged WAL writes
Next
From: iafmgc@unileon.es
Date:
Subject: genetic query optimization