> However in this case, this appears to be a side effect of attempting > to issue CREATE TABLE statements in parallel, and in particular attempting > to create a table of the same name twice in two different processes.
It seems that I dared this approach. > PG developers describe this expected behavior here: > http://www.postgresql.org/message-id/ca+tgmozadyvtwbfp1fl2smzbihcwt4uprzrlnnx1nb30ku3...@mail.gmail.com Does the dialogue on a topic like "Errors on CREATE TABLE IF NOT EXISTS" show any remaining open issues? > I’m not surprised that PG does not prioritize attempting to make > this error more user friendly as this is a very odd and probably > unnecessary use case. I am surprised that this database software show such (unexpected) behaviour. > this has nothing to do with the ORM nor does it really have much > to do with SQLAlchemy as a whole. It makes it more convenient to stress other software components, doesn't it? > You would have this issue in exactly the same way if you were emitting > conflicting CREATE TABLE statements on the DBAPI cursor directly. Thanks for your acknowledgement. > The concurrent creation of tables is an extremely unusual use case > that I would not recommend, but especially when two different > threads/processes are contending to create the same table, Should this use case become more known after the number of processor cores grew in various computers through the years? > that suggests the system attempts to encode data within the database > schema itself; that is, the existence of a table “XYZ” in fact > represents the data “XYZ” being present. I do not try to achieve such a data encoding for my software application at the moment. > Otherwise, the PG developers in that thread suggest this use case > can be facilitated using postgres advisory locks. I am going to try another approach out. * Will it be more useful here to extend a serial database preparation step before records will be stored by background processes simultaneously? * How often will corresponding implementation details need to be redesigned? Regards, Markus -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
