Re: Reject WAIT FOR earlier in transaction-snapshot mode

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Á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-17 15:16:57
Message-ID: CABPTF7WXy1XFDG7MJbu2BX26Q5710Vm30XMcO4pYSdi6njZiOQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 17, 2026 at 10:53 PM Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
>
> > > Done in v6.
> >
> > Xuneng, Sami, do you think v6 is good enough?
>
> I think the user-facing documentation can be simplified considerably while
> preserving the important information. I prefer the below changes on top
> of v6:
>
> 1/ State directly that WAIT cannot be executed while the current transaction
> holds a snapshot.
> 2/ Clarify that WAIT itself does not acquire a snapshot.
> 3/ Explain that it can therefore be executed before the first snapshot-taking
> statement in a REPEATABLE READ or SERIALIZABLE transaction.
> 4/ Briefly explain why holding a snapshot can prevent a standby wait from
> completing.
>

Yeah, I think we can simplify and consolidate them. I proposed a
reorganization earlier but it did not do simplification [1]. The
underlying motivation for those constraints stay the same -- to avoid
deadlock/hang while waiting. So I would prefer a small opening para
for consolidation. As for simplification, personally, I am OK with a
detailed explanation because it helps curious users to learn with the
cost of loading some extra bytes. However, the length of the note part
does seem disproportional to that of usage of this command.

[1] https://www.postgresql.org/message-id/CABPTF7UmSuO5HWfBZ+wcJqTAfSFmwAdByrONhWttg5rq56j8vw@mail.gmail.com

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2026-09-17 15:25:58 Re: 64-bit MultiXactOffset vs. 9.3->9.4 upgrade, pg_resetwal, "wraparound" msg
Previous Message Manuel Reyes Bravo 2026-09-17 15:07:27 Re: pg_get_object_address reports a published relation as non-existent