On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat <adrien.nay...@dalibo.com> wrote: > As Julien said, there is nothing to notice that error comes from > recovery.conf. > My fear would be that an user encounters an error like this. Il will be > difficult to link to the recovery.conf.
Thinking a bit wider than that, we may want to know such context for normal GUC parameters as well, and that's not the case now. Perhaps there is actually a reason why that's not done for GUCs, but it seems that it would be useful there as well. That would give another reason to move all that under the GUC umbrella. > For the others settings (xid, timeline,name) there is an explicit > message that notice error is in recovery.conf. > > I see it is not the case for recovery_target_time. Yes, in this case the parameter value is parsed using an datatype _in function call. And the error message depends on that.. > Should we modify only the documentation or should we try to find a > solution to point the origin of error? The patch as proposed is complicated enough I think, and it would be good to keep things simple if we can. So having something in the docs looks fine to me, and that's actually the reference to pg_lsn used to parse the parameter value. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
