Re: First draft of snapshot snapshot building design document

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, hlinnakangas(at)vmware(dot)com
Subject: Re: First draft of snapshot snapshot building design document
Date: 2012-10-19 16:56:08
Message-ID: 201210191856.13234.andres@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday, October 19, 2012 06:38:30 PM Robert Haas wrote:
> On Thu, Oct 18, 2012 at 11:20 AM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:
> > 2) We need to decide whether a HEAP[1-2]_* record did catalog changes
> > when building/updating snapshots. Unfortunately we also need to do this
> > *before* we built the first snapshot. For now treating all tables as
> > catalog modifying before we built the snapshot seems to work fine.
> > I think encoding the oid in the xlog header wouln't help all that much
> > here, because I am pretty sure we want to have the set of "catalog
> > tables" to be extensible at some point...
>
> I don't like catalog-only snapshots at all. I think that's just a
> recipe for subtle or not-so-subtle breakage down the road...

I really don't see this changing for now. At some point we need to draw the
line otherwise we will never ever get anywhere. Naively building a snapshot
that can access normal tables is just too expensive because it changes all the
time.

Sure, obvious breakage will be there if you have a datatype that accesses
other user-tables during decoding (as we talked about previously). But subtle
breakage should be easily catchable by simply not allowing to open user
relations.
If an extension needs this it will have to mark the table as catalog ones for
now. I find this to be a reasonable restriction.

Greetings,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-10-19 16:59:33 Re: assertion failure w/extended query protocol
Previous Message Peter Geoghegan 2012-10-19 16:41:27 Re: assertion failure w/extended query protocol