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
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 |