Alvaro Herrera wrote:
> On 2019-Jun-18, Oleksii Kliukin wrote:
>
>> Sorry, I was confused, as I was looking only at
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=de87a084c0a5ac927017cd0834b33a932651cfc9
>>
>> without taking your subsequent commit that silences compiler
On 2019-Jun-18, Oleksii Kliukin wrote:
> Sorry, I was confused, as I was looking only at
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=de87a084c0a5ac927017cd0834b33a932651cfc9
>
> without taking your subsequent commit that silences compiler warnings at
>
Alvaro Herrera wrote:
> On 2019-Jun-16, Oleksii Kliukin wrote:
>
>> Alvaro Herrera wrote:
>>
>>> On 2019-Jun-14, Alvaro Herrera wrote:
>>>
I think there are worse problems here. I tried the attached isolation
spec. Note that the only difference in the two permutations is that s0
On 2019-Jun-16, Alvaro Herrera wrote:
> So, I'm too lazy today to generate a case that fully reproduces the
> deadlock, because you need to stall 's2' a little bit using the
> well-known advisory lock trick, but this one hits the code that would
> re-initialize the variable.
Here's such a case.
On Sun, Jun 16, 2019 at 10:27:25PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2019-Jun-17, Michael Paquier wrote:
>>> Could you revert asap please then?
>
>> Done.
>
> Thanks.
Thanks, Alvaro.
--
Michael
signature.asc
Description: PGP signature
Alvaro Herrera writes:
> On 2019-Jun-17, Michael Paquier wrote:
>> Could you revert asap please then?
> Done.
Thanks.
regards, tom lane
On 2019-Jun-17, Michael Paquier wrote:
> On Sun, Jun 16, 2019 at 09:10:13PM -0400, Tom Lane wrote:
> > Yeah, let's do that. I don't want to risk shipping broken code.
> > We can try again for the next updates.
>
> Could you revert asap please then?
Done.
I initially thought to keep the test
On Sun, Jun 16, 2019 at 09:10:13PM -0400, Tom Lane wrote:
> Yeah, let's do that. I don't want to risk shipping broken code.
> We can try again for the next updates.
Could you revert asap please then?
--
Michael
signature.asc
Description: PGP signature
Alvaro Herrera writes:
> On 2019-Jun-16, Tom Lane wrote:
>> If you're going to push anything before tomorrow's wrap, please do it
>> *now* not later. We're running out of time to get a full sample of
>> buildfarm results.
> Yeah, I had to bail out earlier today, so the only thing I'm confident
On 2019-Jun-16, Tom Lane wrote:
> Alvaro Herrera writes:
> > I'm going to push the change of lifetime of the variable for now.
>
> If you're going to push anything before tomorrow's wrap, please do it
> *now* not later. We're running out of time to get a full sample of
> buildfarm results.
Alvaro Herrera writes:
> I'm going to push the change of lifetime of the variable for now.
If you're going to push anything before tomorrow's wrap, please do it
*now* not later. We're running out of time to get a full sample of
buildfarm results.
regards, tom lane
On 2019-Jun-15, Alvaro Herrera wrote:
> But that's not the danger ... with the current coding, it's initialized
> to false every time through that block; that means the tuple lock will
> never be skipped if we jump back to l3. So the danger is that the first
> iteration sets the variable, then
On 2019-Jun-16, Oleksii Kliukin wrote:
> Alvaro Herrera wrote:
>
> > On 2019-Jun-14, Alvaro Herrera wrote:
> >
> >> I think there are worse problems here. I tried the attached isolation
> >> spec. Note that the only difference in the two permutations is that s0
> >> finishes earlier in one
Alvaro Herrera wrote:
> On 2019-Jun-14, Alvaro Herrera wrote:
>
>> I think there are worse problems here. I tried the attached isolation
>> spec. Note that the only difference in the two permutations is that s0
>> finishes earlier in one than the other; yet the first one works fine and
>> the
On 2019-Jun-14, Alvaro Herrera wrote:
> I think there are worse problems here. I tried the attached isolation
> spec. Note that the only difference in the two permutations is that s0
> finishes earlier in one than the other; yet the first one works fine and
> the second one hangs until killed
Alvaro Herrera writes:
> On 2019-Jun-14, Tom Lane wrote:
>> BTW, after looking around a bit I wonder if this complaint isn't
>> exposing an actual logic bug. Shouldn't skip_tuple_lock have
>> a lifetime similar to first_time?
> I think there are worse problems here. I tried the attached
On 2019-Jun-14, Tom Lane wrote:
> I wrote:
> >> Hm, I don't get that warning. Does this patch silence it, please?
>
> > Uh, no patch attached? But initializing the variable where it's
> > declared would certainly silence it.
>
> BTW, after looking around a bit I wonder if this complaint isn't
17 matches
Mail list logo
