Date: Wed, 10 Apr 2019 13:47:47 -0700
From: Andres Freund <andres@anarazel.de>
To: Bruce Momjian <bruce@momjian.us>
Cc: imre.gabesz@gmail.com, pgsql-docs@lists.postgresql.org
Subject: Re: 30.3. Asynchronous Commit
Message-ID: <20190410204747.kodthrzgwszeftdj@alap3.anarazel.de>
References: <155368953491.9806.1253077077613006580@wrigleys.postgresql.org>
 <20190410200610.vhij57iz2xzottiu@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190410200610.vhij57iz2xzottiu@momjian.us>
Precedence: bulk

Hi,

On 2019-04-10 16:06:10 -0400, Bruce Momjian wrote:
> On Wed, Mar 27, 2019 at 12:25:34PM +0000, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> > 
> > Page: https://www.postgresql.org/docs/9.6/wal-async-commit.html
> > Description:
> > 
> > How do async commits and unlogged tables relate? You might add a paragraph
> > on clarifying this relation. 
> > https://www.postgresql.org/docs/9.6/wal-async-commit.html
> 
> Async commit controls the WAL writes for _logged_ tables.  Unlogged
> tables don't generate WAL, since they are not crash safe, and hence are
> not affected by async commit.

That's not quite true, I think. Async commit is a question that only
matters at commit time. Logged/Unlogged only matters insofar as it
determines whether WAL has been written up ot that point.

Currently we *always* perform an async commit if a transaction didn't
write any WAL, even if an xid has been assigned (but we'll log a commit
record).

But even transactions that only write to unlogged tables can easily have
WAL assigned - e.g. hot pruning in catalog tables or during reads from
user defined logged tables; or enough subtransactions were used that an
xid assigment record had to be written; or some logged table (including
catalog tables) was accessed, and a hit bit had been set, and
wal_log_hint bits were set, and a lot of other reasons.

Thus I think it's wrong to say that async commit doesn't mean anything
for unlogged tables.

I'd also say that it's not correct to say that async commit really
controls WAL writes at all. It's just whether we *flush* the commit
record, or not.

Greetings,

Andres Freund