| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, dean(dot)a(dot)rasheed(at)gmail(dot)com, joel(at)compiler(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Schema variables - new implementation for Postgres 15 (typo) |
| Date: | 2023-01-24 11:20:51 |
| Message-ID: | CAFj8pRAfGAOK9+cP7N=vsaENSaYc6oSakKx4iCFJ8uxv79RY8A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2023-01-24 11:40:41 | Re: Test failures of 100_bugs.pl |
| Previous Message | Pavel Borisov | 2023-01-24 10:35:21 | Re: old_snapshot_threshold bottleneck on replica |