Horton

Re: Re: proposal: schema variables

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: jian he <jian.universality@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Erik Rijkers <er@xs4all.nl>, Michael Paquier <michael@paquier.xyz>, Amit Kapila <amit.kapila16@gmail.com>, DUVAL REMI <REMI.DUVAL@cheops.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-28T17:29:26Z
Lists: pgsql-hackers, pgsql-performance

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move WAL sequence code into its own file

  2. Add ExplainState argument to pg_plan_query() and planner().

  3. Don't include access/htup_details.h in executor/tuptable.h

  4. Refactor to avoid code duplication in transformPLAssignStmt.

  5. Avoid including commands/dbcommands.h in so many places

  6. Restrict psql meta-commands in plain-text dumps.

  7. Split func.sgml into more manageable pieces

  8. Fix squashing algorithm for query texts

  9. EXPLAIN: Always use two fractional digits for row counts.

  10. Preliminary refactoring of plpgsql expression construction.

  11. plpgsql: pure parser and reentrant scanner

  12. Add some sanity checks in executor for query ID reporting

  13. Fix misleading error message context

  14. Add macros for looping through a List without a ListCell.

Hi

so 28. 12. 2024 v 11:35 odesílatel jian he <jian.universality@gmail.com>
napsal:

> hi.
>
> src9=# select 'XLogRecPtr'::regtype;
> ERROR:  type "xlogrecptr" does not exist
> LINE 1: select 'XLogRecPtr'::regtype;
>                ^
> so
> + <structfield>varcreate_lsn</structfield> <type>XLogRecPtr</type>
> should be
> <structfield>varcreate_lsn</structfield> <type>pg_lsn</type>
> ?
>

done


>
> also
> +     <row>
> +      <entry role="catalog_table_entry"><para role="column_definition">
> +       <structfield>varcreate_lsn</structfield> <type>XLogRecPtr</type>
> +      </para>
> +      <para>
> +       LSN of the transaction where the variable was created.
> +       <structfield>varcreate_lsn</structfield> and
> +       <structfield>oid</structfield> together form the all-time unique
> +       identifier (<structfield>oid</structfield> alone is not enough,
> since
> +       object identifiers can get reused).
> +      </para></entry>
> +     </row>
> +
> we have "pg_variable_oid_index" PRIMARY KEY, btree (oid)
> for table pg_variable.
> so I am confused by saying the column "oid" itself is not enough to
> prove unique.
>

The session variable is stored in memory until the end of the session.
Theoretically, some sessions with used session variables can be opened for
a very long time without any activity - so it is not possible to process
sinval message. Other sessions can drop and create a lot of session
variables (this is very possible with temporary session variables). Oid in
Postgres can overflow, and postgres can reuse used oid of dropped objects
(oid is only 32bit integer). And after some time, the session with the used
variable can be activated, and the session variable can be used. Before
usage the session variable is rechecked against pg_variable, and
theoretically the variable with the same oid can be there (although it is a
different variable with possibly different type). The implementation should
protect against this scenario. The stored value must not be used in this
case - the usage of old value is dangerous - the calculations with the
variable can lose sense or can crash postgres. LSN is forever unique - it
is 64bit integer - so it is our safeguard so we can detect obsolete values
(stored in memory) although there are variables with the same oid.

oid in pg_variable ensures a unique identifier for any session variable in
one moment. Compound key [oid, varcreate_lsn] is a unique identifier for
ever.



> in let.sgml
> <term><literal>session_variable</literal></term>
> should be
> <term><replaceable class="parameter">session_variable</replaceable></term>
>

done


>
> <term><literal>sql_expression</literal></term>
> should be
> <term><replaceable class="parameter">sql_expression</replaceable></term>
>

done