Re: proposal: session server side variables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: proposal: session server side variables
Date: 2017-01-04 17:58:08
Message-ID: CAFj8pRABsJcjkuNo136sJwxrWNcjvXnH_2X3CHRizv7_DykkHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2017-01-04 18:49 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> ok understand
>>
>
> Good. So we seem to agree that GUCS are transactional?
>
> The logic depends on transactions and on nesting level (nesting doesn't
>> depends on transactions only)
>>
>
> Yep, it probably also happens with LOCAL which hides the previous value
> and restores the initial one when exiting.
>
> void AtEOXact_GUC(bool isCommit, int nestLevel)
>>
>> Probably we should to use CallXactCallbacks instead - then is not a
>> performance impact when there are not transactional variables.
>>
>
> I do not understand your point.
>

It is on critical path, so every check increase computer time for
transaction end.

Regards

Pavel

>
> It is a very good thing that GUCs are transactional, and this should not
> be changed, it is a useful feature! Much more useful than non transactional.
>

Personally, I never used - although I using often nesting

regards

Pavel

>
> Moreover I think that transactional is expensive when writing things to
> disk, but in memory the overhead is reduced, and if you need it then you
> need it.
>
> --
> Fabien.
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2017-01-04 18:15:31 Re: rewrite HeapSatisfiesHOTAndKey
Previous Message Fabien COELHO 2017-01-04 17:49:56 Re: proposal: session server side variables