| From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
|---|---|
| To: | Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Reject WAIT FOR earlier in transaction-snapshot mode |
| Date: | 2026-09-16 01:28:20 |
| Message-ID: | CABPTF7XK82dGsgry_8HSkSD=zapGH6LHpoLxNUMV027yNptsfA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Sep 12, 2026 at 10:48 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> On Fri, Sep 11, 2026 at 11:58 PM Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
> >
> > > 1) Could we use 0/0 instead of $lsn3 for these rejection tests? Since
> > > $lsn3 is deliberately unreachable, the first test can hang if the
> > > isolation check is missing.
> >
> > I think I will keep this as-is. If the isolation-level rejection is
> > missing, the test is broken.
> >
> > > 2) Also, the isolation-error pattern matches the old DETAIL, so
> > > matching the ERROR: prefix would verify that it is now the primary
> > > error.
> >
> > v4 tightens the new recovery tests so the REPEATABLE READ cases match
> > the primary ERROR line, rather than the old DETAIL text. I also cleaned
> > up one test description.
> >
> > > The cursor case better additionally check that the misleading
> > > isolation-level detail is absent.
> >
> > I don't think we need that. The cursor case only needs to verify the
> > new primary error.
>
>
> Thanks. I am OK with your judgement!
Here's a rebase due to a23ab4862cf.
--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.
| Attachment | Content-Type | Size |
|---|---|---|
| v5-0001-Fix-WAIT-FOR-rejection-errors.patch | application/octet-stream | 5.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-09-16 01:59:26 | Re: Support for 8-byte TOAST values, round two |
| Previous Message | Richard Guo | 2026-09-16 00:38:52 | Re: remove_useless_joins vs. bug #19560 |