From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TABLE ... NOREWRITE option |
Date: | 2012-12-04 18:11:25 |
Message-ID: | 50BE3CCD.7070505@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> However, for a very large user group -- users with ORMs which do their
>> own DDL migrations -- we could also use a way to log or WARN for table
>> rewrites. Since the ORMs are not gonna do an EXPLAIN.
>
> An ORM is also quite unlikely to pay attention to a warning, much less a
> postmaster log entry ... so your argument seems unfounded from here.
But the DevOps staff *is*.
There's the workflow:
1. developer writes migrations in Rails/Django/Hibernate
2. DevOps staff tests migrations on test machine.
3. DevOps staff looks at logs for rewrites.
The problem with an EXPLAIN path is that you're requiring the developers
to extract the DDL generated by Rails or whatever from the migration,
something to which the framework is not very friendly. So we need a
path for identifying rewrites which doesn't require extracting DDL in
SQL form.
EXCEPT: I just realized, if we have "explain ALTER" then we can just log
explains, no? In which case, problem solved.
Come to think of it, it would be good to warn about ACCESS EXCLUSIVE
locks as well. That's another big booby trap for developers.
Note that "writing stuff to the log" is far from an ideal solution for
this user base. I think they'd rather have "ERROR on REWRITE". It
would be good to have one of the Heroku folks speak up here ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Scott | 2012-12-04 18:31:05 | Re: Slow query: bitmap scan troubles |
Previous Message | Michael Meskes | 2012-12-04 18:06:02 | Re: [PATCH] Patch to fix libecpg.so for isinf missing |