On Sat, 28 Jul 2007, De Leeuw Guy wrote:
> Hello Stephan
>
> Thanks for you respons.
>
> Stephan Szabo a �crit :
> > _PG_fini is called when the file is unloaded, but not at process end,
> > according to the documentation, so I don't think it does what you want.
> >
> No, I make a small test :
> In _PG_fini I create a file and close it (via fopen), I quit pgsql and
> the file are never created, bul a small lsof say me that the module are
> unloaded.
How are you quitting? Do you mean you close the connection to the server?
That's process end, which explicitly is not currently calling _PG_fini.
Right now it's called when you LOAD the file again and it unloads it in
order to reload. If we had a real UNLOAD, that'd presumably do it as well.
> > What data are you managing? If you can palloc it into an appropriately
> > lived context, it might be easier for you to manage.
> >
> I manage a small cache. pfree release the memory, but it's not possible
> to trigger a special action like "save the cache now".
I see, now. You're not trying to clean it up, you're trying to save it.
Yes, I'm not sure if there's a good way to do that right now on
close/transaction boundaries.
If you're managing your state via row triggers, you might be able to use
statement triggers to save them off at statement boundaries, but that
doesn't really help if you need it to only change if the transaction
commits and there might be locking issues.
Constraint triggers might get you close, but you could end up with
redundant events at commit time, and you can't entirely guarantee the
commit will happen if an error happens in a later constraint trigger.
Also, neither of these help if the process dies due to something like
SIGKILL, but hopefully that'd be okay, since the transaction would be
considered aborted.
> > What information do you want?
> >
> I event like "startBegin", "endBegin", "startCopy", "endCopy" ....
Are start and end in the above equivalent to before and after?
> > You can get whether it's a row or transaction event, as well as whether it
> > was insertion, update or delete from the context.data
> How can I detect (in language C) that the trigger work on a transaction
> context or a row context ?
Actually, I miswrote, and you get statement or row context from an
appropriate TRIGGER_FIRED_BY_* macro. You probably can get whether it's
called immediate or deferred as well, but I'm not sure exactly what you'd
need to do in order to access that.
We don't have real transaction event triggers. They get proposed, but the
usual one that people want is commit, but there's wierdness in the
definitions, since before commit triggers could still find their
transaction aborted by a later before commit trigger (or before commit
triggers would be disallowed to error) and after commit triggers can't
really meaningfully error, and so you couldn't ever guarantee that the
event would always happen on a successful commit unless it's an event that
does things that never fail.