From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marc Morin <marc@sandvine.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: partitioning and locking problems
Date: Wed, 01 Feb 2006 10:20:21 -0500
Message-ID: <307.1138807221@sss.pgh.pa.us> (raw)
In-Reply-To: <2BCEB9A37A4D354AA276774EE13FB8C263B3E5@mailserver.sandvine.com>
References: <2BCEB9A37A4D354AA276774EE13FB8C263B3E5@mailserver.sandvine.com>
"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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, marc@sandvine.com
Subject: Re: partitioning and locking problems
In-Reply-To: <307.1138807221@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox