On 2014-02-02 00:04:41 +0900, Michael Paquier wrote:
> On Fri, Dec 13, 2013 at 2:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Andres Freund <andres@2ndquadrant.com> writes:
> >> On 2013-12-12 11:55:51 -0500, Tom Lane wrote:
> >>> I'm not, however, terribly thrilled with the suggestions to add implicit
> >>> casts associated with this type. Implicit casts are generally dangerous.
> >
> >> It's a tradeof. Currently we have the following functions returning LSNs
> >> as text:
> >> * pg_current_xlog_location
> >> * pg_current_xlog_insert_location
> >> * pg_last_xlog_receive_location
> >> * pg_last_xlog_replay_location
> >> one view containing LSNs
> >> * pg_stat_replication
> >> and the following functions accepting LSNs as textual paramters:
> >> * pg_xlog_location_diff
> >> * pg_xlogfile_name
> >
> >> The question is how do we deal with backward compatibility when
> >> introducing a LSN type? There might be some broken code around
> >> monitoring if we simply replace the type without implicit casts.
> >
> > Given the limited usage, how bad would it really be if we simply
> > made all those take/return the LSN type? As long as the type's
> > I/O representation looks like the old text format, I suspect
> > most queries wouldn't notice.
I've asked around inside 2ndq and we could find one single problematic
query, so it's really not too bad.
> Are there some plans to awaken this patch (including changing the
> output of the functions of xlogfuncs.c)? This would be useful for the
> differential backup features I am looking at these days. I imagine
> that it is too late for 9.4 though...
I think we should definitely go ahead with the patch per-se, we just
added another system view with lsns in it... I don't have a too strong
opinion whether to do it in 9.4 or 9.5. It seems fairly low impact to
me, and it's an old patch, but I personally don't have the tuits to
refresh the patch right now.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
