Re: [Patch] add new parameter to pg_replication_origin_session_setup

The new error message is not great:

postgres=# select pg_replication_origin_session_setup('myorigin', 12345678);
ERROR:  could not find replication state slot for replication origin 
with OID 1 which was acquired by 12345678

Firstly, replication origin is not an OID. Secondly, it's a little 
confusing because the "replication state slot" is in fact present. 
However, it's currently inactive, i.e. not "acquired" by the given PID.

I propose to change that to:

postgres=# select pg_replication_origin_session_setup('myorigin', 12345678);
ERROR:  replication origin with ID 1 is not active for PID 12345678

That's more in line with this neighboring message:

ERROR:  replication origin with ID 1 is already active for PID 701228


I also wonder if the error code is appropriate. That error uses 
ERRCODE_OBJECT_IN_USE, but if the problem is that the origin is 
currently *not* active, that seems backwards. I didn't change that in 
the attached patch, but it's something to think about.


The second patch rearranges the if-else statements to check those 
conditions. I found the current logic hard to follow, this makes them 
feel more natural, in my opinion at least. It has one user-visible 
effect: If you call the function with acquired_pid != 0 and the origin 
has no state slot, *and* there are no free slots, you previously got 
this error:

postgres=# select pg_replication_origin_session_setup('other', 123);
ERROR:  could not find free replication state slot for replication 
origin with ID 2
HINT:  Increase "max_active_replication_origins" and try again.

Now you get this:

postgres=# select pg_replication_origin_session_setup('other', 123);
ERROR:  cannot use PID 123 for inactive replication origin with ID 2

Both error messages are more or less appropriate in that situation, but 
I think the new behavior is slightly better. The fact that the origin is 
inactive feels like the bigger problem here.

- Heikki