|From:||Chapman Flack <chap(at)anastigmatix(dot)net>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 03/26/18 12:34, Tom Lane wrote:
> If that's the argument, why is the WALInsertLockUpdateInsertingAt(CurrPos)
> call still there? GetXLogBuffer() would do that too.
"Because I hadn't noticed that," he said, sheepishly.
> In any case, the new comment ... fails to
> explain what's going on, and the reference to a function that is not
> actually called from the vicinity of the comment ...
> suggest something like "GetXLogBuffer() will fetch and initialize the
> next WAL page for us. ... worth explaining how you know that the new
> page's header is short not long.
Here are patches responding to that (and also fixing the unintended
inclusion of .travis.yml).
What I have not done here is respond to Michael's objection, which
I haven't had time to think more about yet.
|Next Message||Peter Geoghegan||2018-03-27 03:20:57||Re: [HACKERS] A design for amcheck heapam verification|
|Previous Message||David Rowley||2018-03-27 02:51:08||Re: Parallel Aggregates for string_agg and array_agg|