Simon Riggs <si...@2ndquadrant.com> writes: > On Thu, Oct 27, 2011 at 12:36 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Oct 27, 2011 at 5:37 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> It's much easier to understand that StartupCLOG() is actually a no-op >>> and that we need to trim the clog at the end of recovery in all cases.
>> If it's a no-op, why have it at all? > It is a no-op for exactly the same reason other similar functions are > no-ops - it used to do something but now does not. > Anyone seeing StartupSubtrans and StartupMultiXact but no StartupClog > will immediately ask "why?". I think it's a good point that StartupCLog doesn't exist in a vacuum but should be parallel to the init functions for the other SLRU modules. So at this point I think I agree with Simon's approach. However, the obvious next question is whether those other modules don't need to be changed also, and if not why not. Another issue is that if StartupCLog is left as a no-op, what will happen if someone mistakenly tries to access clog before the trim function is called? It would be a good idea to make sure that such a thing results in an easily-identifiable failure. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers