On 2019-02-18 16:42, Andres Freund wrote:
> On February 18, 2019 7:39:25 AM PST, Peter Eisentraut
> wrote:
>> I propose to add an equivalent to unconstify() for volatile. When
>> working on this, I picked the name unvolatize() mostly as a joke, but
>> it
>> appears it's a real word. Other ideas
On 2019-02-25 09:29, Peter Eisentraut wrote:
> On 2019-02-22 21:31, Andres Freund wrote:
>> On 2019-02-22 12:38:35 +0100, Peter Eisentraut wrote:
>>> On 2019-02-19 18:02, Andres Freund wrote:
But even if we were to decide we'd want to keep a volatile in SetLatch()
- which I think really w
On 2019-02-22 21:31, Andres Freund wrote:
> On 2019-02-22 12:38:35 +0100, Peter Eisentraut wrote:
>> On 2019-02-19 18:02, Andres Freund wrote:
>>> But even if we were to decide we'd want to keep a volatile in SetLatch()
>>> - which I think really would only serve to hide bugs - that'd not mean
>>>
Hi,
On 2019-02-22 12:38:35 +0100, Peter Eisentraut wrote:
> On 2019-02-19 18:02, Andres Freund wrote:
> > But even if we were to decide we'd want to keep a volatile in SetLatch()
> > - which I think really would only serve to hide bugs - that'd not mean
> > it's a good idea to keep it on all the o
On 2019-02-19 18:02, Andres Freund wrote:
> Because SetLatch() is careful to have a pg_memory_barrier() before
> touching shared state and conversely so are ResetLatch() (and
> WaitEventSetWait(), which already has no volatiles). And if we've got
> this wrong they aren't safe for shared latches, be
Hi,
On 2019-02-19 11:48:16 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The real reason why variables commonly need to be volatile when used in
> > signal handlers is not the signal handler side, but the normal code flow
> > side.
>
> Yeah, exactly. You have not explained why it'd be safe
Andres Freund writes:
> The real reason why variables commonly need to be volatile when used in
> signal handlers is not the signal handler side, but the normal code flow
> side.
Yeah, exactly. You have not explained why it'd be safe to ignore that.
regards, tom lane
Hi,
On February 19, 2019 7:00:58 AM PST, Peter Eisentraut
wrote:
>On 2019-02-18 21:25, Andres Freund wrote:
>> ISTM this one should rather be solved by removing all volatiles from
>> latch.[ch]. As that's a cross-process concern we can't rely on it
>> anyway (and have placed barriers a few years
On 2019-02-18 21:25, Andres Freund wrote:
> ISTM this one should rather be solved by removing all volatiles from
> latch.[ch]. As that's a cross-process concern we can't rely on it
> anyway (and have placed barriers a few years back to allay concerns /
> bugs due to reordering).
Aren't the volatil
Hi,
On 2019-02-18 16:39:25 +0100, Peter Eisentraut wrote:
> diff --git a/src/backend/storage/ipc/latch.c b/src/backend/storage/ipc/latch.c
> index 7da337d11f..fa7d72ef76 100644
> --- a/src/backend/storage/ipc/latch.c
> +++ b/src/backend/storage/ipc/latch.c
> @@ -381,7 +381,7 @@ WaitLatchOrSocket(v
Petr Jelinek writes:
> On 18/02/2019 16:43, Tom Lane wrote:
>> Umm ... wouldn't this amount to papering over actual bugs?
> I'd argue that it's not making it easier to do but rather easier to spot
> (vs normal type casting) which is IMO a good thing from patch review
> perspective.
Yeah, fair po
On 18/02/2019 16:43, Tom Lane wrote:
> Peter Eisentraut writes:
>> I propose to add an equivalent to unconstify() for volatile. When
>> working on this, I picked the name unvolatize() mostly as a joke, but it
>> appears it's a real word. Other ideas?
>
> Umm ... wouldn't this amount to papering
Hi,
On 2019-02-18 10:43:50 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > I propose to add an equivalent to unconstify() for volatile. When
> > working on this, I picked the name unvolatize() mostly as a joke, but it
> > appears it's a real word. Other ideas?
>
> Umm ... wouldn't this a
Peter Eisentraut writes:
> I propose to add an equivalent to unconstify() for volatile. When
> working on this, I picked the name unvolatize() mostly as a joke, but it
> appears it's a real word. Other ideas?
Umm ... wouldn't this amount to papering over actual bugs? I can
think of legitimate
Hi,
On February 18, 2019 7:39:25 AM PST, Peter Eisentraut
wrote:
>I propose to add an equivalent to unconstify() for volatile. When
>working on this, I picked the name unvolatize() mostly as a joke, but
>it
>appears it's a real word. Other ideas?
Shouldn't we just remove just about all those
I propose to add an equivalent to unconstify() for volatile. When
working on this, I picked the name unvolatize() mostly as a joke, but it
appears it's a real word. Other ideas?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Traini
16 matches
Mail list logo
