Re: check_recovery_target_lsn() does a PG_CATCH without a throw
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2019-06-23T17:21:02Z
Lists: pgsql-hackers
Attachments
- v2-0001-Remove-explicit-error-handling-for-obsolete-date-.patch (text/plain) patch v2-0001
- v2-0002-Don-t-call-data-type-input-functions-in-GUC-check.patch (text/plain) patch v2-0002
On 2019-06-20 18:05, Andres Freund wrote: > Hi, > > On 2019-06-20 15:42:14 +0200, Peter Eisentraut wrote: >> On 2019-06-12 13:16, Peter Eisentraut wrote: >>> I haven't figured out the time zone issue yet, but I guess the solution >>> might involve moving some of the code from check_recovery_target_time() >>> to assign_recovery_target_time(). >> >> I think that won't work either. What we need to do is postpone the >> interpretation of the timestamp string until after all the GUC >> processing is done. So check_recovery_target_time() would just do some >> basic parsing checks, but stores the string. Then when we need the >> recovery_target_time_value we do the final parsing. Then we can be sure >> that the time zone is all set. > > That sounds right to me. Updated patch for that. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Don't call data type input functions in GUC check hooks
- 21f428ebde39 12.0 landed