On Sun, Jun 22, 2003 at 12:23:18PM -0400, Derek Atkins was heard to remark: > > > Until you have more than one LISTENer... ;) > > > > Yeah, and then its called "highly-distributed parallel virtual RPC" ;> > > Well, the problem is if you have more than one LISTENer then you need
I was joking ... > some way to know when you can garbage-collect the table. If you use > the SQL that you suggested (and cut out from your response above) then > the first LISTENer will delete the table, leaving all that follow > without any RPC data.... So GC becomes an issue. I 'solved' this 'problem' in the postgres backend by calling that table the 'audit trail'. It records the changes 'for all time': thus the GC is not needed or wanted. If you wanted to GC, you could: the PG backend does track sessions; when the session count goes to zero, you could safely blow away the audit trail. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
