Re: partitioning and locking problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marc Morin" <marc(at)sandvine(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: partitioning and locking problems
Date: 2006-02-01 15:20:21
Message-ID: 307.1138807221@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Marc Morin" <marc(at)sandvine(dot)com> writes:
> Do you mean it would be impossible to change the code so that existing
> selects continue to use the pre-truncated table until they commit?

Yes, because that table won't exist any more (as in the file's been
unlinked) once the TRUNCATE commits.

> The update/insert rule change appears to be more more doable? No?

You've still got race conditions there: do onlooker transactions see the
old set of rules, or the new set, or some unholy mixture? Removing the
lock as you suggest would make it possible for the rule rewriter to pick
up non-self-consistent data from the system catalogs, leading to
arbitrarily bad behavior ... if you're lucky, it'll just crash, if
you're not lucky the incorrect rule will do a fandango on your data.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-02-01 16:04:44 Re: execution plan : Oracle vs PostgreSQL
Previous Message Marc Morin 2006-02-01 14:25:10 Re: partitioning and locking problems