Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id CAFj8pRAuSNT76ViXvPJMLv-dXk2U92hzr=awgnXMiw20UJLjmw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


2016-12-26 19:13 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:


2016-12-26 18:20 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:



And how would it interact with some "fully persistent/shared" variables?


I have not any use case for this. I don't know about any similar feature in other database systems. Oracle uses dbms_pipe or dbms_alert for interprocess communication.

I am thinking so it is possible to implement. If it is not ACID, then it can work as custom statistic counters. If it should be ACID? Then is better to use table. What I know, now is preferred share nothing design in parallel systems - so for me, it looks like little bit dangerous feature - and I see only one use case - custom statistics - where possible race condition is not hard issue.

But I don't plan to implement it in first stage. There should be strong use case for implementing any complex feature in shared memory. But any implementation doesn't breaking to implement it in feature.

for custom statistic some extension based on bg worker can be better - sharing variables are risk of race conditions - and developers are people only.

I have not a clean opinion about this - the implementation should not be hard, but I am not sure if this gun I would to give to users.

Regards

Pavel
 

Regards

Pavel

 
--
Fabien.


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Incautious handling of overlength identifiers
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] propose to pushdown qual into EXCEPT