| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation() |
| Date: | 2018-02-02 15:37:45 |
| Message-ID: | CA+TgmoZMbPgU6VGG311UU0CLj0XO9-kSnLG+_6OH+it1_Sm=rg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 1, 2018 at 7:21 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Yes, it would be about 99% of the time.
>
> But you have it backwards - we are not assuming that case. That is the
> only case that has risk - the one where an old WAL record starts at
> exactly the place the latest one stops. Otherwise the rest of the WAL
> record will certainly fail the CRC check, since it will effectively
> have random data in it, as you say.
OK, I get it now. Thanks for explaining. I think I understand now
why you think this problem can be solved just by controlling the way
we recycle segments, but I'm still not sure if that can really be made
fully reliable. Michael seems concerned about what might happen after
multiple recyclings, and Tom has raised the issue of old data
reappearing after a crash.
I do agree that it would be nice if we could make it work - saving 8
bytes per WAL record would be significant.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-02-02 15:40:03 | Re: [HACKERS] Bug in to_timestamp(). |
| Previous Message | Robert Haas | 2018-02-02 15:16:17 | Re: Query running for very long time (server hanged) with parallel append |