Re: Proposal: Store "timestamptz" of database creation on "pg_database"

* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> I don't think autonomous transactions are the biggest worry
> here. Transactions essentially already span multiple databases, so thats
> not really a problem in this context. Making it possible to change
> catalogs while still being active in another database seems *far*
> harder. To the point where I would say its not really feasible.

There's two pieces- one is changing catalogs and the other is being able
to have multiple top-level transactions running in a single backend. I
agree that transactions already span multiple databases but I was
expecting the global event trigger to need to run in its own transaction
in the other database, similar to autonomous transactions (though those
could be running in the same database, thus omitting the catalog switch
issue). Spawning a new backend which connects to any database and gets
a new transaction would handle both, which is what I was thinking about.

> A shared table for event triggers sounds like it would be the far easier
> solution (9.4+ that is).

But what happens when it fires and tries to insert a record into a
table..? Does that table have to exist in every database or the event
fails? If it exists in every database, the admin/user/whomever has to
go hunting through all the databases to get a complete picture..
Neither is very good, imv.

Thanks,

Stephen