On 10 October 2016 at 14:49, Merlin Moncure wrote:
> MVCC rules (which DDL generally fall under) try to interleave work as
> much as possible which is the problem you're facing.
Mmff. Yes, that exposes a fundamental misunderstanding on my part: I
had thought that under MVCC things were done indep
On Thu, Oct 6, 2016 at 4:21 AM, Geoff Winkless wrote:
> Hi
>
> I have code that does (inside a single transaction)
>
> DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
>
> Occasionally this produces
>
> ERROR: duplicate key value violates unique constraint
> "pg_type_typname_nsp_index" DETA
On 6 October 2016 at 18:33, Tom Lane wrote:
> I'm a bit confused about exactly what the context is here. AFAICS,
> the fragment you quoted should work as you expect, as long as the
> table always exists beforehand. Then, the DROPs serialize the
> transactions' access to the table and all is well.
On 6 October 2016 at 18:25, Adrian Klaver wrote:
> I do not see sarcasm, I see someone trying to work through what is a complex
> scenario.
When someone talks about things "magically working as you think it
should" I see sarcasm. Perhaps I misread, in which case I apologise.
>> _As far as the tr
Geoff Winkless writes:
> On 6 October 2016 at 16:47, Kevin Grittner wrote:
>> I recommend using a transactional advisory lock to serialize these.
> Thanks Kevin, that does seem like the best (although not particularly
> pleasant) solution.
I'm a bit confused about exactly what the context is he
On 10/06/2016 09:09 AM, Geoff Winkless wrote:
On 6 October 2016 at 16:57, Francisco Olarte wrote:
You are contradicting yourself. First you say after the command it
must not exist. Then you say to do it at commit time. If it is done at
commit time you cannot guarantee it does not exist after th
On 6 October 2016 at 16:47, Kevin Grittner wrote:
> I recommend using a transactional advisory lock to serialize these.
Thanks Kevin, that does seem like the best (although not particularly
pleasant) solution.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
On 6 October 2016 at 16:57, Francisco Olarte wrote:
> You are contradicting yourself. First you say after the command it
> must not exist. Then you say to do it at commit time. If it is done at
> commit time you cannot guarantee it does not exist after the command.
I'm not contradicting myself at
Geoff:
On Thu, Oct 6, 2016 at 5:43 PM, Geoff Winkless wrote:
> Nope. Serializable ignores the DROP, and then freezes on CREATE (and
> then fails when the first transaction COMMITs).
Yep, I tested it too.
> Which is also broken,
> because the transaction should fail if (at COMMIT time) the table
On Thu, Oct 6, 2016 at 9:31 AM, Adrian Klaver wrote:
> This is how I can trigger the ERROR:
>
> Session 1:
>
> test=# begin ;
> BEGIN
> test=# drop table if exists ddl_test;
> NOTICE: table "ddl_test" does not exist, skipping
> DROP TABLE
> test=# create table ddl_test(id int);
> CREATE TABLE
>
Adrian:
On Thu, Oct 6, 2016 at 4:31 PM, Adrian Klaver wrote:
> This is how I can trigger the ERROR:
This is how you can trigger the ISSUE, IMO it is a correct behaviour.
Anyway, your example lacks some important details:
1.- SHOW your isolation level.
2.- SHOW your command interleaving.
Here i
On 6 October 2016 at 15:04, Francisco Olarte wrote:
> And anyway, what isolation level are you working on? Because it seems
> you are using a weaker one than serializable, as I think serializable
> should give you more or less what you are expecting ( not on commit
> time, but second drop could pr
On 10/06/2016 02:21 AM, Geoff Winkless wrote:
Hi
I have code that does (inside a single transaction)
DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
Occasionally this produces
ERROR: duplicate key value violates unique constraint
"pg_type_typname_nsp_index" DETAIL: Key (typname,
typna
Hi Geoff:
On Thu, Oct 6, 2016 at 1:58 PM, Geoff Winkless wrote:
> But surely Transactional DDL implies that (it should appear that) nothing
> happens until transaction-commit. That means "drop table if exists" should
> drop the table if it exists at commit time, not drop the table if it didn't
>
On 6 Oct 2016 12:06 p.m., "Francisco Olarte" wrote:
>
> On Thu, Oct 6, 2016 at 11:21 AM, Geoff Winkless
wrote:
> > DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
> >
> > Occasionally this produces
> >
> > ERROR: duplicate key value violates unique constraint
> > "pg_type_typname_nsp_inde
On Thu, Oct 6, 2016 at 11:21 AM, Geoff Winkless wrote:
> DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
>
> Occasionally this produces
>
> ERROR: duplicate key value violates unique constraint
> "pg_type_typname_nsp_index" DETAIL: Key (typname,
> typnamespace)=(mytable, 2200) already exis
Hi
I have code that does (inside a single transaction)
DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
Occasionally this produces
ERROR: duplicate key value violates unique constraint
"pg_type_typname_nsp_index" DETAIL: Key (typname,
typnamespace)=(mytable, 2200) already exists.
I can
17 matches
Mail list logo
