| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | masao(dot)fujii(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Review for GetWALAvailability() |
| Date: | 2020-06-16 18:31:43 |
| Message-ID: | 20200616183143.GA18116@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-Jun-16, Kyotaro Horiguchi wrote:
> I noticed the another issue. If some required WALs are removed, the
> slot will be "invalidated", that is, restart_lsn is set to invalid
> value. As the result we hardly see the "lost" state.
>
> It can be "fixed" by remembering the validity of a slot separately
> from restart_lsn. Is that worth doing?
We discussed this before. I agree it would be better to do this
in some way, but I fear that if we do it naively, some code might exist
that reads the LSN without realizing that it needs to check the validity
flag first.
On the other hand, maybe this is not a problem in practice, because if
such a bug occurs, what will happen is that trying to read WAL from such
a slot will return the error message that the WAL file cannot be found.
Maybe this is acceptable?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2020-06-16 18:50:47 | Re: Review for GetWALAvailability() |
| Previous Message | Jonathan S. Katz | 2020-06-16 17:49:59 | PostgreSQL 13 Beta 2 Release Date |