Re: partitioning and locking problems - Mailing list pgsql-performance

From Tom Lane
Subject Re: partitioning and locking problems
Date
Msg-id 307.1138807221@sss.pgh.pa.us
Whole thread Raw
In response to Re: partitioning and locking problems  ("Marc Morin" <marc@sandvine.com>)
Responses Re: partitioning and locking problems
List pgsql-performance
"Marc Morin" <marc@sandvine.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

pgsql-performance by date:

Previous
From: "Marc Morin"
Date:
Subject: Re: partitioning and locking problems
Next
From: Tom Lane
Date:
Subject: Re: execution plan : Oracle vs PostgreSQL