| From: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
|---|---|
| To: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
| Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Soumya S Murali <soumyamurali(dot)work(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stepan Neretin <slpmcf(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Mohamed Ali <moali(dot)pg(at)gmail(dot)com>, Nazneen Jafri <jafrinazneen(at)gmail(dot)com>, Shawn McCoy <shawn(dot)the(dot)mccoy(at)gmail(dot)com> |
| Subject: | Re: Fix bug with accessing to temporary tables of other sessions |
| Date: | 2026-05-03 12:49:03 |
| Message-ID: | 0e666e40-d003-4c92-95cf-1a33a647401f@uni-muenster.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Daniil
On 03/05/2026 10:53, Daniil Davydov wrote:
> Autovacuum locks orphaned table's oid before deleting it. LOCK TABLE command
> also locks the oid of the specified table. If we want to make sure that
> autovacuum can acquire the mentioned lock (i.e. cover this behavior using
> tests), I suggest testing it using the LOCK TABLE command.
+1 for the extra test.
> Please, see the attached patch that ensures that cross-session LOCK TABLE works
> properly.
I guess you should either add it to the 0001 sent by Alexander, or
create a 0003. Right now the cfbot is complaining, as
013_temp_obj_multisession.pl still does not exist :)
Best, Jim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Smolkin Grigory | 2026-05-03 14:04:09 | Streaming replication and WAL archive interactions |
| Previous Message | Chengpeng Yan | 2026-05-03 12:46:46 | Re: Add a greedy join search algorithm to handle large join problems |