Do you mean that the optional message is taken from the status argument and printed to the log? This may be OK only if a warning is returned (and log_errors is enabled in the config). If error is returned, this would be a critical "no-go" condition (as for any other errors).

So I have no problems adding a status and making the method returning bool, so that it would behave similar to startTransaction() -- i.e. false result without error in the status means silently disabled replication for this attachment. If warning is present in the status, then it will be logged (if configured).

Also, if we agree on the rules above, then perhaps this method should better be renamed to something like initialize().

I have no problems adding a status and making the method returning bool, so that it would behave similar to startTransaction() -- i.e. false result without error in the status means silently disabled replication for this attachment. If warning is present in the status, then it will be logged (if configured).

This is exactly what I had on mind.

Also, if we agree on the rules above, then perhaps this method should better be renamed to something like initialize().

Best of all would be add the attachment to parameters of plugin's factory but whole current plugin architecture is against it.