Content-Type: text/plain; charset=UTF-8
Cc: Pg Bugs <pgsql-bugs@postgresql.org>
Subject: Re: Errors on CREATE TABLE IF NOT EXISTS
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Matteo Beccati <php@beccati.com>
In-reply-to: <4F9541D3.1000202@beccati.com>
References: <4F9541D3.1000202@beccati.com>
Date: Tue, 01 May 2012 15:36:24 -0400
Message-Id: <1335900770-sup-854@alvh.no-ip.org>
User-Agent: Sup/git
Content-Transfer-Encoding: quoted-printable


Excerpts from Matteo Beccati's message of lun abr 23 08:49:39 -0300 2012:
> Hi,
>=20
> I've recently seen a few errors on our continuous integration system=20
> during a test using a badly written partitioning trigger. The function=20
> was basically checking for the existence of the partition table at ever=
y=20
> insert and was running a CREATE TABLE IF NOT EXISTS statement in case i=
t=20
> was needed. What baffled me was that the function was exiting with an=20
> ERROR, rather than succeeding with a NOTICE, e.g.:

The question you were asking has already been answered, but I think it's
worth pointing out that a partitioned-insert trigger that has to check
whether the partition exist beforehand is a lot slower than one that
doesn't have to.  Our usual suggestion is to create the partitions by
some other means, e.g. create a couple months worth of weekly
partitions, a couple of months ahead of time, via cron.  The insert
trigger is then assured that the partition exists, and it can become
faster by not having to check.

--=20
=C3=81lvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support