On Thu, Apr 7, 2016 at 12:20 PM, Kevin Grittner wrote:
> On Thu, Apr 7, 2016 at 8:49 AM, Thomas Munro
> wrote:
>
>> Here is a version that includes an attempt to describe the
>> situation in the documentation.
>
> Pushed with minor adjustments to the docs. Mostly I thought your
> new text was mo
On Thu, Apr 7, 2016 at 8:49 AM, Thomas Munro
wrote:
> Here is a version that includes an attempt to describe the
> situation in the documentation.
Pushed with minor adjustments to the docs. Mostly I thought your
new text was more appropriate as just another paragraph than as a
"note". The prev
On Thu, Apr 7, 2016 at 10:42 PM, Kevin Grittner wrote:
> On Thu, Apr 7, 2016 at 3:26 AM, Simon Riggs wrote:
>
>> We agree its a bug, so the deadline doesn't need to constrain us.
>
> I'm not sure there is consensus across the community on that.
>
>> I suggest we should apply what we have then fix
On Thu, Apr 7, 2016 at 3:26 AM, Simon Riggs wrote:
> We agree its a bug, so the deadline doesn't need to constrain us.
I'm not sure there is consensus across the community on that.
> I suggest we should apply what we have then fix the rest later
> when we work out how.
On that, I agree. I wil
On 7 April 2016 at 08:55, Michael Paquier wrote:
> On Sun, Mar 27, 2016 at 8:15 AM, Thomas Munro
> wrote:
> > Realistically I'm not going to have a solution to the third problem
> > before the 31st.
>
> Ping.
>
We agree its a bug, so the deadline doesn't need to constrain us.
I suggest we shou
On Sun, Mar 27, 2016 at 8:15 AM, Thomas Munro
wrote:
> Realistically I'm not going to have a solution to the third problem
> before the 31st.
Ping.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
On Sat, Mar 26, 2016 at 5:04 AM, David Steele wrote:
> Hi Thomas,
>
> On 3/13/16 8:20 PM, Thomas Munro wrote:
>
>> <...> I will have another look at this in
>> a few days but for now I need to do some other things, so I'm posting
>> these observations in case they are in some way helpful...
>
>
>
On Sat, Mar 12, 2016 at 1:25 AM, Kevin Grittner wrote:
> On Thu, Mar 10, 2016 at 11:31 PM, Thomas Munro
> wrote:
>
>> Here's a much simpler version with more comments
>
>> It handles the same set of isolation test specs.
>
> I'm impressed that you found a one-line patch that seems to get us
> 90%
On Thu, Mar 10, 2016 at 11:31 PM, Thomas Munro
wrote:
> Here's a much simpler version with more comments
> It handles the same set of isolation test specs.
I'm impressed that you found a one-line patch that seems to get us
90% of the way to a new guarantee; but I think if we're going to do
some
On Thu, Mar 10, 2016 at 1:50 PM, Simon Riggs wrote:
> On 3 February 2016 at 23:12, Thomas Munro
> wrote:
>
>> It quacks suspiciously like a bug.
>
> Agreed
>
> What's more important is that is very publicly a bug in the eyes
> of others and should be fixed and backpatched soon.
I really am ske
On Fri, Mar 11, 2016 at 6:31 PM, Thomas Munro
wrote:
> This patch introduces a drop-in replacement
> check_unique_tuple_still_live to call instead of heap_hot_search. The
> replacement function also calls heap_hot_search_buffer, but while it
> has the buffer it takes the opportunity to do an SSI
On Fri, Mar 11, 2016 at 6:31 PM, Thomas Munro
wrote:
> I'm not sure what to make of the pre-existing comment about following
> HOT-chains and concurrent index builds (which I moved). Does it mean
> there is some way that CREATE INDEX CONCURRENTLY could cause us to
> consider the wrong tuple and m
On Fri, Mar 11, 2016 at 10:00 AM, Simon Riggs wrote:
> On 10 March 2016 at 20:36, Thomas Munro
> wrote:
>>
>> On Fri, Mar 11, 2016 at 8:50 AM, Simon Riggs
>> wrote:
>> > On 3 February 2016 at 23:12, Thomas Munro
>> >
>> > wrote:
>> >
>> >>
>> >> It quacks suspiciously like a bug.
>> >
>> >
>>
On 10 March 2016 at 20:36, Thomas Munro
wrote:
> On Fri, Mar 11, 2016 at 8:50 AM, Simon Riggs
> wrote:
> > On 3 February 2016 at 23:12, Thomas Munro >
> > wrote:
> >
> >>
> >> It quacks suspiciously like a bug.
> >
> >
> > Agreed
> >
> > What's more important is that is very publicly a bug in
On Fri, Mar 11, 2016 at 8:50 AM, Simon Riggs wrote:
> On 3 February 2016 at 23:12, Thomas Munro
> wrote:
>
>>
>> It quacks suspiciously like a bug.
>
>
> Agreed
>
> What's more important is that is very publicly a bug in the eyes of others
> and should be fixed and backpatched soon.
>
> We have
On 3 February 2016 at 23:12, Thomas Munro
wrote:
> It quacks suspiciously like a bug.
>
Agreed
What's more important is that is very publicly a bug in the eyes of others
and should be fixed and backpatched soon.
We have a maintenance release coming in a couple of weeks and I'd like to
see th
On Wed, Feb 3, 2016 at 5:12 PM, Thomas Munro
wrote:
> I don't see it as a difficult choice between two reasonable
> alternatives. It quacks suspiciously like a bug.
That seems a little strong to me; I think it would be an
unacceptable change in behavior to back-patch this, for example.
On the o
On Wed, Feb 3, 2016 at 10:48 AM, Robert Haas wrote:
> I don't feel qualified to have an opinion on whether this is an
> improvement. I'm a little skeptical of changes like this on general
> principle because sometimes one clientele wants error A to be reported
> rather than error B and some other
On Thu, Feb 4, 2016 at 7:48 AM, Robert Haas wrote:
> On Sun, Jan 31, 2016 at 5:19 PM, Thomas Munro
> wrote:
>> As described in a recent Reddit discussion[1] and bug report 9301[2],
>> there are scenarios where overlapping concurrent read-write sequences
>> produce serialization failures without c
On Sun, Jan 31, 2016 at 5:19 PM, Thomas Munro
wrote:
> As described in a recent Reddit discussion[1] and bug report 9301[2],
> there are scenarios where overlapping concurrent read-write sequences
> produce serialization failures without constraints, but produce
> constraint violations when there
Hi hackers,
As described in a recent Reddit discussion[1] and bug report 9301[2],
there are scenarios where overlapping concurrent read-write sequences
produce serialization failures without constraints, but produce
constraint violations when there is a unique constraint. A simple
example is deci
21 matches
Mail list logo
