hot standby - further cleanup of recovery procs stuff - Mailing list pgsql-hackers

From Robert Haas
Subject hot standby - further cleanup of recovery procs stuff
Date
Msg-id 603c8f070908202000n788e59a8s4102e2cfc2349b4c@mail.gmail.com
Whole thread Raw
Responses Re: hot standby - further cleanup of recovery procs stuff  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
I've made a few further cleanups to the hot standby patch:

- UnobservedTransactionsRemoveXids() had an argument called
missing_in_error which was always set to false.  So I removed the
argument and the elog().
[It's an interesting question whether this should be considered an
error, but if we're always going to pass false there's no point in
having the check.]
- Fix compiler warnings in ProcArrayDisplay().  On my system this
generated too: one because index was used without initializing it, and
a second because there was no function prototype.  index was only used
once; I think it was intended to be the same as xid_index, so I merged
them.
- Reverted all the changes to ProcArrayAdd() and ProcArrayRemove() as
compared with CVS HEAD.  Now that RecoveryProcs are gone, none of this
looks to be necessary.
- Modified CreateSharedProcArray() to no longer add MaxBackends to
procArray->maxProcs twice.  This appears to be another RecoveryProcs
holdover.
- Adjusted a few comments that previously referred to recovery procs,
and reverted a few other semantically unimportant changes vs. CVS
HEAD.

I am not sure why we have a single GUC to size both the number of
PGPROC structures we allow and the size of UnobservedXids.  A
read-only slave might only need to allow a few connections for
reporting purposes, while the master needs to allow many.

Revised patch updated and pushed to my git repo.

...Robert

Attachment

pgsql-hackers by date:

Previous
From: Brendan Jurd
Date:
Subject: Re: WIP: generalized index constraints
Next
From: Greg Stark
Date:
Subject: Re: WIP: generalized index constraints