Horton

Re: Schema variables - new implementation for Postgres 15 (typo)

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Erik Rijkers <er@xs4all.nl>, Sergey Shinderuk <s.shinderuk@postgrespro.ru>, Tomas Vondra <tomas.vondra@enterprisedb.com>, dean.a.rasheed@gmail.com, joel@compiler.org, pgsql-hackers@lists.postgresql.org
Date: 2023-01-24T11:20:51Z
Lists: pgsql-hackers

Commits

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

  1. Allow underscores in integer and numeric constants.

  2. Remove special outfuncs/readfuncs handling of RangeVar.catalogname.

  3. Remove extra space from dumped ALTER DEFAULT PRIVILEGES.

  4. Create FKs properly when attaching table as partition

  5. psql: improve tab-complete's handling of variant SQL names.

>
> > I can be wrong, but from these numbers I don't think so these sync cycles
> > should to contain CHECK_FOR_INTERRUPTS
> >
> > What do you think?
>
> Well, there is always possibility someone will create more variables
> than any arbitrary limit we have tested for. But I see your point and
> don't have a strong opinion about this, so let's keep it as it is :)
>
>
In this case, I afraid more about possible impacts of canceling than long
operation.

It should be possible to cancel query - but you cannot to cancel followup
operation like memory cleaning or other resource releasing.

The possibility to be cancelled in this cycle means rewriting  processing
to be much more defensive (and slower). And although you can hypothetically
cancel sync cycles, then you should to some time finish these cycles
because you need to clean memory from garbage.

Regards

Pavel







ok :)

If it is an issue, then it can be easily fixed at future, but I don't think

I