Re: New Event Trigger: table_rewrite

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New Event Trigger: table_rewrite
Date: 2014-11-19 17:57:21
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Almost the whole of that function is conditions to bail out clustering
> the relation if things have changed since the relation list was
> collected. It seems wrong to invoke the event trigger in all those
> cases; it's going to fire spuriously. I think you should move the
> invocation of the event trigger at the end, just before rebuild_relation
> is called. Not sure where relative to the predicate lock stuff therein;
> probably before, so that we avoid doing that dance if the event trigger
> function decides to jump ship.

Actually when you do a CLUSTER or a VACUUM FULL you know that the
table is going to be rewritten on disk, because that's about the only
purpose of the command.

Given the complexity involved here, the new version of the patch
(attached) has removed support for those statements.

> In ATRewriteTables, it seems wrong to call it after make_new_heap. If
> the event trigger function aborts, we end up with useless work done
> there; so I think it should be called before that. Also, why do you
> have the evt_table_rewrite_fired stuff? I think you should fire one
> event per table, no?

Fixed in the attached version of the patch.

> The second ATRewriteTable call in ATRewriteTables does not actually
> rewrite the table; it only scans it to verify constraints. So I'm
> thinking you shouldn't call this event trigger there. Or, if we decide
> we want this, we probably also need something for the table scans in

Fixed in the attached version of the patch.

> You still have the ANALYZE thing in docs, which now should be removed.

Fixed in the attached version of the patch.

Dimitri Fontaine 06 63 07 10 78 PostgreSQL : Expertise, Formation et Support

Attachment Content-Type Size
table_rewrite.4.patch text/x-patch 53.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-11-19 17:59:33 Re: Increasing test coverage of WAL redo functions
Previous Message Robert Haas 2014-11-19 17:52:24 Re: Doing better at HINTing an appropriate column within errorMissingColumn()