| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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:32:46 |
| Message-ID: | CA+hUKGK428KdYB_3OaVc6fVKkOi18PUWp=GoSiymP9_ZOxUc9g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 23, 2022 at 4:21 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> 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.
I will get a fix committed this week -- I need to study
Horiguchi-san's analysis...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2022-08-23 05:56:11 | Re: Schema variables - new implementation for Postgres 15 |
| Previous Message | David Rowley | 2022-08-23 04:24:01 | Re: Considering additional sort specialisation functions for PG16 |