Re: [GENERAL] Error that shouldn't happen? - Mailing list pgsql-general

From vinny
Subject Re: [GENERAL] Error that shouldn't happen?
Date
Msg-id 08dd8f7512eca8e52ecfddec9921e64e@xs4all.nl
Whole thread Raw
In response to [GENERAL] Error that shouldn't happen?  (Rob Brucks <rob.brucks@rackspace.com>)
List pgsql-general
On 2017-05-18 21:48, Rob Brucks wrote:
> Hello Everyone,
>
> I am unable to figure out how the trigger was able to successfully
> create the table, but then fail creating the index.  I would have
> expected one thread to "win" and create both the table and index, but
> other threads would fail when creating the table… but NOT when
> creating the index.

First, I agree whole heartedly with the other's suggestions to "not do
this".
Create a cronjob of whatever that prepares the required tables before
you need them, empty tables are cheap.

Second: IF EXISTS only tells you that an object exists and is ready for
use.
So what happens when a process is in the middle of creating that object?
Does IF EXISTS tell you it exists or not?


What you need (accepting that this whole trigger based approach is
probably not the best option)
is a proper locking mechanism. A "thundering herd" protection. The first
time the trigger is triggered
it should set a lock (n advisory lock for example) that subsequent calls
to the same trigger
can lok at to see if the table they need is being created at that time,
so they will skip the create commands
and *WAIT* for the first process to complete before using the table.

That *WaIT* is important, and also something you probably don't want,
especially if you have a busy database.


pgsql-general by date:

Previous
From: "Karl O. Pinc"
Date:
Subject: Re: [GENERAL] Serializable isolation -- are predicate locks stillheld across all databases?
Next
From: cen
Date:
Subject: [GENERAL] Weird periodical pg log