Re: The problem is related to concurrent resquests

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "'Nguyen Hoai Nam *EXTERN*'" <namptit307(at)gmail(dot)com>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: The problem is related to concurrent resquests
Date: 2016-05-23 09:32:31
Message-ID: A737B7A37273E048B164557ADEF4A58B53852F56@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Nguyen Hoai Nam wrote:
> Thank you so much for your time. Let me explain my problem:
>
> 1. There are some conditions which I must follow it.
>
> Condition 1: the type of "subnet" is varchar(30),
> Condition 2: currently, I am about to use trigger and function to detect and prevent CIDR overlapping
> (subnet's value)
>
> 2. What I am doing
>
> 2.1 Writing a function can detect overlap CIDR (called cidr_overlap).
[...]
> 2.2 Writing a function for trigger and a trigger as follows:
>
[...]
> - Create trigger:
[...]
>
>
> Please don't follow detail syntax. Something like that. Actually, this method is good active in case
> of request sequently. But in case of we have two resquest which insert to DB at the same time (it mean
> there are concurrent request). Have you ever see this problem, could please give me some advices to
> slove it.

A trigger cannot guarantee that the condition will always be satisfied.
At the time that the concurrent triggers run the SELECT, everything is fine.

Do use an SQL contraint to enforce a table constraint.
If you really need to store "subnet" as varchar (why?), define the constraint like this:

EXCLUDE USING gist (subnet::cidr inet_ops WITH &&)

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message zz_11 2016-05-23 09:49:09 Re: very slow postgresql startup
Previous Message Magnus Hagander 2016-05-23 09:28:36 Re: very slow postgresql startup