Re: Do not lock temp relations
| От | Daniil Davydov |
|---|---|
| Тема | Re: Do not lock temp relations |
| Дата | |
| Msg-id | CAJDiXgiy6H5+_ue1w-=pDNMUEnNu==U8AWR9V7vKOG0oq=jgOw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Do not lock temp relations (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Mon, 30 Sept 2024 at 18:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yes. Our implementation restrictions preclude access to the contents
> of another session's temp tables, but it is not forbidden to do DDL
> on them so long as no content access is required. (Without this,
> it'd be problematic for example to clean out a crashed session's temp
> Yes. Our implementation restrictions preclude access to the contents
> of another session's temp tables, but it is not forbidden to do DDL
> on them so long as no content access is required. (Without this,
> it'd be problematic for example to clean out a crashed session's temp
> tables. See the "orphan temporary tables" logic in autovacuum.c.)
Indeed, a potentially dangerous situation may arise when both the autovacuum and client process attempt to delete the contents of a temporary namespace. But there is a patch (6faca9ae2878c8f642a2e5748d2dbb2b91341bec) that protects us from race condition in this case.
--
Best regards,
Daniil Davydov
On Tue, Oct 22, 2024 at 5:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Maxim Orlov <orlovmg@gmail.com> writes:
> But for the second one: do we really need any lock for temp relations?
Yes. Our implementation restrictions preclude access to the contents
of another session's temp tables, but it is not forbidden to do DDL
on them so long as no content access is required. (Without this,
it'd be problematic for example to clean out a crashed session's temp
tables. See the "orphan temporary tables" logic in autovacuum.c.)
You need fairly realistic locking to ensure that's OK.
regards, tom lane
В списке pgsql-hackers по дате отправления: