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
33 matches
Mail list logo
