On Thu, Oct 19, 2017 at 9:03 AM, Peter Geoghegan wrote:
>> /me studies the problem for a while.
>>
>> What's bothering me about this is: how is cutoff_xid managing to be a
>> new enough transaction ID for this to happen in the first place? The
>> cutoff XID should certainly be
On Thu, Oct 19, 2017 at 7:21 AM, Robert Haas wrote:
> The commit message for a5736bf7 doesn't say anything about a race; it
> just claims that it is fixing traversal of half-frozen update chains,
> without making any reference to how such a thing as a half-frozen
> update
On Wed, Oct 18, 2017 at 5:52 PM, Peter Geoghegan wrote:
> There is a race where we cannot prune the page, though. That's why we
> had to revisit what I suppose was a tacit assumption, and address its
> problems in the commit that started this thread (commit a5736bf7).
The commit
On Wed, Oct 18, 2017 at 1:54 PM, Robert Haas wrote:
> Well, I guess what I don't understand is, suppose we have a HOT chain
> that looks like this, where [x,y] denotes a tuple with an xmin of x
> and an xmax of y.
>
> [a,b]->[b,c]->[c,d]
>
> If b is eligible to be frozen,
On Tue, Oct 17, 2017 at 6:02 AM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> I haven't really followed this thread in depth, but I'm very nervous
>> about the idea that we should ever be examining the raw-xmin of a
>> tuple that has been marked HEAP_XMIN_FROZEN for
On Tue, Oct 17, 2017 at 3:02 AM, Alvaro Herrera wrote:
> Yeah, me too. If you see another way to fix the problem, let's discuss
> it.
I doubt that there is a better way.
> I think a possible way is to avoid considering that the relfrozenxid
> value computed by the
Robert Haas wrote:
> I haven't really followed this thread in depth, but I'm very nervous
> about the idea that we should ever be examining the raw-xmin of a
> tuple that has been marked HEAP_XMIN_FROZEN for anything other than
> forensic purposes.
Yeah, me too. If you see another way to fix
On Fri, Oct 13, 2017 at 4:54 AM, Robert Haas wrote:
> I haven't really followed this thread in depth, but I'm very nervous
> about the idea that we should ever be examining the raw-xmin of a
> tuple that has been marked HEAP_XMIN_FROZEN for anything other than
> forensic
On Thu, Oct 12, 2017 at 7:31 PM, Alvaro Herrera wrote:
>> Wouldn't this last "if" test, to cover the pg_upgrade case, be better
>> targeted by comparing *raw* xmin to FrozenTransactionId? You're using
>> the potentially distinct xmin value returned by
>>
Peter Geoghegan wrote:
> On Fri, Oct 6, 2017 at 8:29 AM, Alvaro Herrera
> wrote:
> > /*
> > * When a tuple is frozen, the original Xmin is lost, but we know it's a
> > * committed transaction. So unless the Xmax is InvalidXid, we don't
> > know
> >
10 matches
Mail list logo