On Thu, Dec 6, 2012 at 3:34 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
I think we need to be solving that problem when we implement new firing
points for event trigger. The 'table_rewrite' event needs to fire at a
time when the code can cope with it. That's the main difficulty in
Robert Haas robertmh...@gmail.com writes:
is needed there, or we may need to move some things from the exec
phase to the prep phase to make it all work out. I think it's totally
doable, but it's not going to be a 50-line patch.
If you want to work on it, please be my guest :)
Regards,
--
On 6 December 2012 00:46, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 5, 2012 at 6:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
Yes, but it is also the trigger writers problem.
Maybe to some degree. I don't think that a server crash or something
like a block-read error is ever
On 2012-12-06 18:21:09 +, Simon Riggs wrote:
On 6 December 2012 00:46, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 5, 2012 at 6:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
Yes, but it is also the trigger writers problem.
Maybe to some degree. I don't think that a server
On 6 December 2012 18:31, Andres Freund and...@2ndquadrant.com wrote:
On 2012-12-06 18:21:09 +, Simon Riggs wrote:
On 6 December 2012 00:46, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 5, 2012 at 6:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
Yes, but it is also the trigger
On 2012-12-06 18:42:22 +, Simon Riggs wrote:
On 6 December 2012 18:31, Andres Freund and...@2ndquadrant.com wrote:
On 2012-12-06 18:21:09 +, Simon Riggs wrote:
On 6 December 2012 00:46, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 5, 2012 at 6:45 PM, Simon Riggs
TABLE ... NOREWRITE option
I don't see any difference between an event trigger and these
statements...
BEGIN;
ALTER TABLE x ...;
SELECT somefunction();
ALTER TABLE y ...;
COMMIT;
Event triggers get called *during* the ALTER TABLE. So if were not careful
they see something thats
;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] ALTER TABLE ... NOREWRITE option
I don't see any difference between an event trigger and these
statements...
BEGIN;
ALTER TABLE x ...;
SELECT somefunction();
ALTER TABLE y ...;
COMMIT;
Event triggers get called *during
Subject: Re: [HACKERS] ALTER TABLE ... NOREWRITE option
Event triggers get called *during* the ALTER TABLE. So if were not
careful they see something thats not easy to handle.
I thought the point of this was to call the trigger *before* anything
happens.
Just because the rewrite hasn't
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-06 18:42:22 +, Simon Riggs wrote:
in-between state means what? And what danger do you see?
For example during table rewrites we have a temporary pg_class entry
thats a full copy of the table, with a separate oid, relfilenode and
On 5 December 2012 00:16, Josh Berkus j...@agliodbs.com wrote:
Sure, and the DevOps staff would be using the EXPLAIN feature (if we had
it). After which they could do little anyway except complain to the ORM
authors, who might or might not give a damn. I don't see that there's
enough
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about the actions taken by
DDL statements. That will also highlight locks and the need to reduce
their lock levels.
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Josh Berkus
Sent: 05 December 2012 01:17
To: Tom Lane
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] ALTER TABLE ... NOREWRITE option
However, as I said
On 5 December 2012 09:46, John R Pierce pie...@hogranch.com wrote:
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about the actions taken by
DDL statements. That
John R Pierce pie...@hogranch.com writes:
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about the actions taken by
DDL statements. That will also highlight
Simon Riggs si...@2ndquadrant.com writes:
On 5 December 2012 09:46, John R Pierce pie...@hogranch.com wrote:
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about
On 5 December 2012 15:01, Tom Lane t...@sss.pgh.pa.us wrote:
John R Pierce pie...@hogranch.com writes:
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about the
Simon Riggs si...@2ndquadrant.com writes:
On 5 December 2012 15:01, Tom Lane t...@sss.pgh.pa.us wrote:
And perhaps more to the point, what's the advantage compared to
good old log_statement = ddl?
That logs DDL statements for the whole system and isn't user settable.
Not true; you can set it
Simon,
And anything which assumes the *absence* of a manual script is also
leaving out a large class of users. ORMs are very important, but not
the only thing we serve.
Yes. In the long run, we'll probably need two solutions. An
interactive EXPLAIN, and something which logs or aborts for
On Wed, Dec 5, 2012 at 1:41 PM, Josh Berkus j...@agliodbs.com wrote:
That's why we need a mechanism which either logs, or aborts on specific
actions. From the perspective of the DevOps staff, abort is possibly
the better option, but there may be issues with it on our end. That was
the
You know, event triggers seem like an awfully good solution to this
problem. All we'd need is a new event called table_rewrite:
CREATE EVENT TRIGGER my_event_trigger
ON table_rewrite
EXECUTE PROCEDURE consider_whether_to_throw_an_error();
Oh, wow, that would be perfect. That
On 5 December 2012 19:15, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 5, 2012 at 1:41 PM, Josh Berkus j...@agliodbs.com wrote:
That's why we need a mechanism which either logs, or aborts on specific
actions. From the perspective of the DevOps staff, abort is possibly
the better
Simon Riggs si...@2ndquadrant.com writes:
CREATE EVENT TRIGGER my_event_trigger
ON table_rewrite
EXECUTE PROCEDURE consider_whether_to_throw_an_error();
+1, I was just thinking that myself.
+1, and I think that can happen for 9.3, as soon as we agree on the list
of code points where
On 5 December 2012 22:21, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Simon Riggs si...@2ndquadrant.com writes:
CREATE EVENT TRIGGER my_event_trigger
ON table_rewrite
EXECUTE PROCEDURE consider_whether_to_throw_an_error();
+1, I was just thinking that myself.
+1, and I think
Simon Riggs si...@2ndquadrant.com writes:
On 5 December 2012 22:21, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Simon Riggs si...@2ndquadrant.com writes:
CREATE EVENT TRIGGER my_event_trigger
ON table_rewrite
EXECUTE PROCEDURE consider_whether_to_throw_an_error();
+1, I was just
On 2012-12-05 22:41:21 +, Simon Riggs wrote:
On 5 December 2012 22:21, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Simon Riggs si...@2ndquadrant.com writes:
CREATE EVENT TRIGGER my_event_trigger
ON table_rewrite
EXECUTE PROCEDURE consider_whether_to_throw_an_error();
On Wed, Dec 5, 2012 at 5:56 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2012-12-05 22:41:21 +, Simon Riggs wrote:
On 5 December 2012 22:21, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Simon Riggs si...@2ndquadrant.com writes:
CREATE EVENT TRIGGER my_event_trigger
ON
On 5 December 2012 22:49, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 5 December 2012 22:21, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Simon Riggs si...@2ndquadrant.com writes:
CREATE EVENT TRIGGER my_event_trigger
ON table_rewrite
On 5 December 2012 23:34, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 5, 2012 at 5:56 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2012-12-05 22:41:21 +, Simon Riggs wrote:
On 5 December 2012 22:21, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Simon Riggs
On Wed, Dec 5, 2012 at 6:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
Yes, but it is also the trigger writers problem.
Maybe to some degree. I don't think that a server crash or something
like a block-read error is ever tolerable though, no matter how silly
the user is with their event
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
Josh Berkus j...@agliodbs.com writes:
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
On 4 December 2012 22:30, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
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
Sure, and the DevOps staff would be using the EXPLAIN feature (if we had
it). After which they could do little anyway except complain to the ORM
authors, who might or might not give a damn. I don't see that there's
enough value-added from what you suggest to justify the development
time.
Noah Misch n...@leadboat.com writes:
Acquiring the lock could still take an unpredictable amount of time.
I think there's a new GUC brewing about setting the lock timeout
separately from the statement timeout, right?
being said, I share Tom's doubts. The DEBUG1 messages are a sorry excuse for
EXPLAIN ALTER TABLE would be the next step I guess. I discovered plenty
of magic tricks when working on the rewriting support for that command,
and I think exposing them in the EXPLAIN output would go a long way
towards reducing some POLA violations.
I think this would be cool on its own
Josh Berkus j...@agliodbs.com writes:
EXPLAIN ALTER TABLE would be the next step I guess. I discovered plenty
of magic tricks when working on the rewriting support for that command,
and I think exposing them in the EXPLAIN output would go a long way
towards reducing some POLA violations.
I
On Mon, Dec 03, 2012 at 11:37:17AM +0100, Dimitri Fontaine wrote:
Noah Misch n...@leadboat.com writes:
Acquiring the lock could still take an unpredictable amount of time.
I think there's a new GUC brewing about setting the lock timeout
separately from the statement timeout, right?
Yes.
On 12/02/2012 03:07 AM, Noah Misch wrote:
On Sat, Dec 01, 2012 at 07:34:51PM +0100, Andres Freund wrote:
On 2012-12-01 18:27:08 +, Simon Riggs wrote:
On 1 December 2012 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
It's hard to know whether your
It's hard to know whether your tables will be locked for long periods
when implementing DDL changes.
The NOREWRITE option would cause an ERROR if the table would be
rewritten by the command.
This would allow testing to highlight long running statements before
code hits production.
--
Simon
Simon Riggs si...@2ndquadrant.com writes:
It's hard to know whether your tables will be locked for long periods
when implementing DDL changes.
The NOREWRITE option would cause an ERROR if the table would be
rewritten by the command.
This would allow testing to highlight long running
On 1 December 2012 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
It's hard to know whether your tables will be locked for long periods
when implementing DDL changes.
The NOREWRITE option would cause an ERROR if the table would be
rewritten by the
On 2012-12-01 18:27:08 +, Simon Riggs wrote:
On 1 December 2012 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
It's hard to know whether your tables will be locked for long periods
when implementing DDL changes.
The NOREWRITE option would cause
I'm not thrilled about inventing YA keyword for this. If you have a
problem with that sort of scenario, why aren't you testing your DDL
on a test server before you do it on production?
*I* do test my DDL. However, there are literally hundreds of thousands
of Rails, Django and Hibernate
On 2012-12-01 12:24:57 -0800, Josh Berkus wrote:
I'm not thrilled about inventing YA keyword for this. If you have a
problem with that sort of scenario, why aren't you testing your DDL
on a test server before you do it on production?
*I* do test my DDL. However, there are literally
If you have a framework and you want to test for this you can just
compare relfilenodes before/after.
You're targeting the wrong users. This feature isn't for helping you or
me. It's for helping the Rails users.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
On 2012-12-01 12:35:15 -0800, Josh Berkus wrote:
If you have a framework and you want to test for this you can just
compare relfilenodes before/after.
You're targeting the wrong users. This feature isn't for helping you or
me. It's for helping the Rails users.
I am not targeting
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Andres Freund
Sent: 01 December 2012 21:40
To: Josh Berkus
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] ALTER TABLE ... NOREWRITE option
On 2012-12-01
On Sat, Dec 01, 2012 at 07:34:51PM +0100, Andres Freund wrote:
On 2012-12-01 18:27:08 +, Simon Riggs wrote:
On 1 December 2012 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
It's hard to know whether your tables will be locked for long periods
49 matches
Mail list logo
