Re: GetOldestXmin going backwards is dangerous after all

On 1 February 2013 23:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Feb 1, 2013 at 2:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> In any case, I no longer have much faith in the idea that letting
>>> GetOldestXmin go backwards is really safe.
>
>> That is admittedly kind of weird behavior, but I think one could
>> equally blame this on CLUSTER. This is hardly the first time we've
>> had to patch CLUSTER's handling of TOAST tables (cf commits
>> 21b446dd0927f8f2a187d9461a0d3f11db836f77,
>> 7b0d0e9356963d5c3e4d329a917f5fbb82a2ef05,
>> 83b7584944b3a9df064cccac06822093f1a83793) and it doesn't seem unlikely
>> that we might go the full ten rounds.
>
> Yeah, but I'm not sure whether CLUSTER is the appropriate blamee or
> whether it's more like the canary in the coal mine, first to expose
> problematic behaviors elsewhere. The general problem here is really
> that we're cleaning out toast tuples while the referencing main-heap
> tuple still physically exists. How safe do you think that is?

Agree that CLUSTER is just first to hit the problem. As long as the
problem exists, we have issues.

> That
> did not ever happen before we decoupled autovacuuming of main and toast
> tables, either --- so a good case could be made that that idea is
> fundamentally broken.

It's broken, but not fundamentally. We can decouple the autovacuuming,
as long as we don't decouple the xid used.

"Fixing" GetOldestXmin() seems like the easiest thing to do for
backbranches, but seems a little heavy handed for a general fix -
though doing that will probably close any future thinkos of similar
nature.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services