Re: [HACKERS] Proper cleanup at backend exit

>
> I have been looking into the problem reported by Massimo, and also seen
> by me, that backends sometimes exit without cleaning up entries they
> made in the pg_listener table. I have fixed several contributing bugs
> (having to do with the limited size of the on_shmem_exit table), but

could you explain this to us ?

> I still see the problem occasionally.
>
> I just discovered one fairly fundamental reason why there's still a
> problem:
>
> test=> listen test;
> LISTEN
> test=> begin;
> BEGIN
> test=> \q
> $
>
> (start new psql)
>
> test=> select * from pg_listener;
> relname|listenerpid|notification
> -------+-----------+------------
> test | 20024| 0
> (1 row)
>
> Oops. It would seem that async.c is *trying* to clean up, but the
> changes are thrown away because they are considered part of a
> never-committed transaction :-(. More generally, I believe that
> a backend killed in the middle of any individual SQL statement will
> fail to remove its LISTEN entries, because it will think that any
> database changes made just before exit ought to be discarded.

This is correct in some sense. Any change made but not commited should
never be seen in the table, so the tuple is not deleted.

> If we want a backend to clean out its pg_listen entries at shutdown,
> it looks to me like backend exit will have to work like this:
>
> 1. Abort the current transaction, if any, and exit the current
> transaction block, if any.
>
> 2. Perform LISTEN cleanup within a new transaction. Commit this
> transaction.
>
> 3. Continue with closing up shop.
>
> I don't know whether there are any other things besides LISTEN cleanup
> that really need to be done, not discarded, during backend exit. If
> there are, then we probably ought to restructure the exit sequence to
> handle this cleanly. But I'm worried about doing this much processing
> during backend exit --- if you're trying to kill a backend that's gone
> wrong, the last thing you want is for it to start doing new
> transactions.
>
> (BTW, that last thought also says that we *still* won't be able to get
> rid of pg_listen entries 100% reliably. In a panic exit scenario,
> ie after one backend has crashed, none of the backends will clean up
> their pg_listen entries. We dare not tamper with that. At least
> I dare not.)
>
> I'm half tempted to say that we should rip out the cleanup code and
> not even try to remove pg_listener entries at backend exit. They'll
> go away anyway over time, because the next notifier to try to notify
> that relation name will delete the entries when he discovers he can't
> signal that backend PID anymore. So cleanup-at-exit is not at all a
> critical function, and it's hard to justify a bunch of new complexity
> just for this.
>
> Comments? This depends a lot on whether you think LISTEN cleanup
> is a unique case, or whether there will be other standard cleanup
> activities that a backend ought to perform. (Is there such a thing
> as an ON EXIT hook in SQL?)

The code should be left if it works in the normal case.
I believe that some tuples left in pg_listener don't do any harm because
they refer to dead backends and the notify code can detect this situation
and delete the dead tuples. Anyway for safety I always truncate the file
to 0 in the shell loop that keeps the postmaster alive. Also a vacuum every
few hours doesn't hurt.

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
| Massimo Dal Zotto email: dz(at)cs(dot)unitn(dot)it |
| Via Marconi, 141 phone: ++39-461-534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: finger dz(at)tango(dot)cs(dot)unitn(dot)it |
+----------------------------------------------------------------------+