Hi,
On Wed, Mar 19, 2025 at 6:32 AM David G. Johnston
wrote:
>
> I'm probably done trying to help with this one - it's beyond my ability and
> desire to contribute to meaningfully. It seems to need to be escalated if
> the regression has a chance of being understood and fixed.
> Some good cand
On Mon, Mar 17, 2025 at 9:27 PM Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Tue, Mar 18, 2025 at 2:36 AM David G. Johnston
> wrote:
> >
> > "I want to give a better error message" is not a good enough reason to
> change this long-standing behavior in a back-patchable bug fix.
> >...
Hi,
On Tue, Mar 18, 2025 at 2:36 AM David G. Johnston
wrote:
>
> "I want to give a better error message" is not a good enough reason to change
> this long-standing behavior in a back-patchable bug fix.
> and I do not agree that it is an improvement worth making in HEAD.
OK, In this case I'd
On Mon, Mar 17, 2025 at 10:58 AM Daniil Davydov <3daniss...@gmail.com>
wrote:
>
> Please see v4 patch (only comment change).
>
>
/*
- * For missing_ok, allow a non-existent schema name to
- * return InvalidOid.
+ * We don't allow users to access temp tables of other
+ * sessions (consider adding
On Mon, Mar 17, 2025 at 10:58 AM Daniil Davydov <3daniss...@gmail.com>
wrote:
> 2)
Is this really the implementation detail that we want to hide from the
> user? User can just run "select pg_my_temp_schema();" and see that
> there is no temp schema in the current session.
>
No ordinary user uses
Hi,
On Mon, Mar 17, 2025 at 10:09 PM David G. Johnston
wrote:
>
> On Monday, March 17, 2025, Daniil Davydov <3daniss...@gmail.com> wrote:
>>
>>
>> >
>> > 2."you have not any temporary relations" --> "you have no any temporary
>> > relations"
>> I am not an English speaker, but it seems that "have
On Sunday, March 16, 2025, Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Sun, Mar 16, 2025 at 7:53 PM vignesh C wrote:
> > I noticed that the following Andrey's comment regarding the isolation
> > test from [1] and Andres's comment from [2] are pending. I'm changing
> > the commitfes
Hi,
On Mon, Mar 17, 2025 at 8:29 PM Steven Niu wrote:
>
> If the (relation->relpersistence == RELPERSISTENCE_TEMP) can ensure the
> myTempNamespace is always valid, then my comment can be ignored.
No, even if we see a temporary table in RangeVarGetRelidExtended,
MyTempNamespace still can be `Inv
On Monday, March 17, 2025, Daniil Davydov <3daniss...@gmail.com> wrote:
>
> >
> > 2."you have not any temporary relations" --> "you have no any temporary
> > relations"
> I am not an English speaker, but it seems that "have not" would be
> more correct. Someone has to judge us :)
>
>
Both are not
在 2025/3/17 18:56, Daniil Davydov 写道:
Hi,
On Mon, Mar 17, 2025 at 5:33 PM Steven Niu wrote:
I mean RangeVarGetRelidExtended(), you deleted the following code:
if (!OidIsValid(myTempNamespace))
relId = InvalidOid; /* this probably can't happen? */
Hm, I got it. Let's start w
Hi,
On Mon, Mar 17, 2025 at 5:33 PM Steven Niu wrote:
>
> I mean RangeVarGetRelidExtended(), you deleted the following code:
>
> if (!OidIsValid(myTempNamespace))
> relId = InvalidOid; /* this probably can't happen? */
Hm, I got it. Let's start with the fact that the comment "this
pr
在 2025/3/17 18:13, Daniil Davydov 写道:
Hi,
On Mon, Mar 17, 2025 at 4:48 PM Steven Niu wrote:
1. namespace.c, if relation->schemaname is pg_temp but myTempNamespace
isn't set, the error information might be misleading. Consider checking
OidIsValid(myTempNamespace) first.
Could you please cl
Hi,
On Mon, Mar 17, 2025 at 4:48 PM Steven Niu wrote:
>
> 1. namespace.c, if relation->schemaname is pg_temp but myTempNamespace
> isn't set, the error information might be misleading. Consider checking
> OidIsValid(myTempNamespace) first.
Could you please clarify exactly which place in the code
Hi,
I have some comments:
1. namespace.c, if relation->schemaname is pg_temp but myTempNamespace
isn't set, the error information might be misleading. Consider checking
OidIsValid(myTempNamespace) first.
2."you have not any temporary relations" --> "you have no any temporary
relations"
3.
Hi,
I see that the presence of isolation tests in the patch is
controversial. First things first, let's concentrate on fixing the
bug.
I attach a new version of patch (for `master` branch) to this letter.
It contains better comments and a few small improvements.
P.S.
Sorry for bad formatting in pr
Hi,
On Mon, Mar 17, 2025 at 1:52 PM David G. Johnston
wrote:
>
> My understanding is the limitation of an owner of a temporary relation in one
> session being disallowed to alter its contents from another session is an
> implementation consequence, and not some fundamental model restriction.
I
Hi,
On Mon, Mar 17, 2025 at 1:15 PM David G. Johnston
wrote:
>
> It’s seems like the bug “session A can read and write to session B’s tables”
> has gotten lost in this thread that pertains to something related but
> different. Solving the bug is not going to involve adding a new GUC.
I don
Hi,
On Sun, Mar 16, 2025 at 7:53 PM vignesh C wrote:
> I noticed that the following Andrey's comment regarding the isolation
> test from [1] and Andres's comment from [2] are pending. I'm changing
> the commitfest entry to Waiting on Author, please provide an updated
> patch and update it to Nee
On Saturday, November 23, 2024, Andrey M. Borodin
wrote:
>
>
> It seems that protection of temp tables should belong to ACL stuff. And in
> a logic of this subsystem would be natural to just allow superuser do
> whatever they want with.
>
My understanding is the limitation of an owner of a tempor
On Thu, 14 Nov 2024 at 14:26, Daniil Davydov <3daniss...@gmail.com> wrote:
>
> On Wed, Oct 30, 2024 at 7:32 PM Rafia Sabih wrote:
>
> > Good catch. I agree with this being an unwarranted behaviour.
> > A minor comment from my end is the wording of the error message.
> > Based on the Postgresql err
Hi,
I'm sorry for the long lull.
Considering that it is still important for some users to be able to
clean other sessions' temporary directories, I suggest adding a GUC
that will allow superuser to do this.
We keep only one option - to drop tables, because only this feature
works properly in postgr
On Sat, 23 Nov 2024 at 21:13, Andrey M. Borodin
wrote:
> What if we say it's not a bug, but a feature. Will it break some contracts
> with user or some functionality?
An important thing to note here. We have to trade off an opportunity to
significantly improve temp tables performance by removin
> On 22 Nov 2024, at 03:02, Andres Freund wrote:
>
> I don't
> love having to put RELATION_IS_OTHER_TEMP() checks everywhere either.
+1. I do not understand why this restriction (protecting temp tables from
access) is a responsibility of the buffer manager.
Actually, I like the idea that su
Hi,
On 2024-11-21 23:52:52 +0300, Andrey M. Borodin wrote:
> I suspect that protection of temp tables was broken by 00d1e02be249.
I think we might have broken this in multiple ways in recent releases. In 17
one can even read the data from the other relation when using a sequential
scan, because t
> On 14 Nov 2024, at 11:55, Daniil Davydov <3daniss...@gmail.com> wrote:
>
> On Wed, Oct 30, 2024 at 7:32 PM Rafia Sabih wrote:
>
>> Good catch. I agree with this being an unwarranted behaviour.
>> A minor comment from my end is the wording of the error message.
>> Based on the Postgresql err
On Thu, 14 Nov 2024 at 09:55, Daniil Davydov <3daniss...@gmail.com> wrote:
> On Wed, Oct 30, 2024 at 7:32 PM Rafia Sabih
> wrote:
>
> > Good catch. I agree with this being an unwarranted behaviour.
> > A minor comment from my end is the wording of the error message.
> > Based on the Postgresql er
On Wed, Oct 30, 2024 at 7:32 PM Rafia Sabih wrote:
> Good catch. I agree with this being an unwarranted behaviour.
> A minor comment from my end is the wording of the error message.
> Based on the Postgresql error message style huide, something like this could
> be better,
> "could not access te
On Tue, 29 Oct 2024 at 07:22, Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
> Thanks for your comments, I appreciate them.
>
> As I continued to deal with the topic of working with temp tables of
> other sessions, I noticed something like a bug. For example
> (REL_17_STABLE):
> Session 1:
> =
Hi, looks good for me, but please fix formatting in temp_tbl_fix.patch!
Hi,
Thanks for your comments, I appreciate them.
As I continued to deal with the topic of working with temp tables of
other sessions, I noticed something like a bug. For example
(REL_17_STABLE):
Session 1:
=# CREATE TEMP TABLE test(id int);
Session 2:
=# INSERT INTO pg_temp_0.test VALUES (1);
=#
On Fri, Oct 25, 2024 at 02:01:23PM -0400, Tom Lane wrote:
> If autovacuum can do it, I don't see a reason to prevent superusers
> from doing it manually.
Being able to do a DROP of a temporary table in a controlled way can
also be very handy when working on a cluster with a corrupted catalog
state
Daniil Davydov <3daniss...@gmail.com> writes:
> I noticed that TRUNCATE and ALTER commands on temporary tables of other
> sessions produce an error "cannot truncate/alter temporary tables of other
> sessions". But are there any reasons to allow us to DROP such tables?
> It seems to me that the only
On Fri, 25 Oct 2024 at 11:02, Daniil Davydov <3daniss...@gmail.com> wrote:
> But are there any reasons to allow us to DROP such tables?
>
Hi!
This topic has already been discussed in [0], I believe. I'm not sure how
it all ended and if there were any changes made in the end. But from the
user's p
Hi,
I noticed that TRUNCATE and ALTER commands on temporary tables of other
sessions produce an error "cannot truncate/alter temporary tables of other
sessions". But are there any reasons to allow us to DROP such tables?
It seems to me that the only case when we may need it is the removal of
orphan
34 matches
Mail list logo
