| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Ajin Cherian <itsajin(at)gmail(dot)com> |
| Cc: | cca5507 <cca5507(at)qq(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state |
| Date: | 2026-07-23 16:28:37 |
| Message-ID: | CAD21AoDYWJGtsbDg2CoNEQC9SSCXbKM8FR8vAtdLb_TyXH6FxQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 27, 2025 at 3:30 AM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
>
> On Fri, Jun 27, 2025 at 3:48 PM cca5507 <cca5507(at)qq(dot)com> wrote:
> >
> > Hi,
> >
> > I refactor the code and fix the git apply warning according to [1].
> >
> > Here are the new version patches.
> >
> > --
> > Regards,
> > ChangAo Chen
> >
> > [1] https://www.postgresql.org/message-id/Zrmh7X8jYCbFYXjH%40ip-10-97-1-34.eu-west-3.compute.internal
>
> I see this problem is similar to the bug reported in [1], and your fix
> also addresses the issue reported there. Although I like your approach
> of tracking changes starting from the BUILDING_SNAPSHOT state, I’d
> like to suggest an alternative.
>
> While debugging that issue, my plan was not to track catalog changes
> prior to SNAPBUILD_CONSISTENT, but instead to ensure we don’t use
> snapshots built before SNAPBUILD_CONSISTENT, since we don’t track
> catalog changes in those states. We should discard previously built
> snapshots and rebuild them once we reach the SNAPBUILD_CONSISTENT
> state. At that point, all necessary transactions would have been
> committed, and builder->xmin would have advanced enough to decode all
> transactions from then on.
>
> The problem is that previously built snapshots hang around without the
> latest xmin and xmax, and we tend to reuse them. We should ensure that
> all txn->base_snapshot and builder->snapshot snapshots built in the
> SNAPBUILD_FULL_SNAPSHOT state are rebuilt once we reach
> SNAPBUILD_CONSISTENT. For this, we need to track when the snapshot was
> built. There is already a field in ReorderBufferTXN -
> 'base_snapshot_lsn' which we can use. If base_snapshot_lsn <
> builder->start_decoding_at, then we should rebuild the snapshot. Just
> a thought.
How does this idea address the distributed snapshots? Replaying a
transaction could use multiple snapshots if catalog-change
transactions are committed when the transaction was running. I think
that's true also for transactions that started in FULL state and were
committed in CONSISTENT state.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tristan Partin | 2026-07-23 16:35:25 | Re: Add pg_stat_kind_info system view |
| Previous Message | Zsolt Parragi | 2026-07-23 16:26:16 | Re: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support |