| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: logical decoding and replication of sequences |
| Date: | 2022-08-23 04:21:40 |
| Message-ID: | YwRV1GUPuAX0erri@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Aug 08, 2022 at 06:15:46PM +1200, Thomas Munro wrote:
> The attached patch that simply moves the cache invalidation into
> report_invalid_record(), so that it's reached by the above code and
> everything else that reports an error, seems to fix the problem in
> src/bin/pg_ctl/t/003_promote.pl with Noah's spanner-in-the-works patch
> applied, and passes check-world without it. I need to look at this
> some more, though, and figure out if it's the right fix.
Thomas, where are you on this open item? A potential PANIC at
promotion is bad. One possible exit path would be to switch the
default of recovery_prefetch, though that's a kind of last-resort
option seen from here.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2022-08-23 04:24:01 | Re: Considering additional sort specialisation functions for PG16 |
| Previous Message | Peter Smith | 2022-08-23 04:20:08 | Re: Perform streaming logical transactions by background workers and parallel apply |