On 15.01.2013 21:03, Tom Lane wrote:
Robert Haas<robertmh...@gmail.com>  writes:
On the third hand, the fact that a table is OCDR is recorded in
backend-local storage somewhere, and that storage (unlike the
relcache) had better be reliable.  So maybe there's some way to
finesse it that way.

Hm, keep a flag in that storage you mean?  Yeah, that could possibly
work.

Sounds reasonable.

Until someone gets around to write a patch along those lines, I'm inclined to apply this one liner:

*** a/src/backend/commands/tablecmds.c
--- b/src/backend/commands/tablecmds.c
***************
*** 10124,10130 **** PreCommit_on_commit_actions(void)
                                /* Do nothing (there shouldn't be such entries, 
actually) */
                                break;
                        case ONCOMMIT_DELETE_ROWS:
!                               oids_to_truncate = lappend_oid(oids_to_truncate, 
oc->relid);
                                break;
                        case ONCOMMIT_DROP:
                                {
--- 10124,10136 ----
                                /* Do nothing (there shouldn't be such entries, 
actually) */
                                break;
                        case ONCOMMIT_DELETE_ROWS:
!                               /*
!                                * If this transaction hasn't accessed any 
temporary relations,
!                                * we can skip truncating ON COMMIT DELETE ROWS 
tables, as
!                                * they must still be empty.
!                                */
!                               if (MyXactAccessedTempRel)
!                                       oids_to_truncate = 
lappend_oid(oids_to_truncate, oc->relid);
                                break;
                        case ONCOMMIT_DROP:
                                {

We already have that MyXactAccessedTempRel global flag. Just checking that should cover many common cases.

- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to