Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I've hacked the whole thing enough that I fixed most of the issues.
> However this one I don't know how to handle. What I need to do is
> compare each database's frozen Xid with the current transaction Id.
> I can get the frozenxid from the flatfile -- however I don't have
> anything with which to compare it. I tried ReadNewTransactionId(), but
> it doesn't work because it tries to acquire a LWLock, which isn't
> possible because we don't have a PGPROC before connecting to a database.
> I guess I could the Xid from pg_control. This seems unclean however.
> Opinions about doing that? Better ideas?
Getting it from pg_control isn't that bad; the value could be as old as
the last checkpoint, but that should be close enough for this purpose.
The only alternative I can see is for the stats daemon to try to track
recent values of nextXID and include the latest in the stats datafile.
You really wouldn't want to put XID into every stats message, but you
could put it into PgStat_MsgAutovacStart say, so that each autovac run
would seed the XID information for the next run. On the whole it's not
clear this is cleaner than looking to pg_control.
regards, tom lane