So I have a scenario in which account creation at the application
layer generates a set of tables and indexes. The tables created have
foreign keys to tables in use (and frequently read from and written
to) by the rest of the application. Occasionally I was getting
deadlocks, and this definitel
So I have a scenario in which account creation at the application layer
generates a set of tables and indexes. The tables created have foreign
keys to tables in use (and frequently read from and written to) by the
rest of the application. Occasionally I was getting deadlocks, and this
definitel
On Sat, Apr 23, 2005 at 10:36:00AM -0500, Thomas F.O'Connell wrote:
>
> Why would DDL statements in a transaction cause deadlocks? I understand
> the prevention of concurrent access, but I'm curious to know more about
> how deadlocks arise in this situation, as this is something I've seen
> in a
Why would DDL statements in a transaction cause deadlocks? I understand
the prevention of concurrent access, but I'm curious to know more about
how deadlocks arise in this situation, as this is something I've seen
in a production environment during transactional DDL traffic. Why would
DDL state
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> I wasn't able to find where this is spelled out in the documentation,
> but I believe all DDL commands except DROP DATABASE can be rolled back now.
I don't think there's any all-in-one-place statement about it, but
anything that doesn't explicitly obje
On Fri, Apr 22, 2005 at 11:34:29 +0100,
David Roussel <[EMAIL PROTECTED]> wrote:
>
> > I usually put DDL statements in a transaction, for a couple of
> > reasons: so that a mistake doesn't leave me with half-done work
> > (any error will cause the entire transaction to roll back), and to
> > mak
On Fri, Apr 22, 2005 at 11:34:29AM +0100, David Roussel wrote:
>
> > I usually put DDL statements in a transaction, for a couple of
> > reasons: so that a mistake doesn't leave me with half-done work
> > (any error will cause the entire transaction to roll back), and to
> > make the changes atomic
> I usually put DDL statements in a transaction, for a couple of
> reasons: so that a mistake doesn't leave me with half-done work
> (any error will cause the entire transaction to roll back), and to
> make the changes atomic for the benefit of other transactions.
Can you do that in postgres? Wi
On Thu, Apr 21, 2005 at 09:24:49PM -0500, John Browne wrote:
>
> Ok, I've been using postgres for a-while now, and am curious how you
> guys handle this. What is the best way to make modifications to
> tables that have lots of dependent objects, like views? Do you just
> do the obvious drop...cas
Ok, I've been using postgres for a-while now, and am curious how you
guys handle this. What is the best way to make modifications to
tables that have lots of dependent objects, like views? Do you just
do the obvious drop...cascade and manually re-create your views? Do
you keep your "create view"
10 matches
Mail list logo
