| From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility |
| Date: | 2018-03-27 03:16:15 |
| Message-ID: | 5AB9B77F.3020306@anastigmatix.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
-Chap
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Zero-headers-of-unused-pages-after-WAL-switch.patch | text/x-patch | 3.5 KB |
| 0002-Add-test-for-ensuring-WAL-segment-is-zeroed-out.patch | text/x-patch | 2.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| 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 |