| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Korotkov <akorotkov(at)postgresql(dot)org> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Pg Committers <pgsql-committers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pgsql: Check for conflicting queries during replay of gistvacuumpage() |
| Date: | 2018-12-21 16:09:32 |
| Message-ID: | 26932.1545408572@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Hmmm, I'm fairly sure you should have bumped XLOG_PAGE_MAGIC for this
>> change. Otherwise, what is going to happen to an unpatched standby (of
>> released versions) that receives the new WAL record from a patched
>> primary?
Oh, and if the answer to your question is not "it fails with an
intelligible error about an unrecognized WAL record type", then we
need to adjust what is emitted so that that will be what happens.
Crashing, or worse silently misprocessing the record, will not do.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-12-21 16:16:38 | Re: pgsql: Check for conflicting queries during replay of gistvacuumpage() |
| Previous Message | Tom Lane | 2018-12-21 16:00:37 | Re: pgsql: Check for conflicting queries during replay of gistvacuumpage() |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-12-21 16:16:38 | Re: pgsql: Check for conflicting queries during replay of gistvacuumpage() |
| Previous Message | Tom Lane | 2018-12-21 16:00:37 | Re: pgsql: Check for conflicting queries during replay of gistvacuumpage() |