Re: Simple SQL INSERT to avoid duplication failed: why?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Carlo Stonebanks" <stonec(dot)register(at)sympatico(dot)ca>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Simple SQL INSERT to avoid duplication failed: why?
Date: 2013-04-30 23:11:32
Message-ID: 14798.1367363492@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Carlo Stonebanks" <stonec(dot)register(at)sympatico(dot)ca> writes:
> The only way I can see this happening is that an
> acache_mdx_logic_address_validation sneaks in before the insert and after
> the NOT EXISTS... SELECT. And for that to occur, the client must be mistaken
> and something else MUST be running and inserting into
> acache_mdx_logic_address_validation.

That seems like the way to bet to me. Note that the window can actually
be wider than it might seem because of MVCC considerations --- for
example, if the conflicting insert has been done by an uncommitted
transaction, the EXISTS will fly right past the uncommitted row, but
then the index insertion will wait patiently to see if the conflicting
row commits, whereupon it will throw the error.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Yang Zhang 2013-04-30 23:55:34 OK to put temp tablespace on volatile storage or to omit it from backups?
Previous Message Steven Schlansker 2013-04-30 23:10:27 Re: Simple SQL INSERT to avoid duplication failed: why?