Re: TRUNCATE SERIALIZABLE and frozen COPY

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)mail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TRUNCATE SERIALIZABLE and frozen COPY
Date: 2012-11-12 16:10:50
Message-ID: CA+TgmobgFLC+506vEyJH4WwFYHL6QcCv_XbX01nU=TrcOi4Thg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 9, 2012 at 3:31 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> So what we're talking about here is a new mode for COPY, that when
> requested will pre-freeze tuples when loading into a newly
> created/truncated table. If the table isn't newly created/truncated
> then we'll just ignore it and continue. I see no need to throw an
> error, since that will just cause annoying usability issues.

Actually, why not just have it work always? If people want to load
frozen tuples into a table that's not newly created/truncated, why not
let them? Sure, there could be MVCC violations, but as long as the
behavior is opt-in, who cares? I think it'd be useful to a lot of
people.

If we want to reduce (not eliminate) the potential MVCC issues, which
I think would be a good idea, we could take AccessExclusiveLock on the
table when COPY (FREEZE) is used. Someone using an old snapshot but
accessing the table for the first time after AEL is released could
still see MVCC anomalies, but at least it would rule out things
changing in mid-query, which is the case that I think would be most
problematic.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-11-12 16:11:03 Re: Further pg_upgrade analysis for many tables
Previous Message Bruce Momjian 2012-11-12 16:05:32 Re: Further pg_upgrade analysis for many tables