Re: pg_get_indexdef() modification to use TxnSnapshot

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_get_indexdef() modification to use TxnSnapshot
Date: 2023-06-14 06:31:02
Message-ID: CALDaNm1E=W20=w0_zQjcAHui32Q01Qw2-NaKqzpgdRdaTvKQGQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 13 Jun 2023 at 11:49, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Fri, May 26, 2023 at 6:55 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > I have attempted to convert pg_get_indexdef() to use
> > systable_beginscan() based on transaction-snapshot rather than using
> > SearchSysCache(). The latter does not have any old info and thus
> > provides only the latest info as per the committed txns, which could
> > result in errors in some scenarios. One such case is mentioned atop
> > pg_dump.c. The patch is an attempt to fix the same pg_dump's issue.
> > Any feedback is welcome.
>
> Even only in pg_get_indexdef_worker(), there are still many places
> where we use syscache lookup: generate_relation_name(),
> get_relation_name(), get_attname(), get_atttypetypmodcoll(),
> get_opclass_name() etc.
>
> >
> > There is a long list of pg_get_* functions which use SearchSysCache()
> > and thus may expose similar issues. I can give it a try to review the
> > possibility of converting all of them. Thoughts?
> >
>
> it would be going to be a large refactoring and potentially make the
> future implementations such as pg_get_tabledef() etc hard. Have you
> considered changes to the SearchSysCache() family so that they
> internally use a transaction snapshot that is registered in advance.
> Since we are already doing similar things for catalog lookup in
> logical decoding, it might be feasible. That way, the changes to
> pg_get_XXXdef() functions would be much easier.

I feel registering an active snapshot before accessing the system
catalog as suggested by Sawada-san will be a better fix to solve the
problem. If this approach is fine, we will have to similarly fix the
other pg_get_*** functions like pg_get_constraintdef,
pg_get_function_arguments, pg_get_function_result,
pg_get_function_identity_arguments, pg_get_function_sqlbody,
pg_get_expr, pg_get_partkeydef, pg_get_statisticsobjdef and
pg_get_triggerdef.
The Attached patch has the changes for the same.

Regards,
Vignesh

Attachment Content-Type Size
0001-pg_get_indexdef-modification-to-access-catalog-based.patch text/x-patch 1.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-06-14 06:44:21 Re: Views no longer in rangeTabls?
Previous Message John Naylor 2023-06-14 06:23:07 Re: [PoC] Improve dead tuple storage for lazy vacuum