| From: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
|---|---|
| To: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
| Cc: | 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> |
| Subject: | Re: Fix bug with accessing to temporary tables of other sessions |
| Date: | 2026-04-09 14:35:29 |
| Message-ID: | e58a9580-7bbf-4d70-ad99-833fab77cf88@uni-muenster.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Daniil
On 09/04/2026 13:46, Daniil Davydov wrote:
> 1) Right now, read stream seems like an appropriate place for this restriction.
> But actually the StartReadBuffers is not "binded" to the read stream logic. I
> mean that if someone calls it bypassing the "read_stream_begin_relation"
> function (it is OK to do so), then our restriction will be violated again.
> I think that it will be more reliable to add the restriction directly to the
> StartReadBuffers. Also, we can add an assertion ("relation is not other temp
> table") to the PinBufferForBlock. What do you think?> 2) If we decide to leave restriction in the "read_stream_begin_relation"
> function, I would suggest adding a "rel != NULL" check here (read_stream.c):
> + if (RELATION_IS_OTHER_TEMP(rel))
> + ereport(ERROR,
> + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> + errmsg("cannot access temporary relations of other
> sessions")));
> 3) The "rel != NULL" checks may use the "RelationIsValid" macro, which seems
> more pretty to me.
Mm, not so sure...
AFAICT moving the check to StartReadBuffersImpl would require an extra
NULL guard that isn't needed in read_stream_begin_relation, as the
callers already pass valid Relations. So, rel != NULL is not needed.
Also, wouldn't it potentially make this check multiple times in a table
scan?
Am I missing something?
Best, Jim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-04-09 14:40:30 | Re: s/pg_attribute_always_inline/pg_always_inline/? |
| Previous Message | Andres Freund | 2026-04-09 14:34:52 | Re: Adding REPACK [concurrently] |