Prev: gcc versus division-by-zero traps
Next: [HACKERS] integer input functions : interesting limit behaviour
From: Simon Riggs on 3 Sep 2009 14:22

We discussed earlier that HS should continue to work even if
max_connections was set differently on the primary and the standby. This
now gives a situation where snapshots can be allowed, then disallowed
for a while, then allowed again.

Complication is that this will cause some connections to fail since we
take a snapshot in postinit.c. (That is the part I just noticed in my
self-review). Some queries will also fail. Sometimes, not all the time.

This makes both behaviour and coding more complicated and my feeling is
that if we are aiming for simplicity in all areas we should remove
this.

Currently max_prepared_transactions needs to be set correctly in
recovery also, so this complex coding doesn't actually remove the need
to set some parameters correctly. Not many people change them from the
default in the first place, so I don't think its a big deal. And most
people use the same postgresql.conf on the standby anyway.

I propose we just accept that both max_connections and
max_prepared_transactions need to be set correctly for recovery to work.
This will make the state transitions more robust and it will avoid
spurious and hard to test error messages.

Any objections to me removing this slice of code from the patch?

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: gcc versus division-by-zero traps
Next: [HACKERS] integer input functions : interesting limit behaviour