should we add a XLogRecPtr/LSN SQL type?

On Wed, Dec 11, 2013 at 7:41 AM, Andres Freund <andres@2ndquadrant.com> wrote:

There's already a couple of SQL function dealing with XLogRecPtrs and
the logical replication work will add a couple of more. Currently each
of those funtions taking/returning an LSN does sprintf/scanf to
print/parse the strings. Which both is awkward and potentially
noticeable performancewise.

It seems relatively simple to add a proper type, with implicit casts
from text, instead?

I'm pretty sure that this was discussed last year, and I voted for it
-- except for the implicit casts part, perhaps -- but more people
voted against it, so it died. I still think that was a mistake, but I
just work here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 11-12-2013 09:41, Andres Freund wrote:

There's already a couple of SQL function dealing with XLogRecPtrs and
the logical replication work will add a couple of more. Currently each
of those funtions taking/returning an LSN does sprintf/scanf to
print/parse the strings. Which both is awkward and potentially
noticeable performancewise.

While discussing pg_xlog_location_diff function, Robert posted a lsn
datatype [1]/messages/by-id/CA+TgmoZRMNN0eVEsD-kxB9e-MvdmwoTi6guuJUvQP_8q2C5Cyg@mail.gmail.com. At that time we wouldn't go that far (a new datatype) to
cover only one function. If your proposal is just validation, I think
generic validation functions is the way to follow. However, if you are
thinking in adding operators, the lsn datatype should be implemented.

It seems relatively simple to add a proper type, with implicit casts
from text, instead?

Do you want to change the function signatures too?

[1]: /messages/by-id/CA+TgmoZRMNN0eVEsD-kxB9e-MvdmwoTi6guuJUvQP_8q2C5Cyg@mail.gmail.com
/messages/by-id/CA+TgmoZRMNN0eVEsD-kxB9e-MvdmwoTi6guuJUvQP_8q2C5Cyg@mail.gmail.com

--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Bonus points if you implement a (explicit) cast to and from timestamptz :)

--
greg
On 11 Dec 2013 12:41, "Andres Freund" <andres@2ndquadrant.com> wrote:

On 2013-12-11 08:13:18 -0500, Robert Haas wrote:

On Wed, Dec 11, 2013 at 7:41 AM, Andres Freund <andres@2ndquadrant.com> wrote:

There's already a couple of SQL function dealing with XLogRecPtrs and
the logical replication work will add a couple of more. Currently each
of those funtions taking/returning an LSN does sprintf/scanf to
print/parse the strings. Which both is awkward and potentially
noticeable performancewise.

It seems relatively simple to add a proper type, with implicit casts
from text, instead?

I'm pretty sure that this was discussed last year, and I voted for it
but more people
voted against it, so it died. I still think that was a mistake, but I
just work here.

Ah. I missed or forgot that discussion. The primary argument seemed to
be that we were are only talking about a single function using it. I
don't think that really was true back then, but there definitely are
some more uses coming up. E.g. the changeset extraction SRF will return
the LSN of every extracted change...
I don't really buy the argument that it can wholl be replaced by
representing LSNs as numeric - those look significantly different enough
that that doesn't seem to make much sense to me. Also, they are a
pass-by-reference type...

-- except for the implicit casts part, perhaps --

I'd like to convert some existing functions to use the new type, and
without added casts that seems too likely to break existing usages. If
we just consistently use the new type everywhere, I can't see the usual
troubles with the added casts.

On 2013-12-11 10:13:51 -0300, Euler Taveira wrote:

On 11-12-2013 09:41, Andres Freund wrote:
While discussing pg_xlog_location_diff function, Robert posted a lsn
datatype [1]. At that time we wouldn't go that far (a new datatype) to
cover only one function. If your proposal is just validation, I think
generic validation functions is the way to follow. However, if you are
thinking in adding operators, the lsn datatype should be implemented.

I am mostly thinking of returning many such datums - representing them
as text is just pointless overhead. But even if it just were validation
- why sprinkle validation over dozens of places if we actually have a
typesystem to handle that kind of thing?

It seems relatively simple to add a proper type, with implicit casts
from text, instead?

Do you want to change the function signatures too?

Yes.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 12 December 2013 12:27, Andres Freund <andres@2ndquadrant.com> wrote:

On 2013-12-11 08:13:18 -0500, Robert Haas wrote:

On Wed, Dec 11, 2013 at 7:41 AM, Andres Freund <andres@2ndquadrant.com> wrote:

There's already a couple of SQL function dealing with XLogRecPtrs and
the logical replication work will add a couple of more. Currently each
of those funtions taking/returning an LSN does sprintf/scanf to
print/parse the strings. Which both is awkward and potentially
noticeable performancewise.

It seems relatively simple to add a proper type, with implicit casts
from text, instead?

I'm pretty sure that this was discussed last year, and I voted for it
but more people
voted against it, so it died. I still think that was a mistake, but I
just work here.

Ah. I missed or forgot that discussion.

Hmm, don't recall that. Just in case I opposed it, its a good idea now.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Dec 12, 2013 at 8:20 AM, Simon Riggs <simon@2ndquadrant.com> wrote:

On 12 December 2013 12:27, Andres Freund <andres@2ndquadrant.com> wrote:

On 2013-12-11 08:13:18 -0500, Robert Haas wrote:

On Wed, Dec 11, 2013 at 7:41 AM, Andres Freund <andres@2ndquadrant.com> wrote:

There's already a couple of SQL function dealing with XLogRecPtrs and
the logical replication work will add a couple of more. Currently each
of those funtions taking/returning an LSN does sprintf/scanf to
print/parse the strings. Which both is awkward and potentially
noticeable performancewise.

It seems relatively simple to add a proper type, with implicit casts
from text, instead?

I'm pretty sure that this was discussed last year, and I voted for it
but more people
voted against it, so it died. I still think that was a mistake, but I
just work here.

Ah. I missed or forgot that discussion.

Hmm, don't recall that. Just in case I opposed it, its a good idea now.

I am happy to have my old patch resurrected - could become a trend.
But someone should probably go back and check who objected and for
what reasons.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas escribi�:

I am happy to have my old patch resurrected - could become a trend.
But someone should probably go back and check who objected and for
what reasons.

Here it is FWIW:

/messages/by-id/CA+TgmoZRMNN0eVEsD-kxB9e-MvdmwoTi6guuJUvQP_8q2C5Cyg@mail.gmail.com

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Robert Haas escribi�:

I am happy to have my old patch resurrected - could become a trend.
But someone should probably go back and check who objected and for
what reasons.

Here it is FWIW:
/messages/by-id/CA+TgmoZRMNN0eVEsD-kxB9e-MvdmwoTi6guuJUvQP_8q2C5Cyg@mail.gmail.com

AFAICS the objections were "why bother with a datatype for just one
function". If we've now got multiple use-cases, that loses its force.

I'm not, however, terribly thrilled with the suggestions to add implicit
casts associated with this type. Implicit casts are generally dangerous.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi,

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. But
just leaving all those as-is seems quite unattractive.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

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...
Regards,
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Feb 2, 2014 at 12:07 AM, Andres Freund <andres@2ndquadrant.com> wrote:

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.

Please find attached a patch implementing lsn as a datatype, based on
the one Robert wrote a couple of years ago. Since XLogRecPtr has been
changed to a simple uint64, this *refresh* has needed some work. In
order to have this data type plugged in more natively with other xlog
system functions, I have added as well PG_RETURN_LSN and PG_GETARG_LSN
to facilitate the interface, making easier code management if
XLogRecPtr or LSN format are changed in the future.

Patch contains regression tests as well as a bit of documentation.
Perhaps this is too late for 9.4, so if there are no objections I'll
simply add this patch to the next commit fest in June for 9.5. Having
the system functions use this data type (pg_start_backup, pg_xlog_*,
create_rep_slot, etc.) does not look to be that difficult as all the
functions in xlogfuncs.c actually use XLogRecPtr before changing it to
text, so it would actually simplify the code. I think I'll simply code
it as I just looking at it now...
Regards,
--
Michael

Michael Paquier <michael.paquier@gmail.com> writes:

Please find attached a patch implementing lsn as a datatype, based on
the one Robert wrote a couple of years ago.

Patch contains regression tests as well as a bit of documentation.
Perhaps this is too late for 9.4, so if there are no objections I'll
simply add this patch to the next commit fest in June for 9.5.

I may have lost count, but aren't a bunch of the affected functions new
in 9.4? If so, there's a good argument to be made that we should get
this in now, rather than waiting and having an API change for those
functions in 9.5.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Feb 4, 2014 at 10:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

Please find attached a patch implementing lsn as a datatype, based on
the one Robert wrote a couple of years ago.

Patch contains regression tests as well as a bit of documentation.
Perhaps this is too late for 9.4, so if there are no objections I'll
simply add this patch to the next commit fest in June for 9.5.

I may have lost count, but aren't a bunch of the affected functions new
in 9.4? If so, there's a good argument to be made that we should get
this in now, rather than waiting and having an API change for those
functions in 9.5.

Cool... I have created a second patch that updates all the system
functions to use the new lsn datatype introduced in the 1st patch
(pg_start|stop_backup, replication_slot stuff, xlog diff things, etc.)
and it is attached. This cleans up quite a bit of code in xlogfuncs.c
because we do not need anymore the LSN <-> cstring transformations!
I am also attaching a v2 of the first patch, I noticed that lsn_in
introduced in the first patch was using some error messages not
consistent with the ones of validate_xlog_location:xlogfuncs.c. Note
as well that validate_xlog_location is removed in the 2nd patch where
all the system functions are swicthed to the new datatype.
Regards,
--
Michael

Hi,

On 2014-02-04 10:23:14 +0900, Michael Paquier wrote:

On Tue, Feb 4, 2014 at 10:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

Please find attached a patch implementing lsn as a datatype, based on
the one Robert wrote a couple of years ago.

Patch contains regression tests as well as a bit of documentation.
Perhaps this is too late for 9.4, so if there are no objections I'll
simply add this patch to the next commit fest in June for 9.5.

I may have lost count, but aren't a bunch of the affected functions new
in 9.4? If so, there's a good argument to be made that we should get
this in now, rather than waiting and having an API change for those
functions in 9.5.

Yes, that sounds sensible.

+ /*----------------------------------------------------------
+  *	Relational operators for LSNs
+  *---------------------------------------------------------*/

Isn't it just operators? They aren't really relational...

*** 302,307 **** extern struct varlena *pg_detoast_datum_packed(struct varlena * datum);
--- 303,309 ----
#define PG_RETURN_CHAR(x)	 return CharGetDatum(x)
#define PG_RETURN_BOOL(x)	 return BoolGetDatum(x)
#define PG_RETURN_OID(x)	 return ObjectIdGetDatum(x)
+ #define PG_RETURN_LSN(x)	 return LogSeqNumGetDatum(x)
#define PG_RETURN_POINTER(x) return PointerGetDatum(x)
#define PG_RETURN_CSTRING(x) return CStringGetDatum(x)
#define PG_RETURN_NAME(x)	 return NameGetDatum(x)
*** a/src/include/postgres.h
--- b/src/include/postgres.h
***************
*** 484,489 **** typedef Datum *DatumPtr;
--- 484,503 ----
#define ObjectIdGetDatum(X) ((Datum) SET_4_BYTES(X))

/*
+  * DatumGetLogSeqNum
+  *		Returns log sequence number of a datum.
+  */
+ 
+ #define DatumGetLogSeqNum(X) ((XLogRecPtr) GET_8_BYTES(X))

I am not a fan of LogSegNum. I think at this point fewer people
understand that than LSN. There's also no reason to invent a third term
for LSNs. We'd have LSN, XLogRecPtr, and LogSeqNum.

*** a/src/backend/replication/slotfuncs.c
--- b/src/backend/replication/slotfuncs.c
***************
*** 141,148 **** pg_get_replication_slots(PG_FUNCTION_ARGS)
bool		active;
Oid			database;
const char *slot_name;
- 
- 		char		restart_lsn_s[MAXFNAMELEN];
int			i;

SpinLockAcquire(&slot->mutex);
--- 141,146 ----

Unrelated change.

Looks reasonable on a first look. Thanks!

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Feb 4, 2014 at 6:15 PM, Andres Freund <andres@2ndquadrant.com> wrote:

+ /*----------------------------------------------------------
+  *  Relational operators for LSNs
+  *---------------------------------------------------------*/

Isn't it just operators? They aren't really relational...

Operators for LSNs?

*** 302,307 **** extern struct varlena *pg_detoast_datum_packed(struct varlena * datum);
--- 303,309 ----
#define PG_RETURN_CHAR(x)    return CharGetDatum(x)
#define PG_RETURN_BOOL(x)    return BoolGetDatum(x)
#define PG_RETURN_OID(x)     return ObjectIdGetDatum(x)
+ #define PG_RETURN_LSN(x)     return LogSeqNumGetDatum(x)
#define PG_RETURN_POINTER(x) return PointerGetDatum(x)
#define PG_RETURN_CSTRING(x) return CStringGetDatum(x)
#define PG_RETURN_NAME(x)    return NameGetDatum(x)
*** a/src/include/postgres.h
--- b/src/include/postgres.h
***************
*** 484,489 **** typedef Datum *DatumPtr;
--- 484,503 ----
#define ObjectIdGetDatum(X) ((Datum) SET_4_BYTES(X))

/*
+  * DatumGetLogSeqNum
+  *          Returns log sequence number of a datum.
+  */
+
+ #define DatumGetLogSeqNum(X) ((XLogRecPtr) GET_8_BYTES(X))

I am not a fan of LogSegNum. I think at this point fewer people
understand that than LSN. There's also no reason to invent a third term
for LSNs. We'd have LSN, XLogRecPtr, and LogSeqNum.

So let's go with DatumGetLSN and LSNGetDatum instead...

*** a/src/backend/replication/slotfuncs.c
--- b/src/backend/replication/slotfuncs.c
***************
*** 141,148 **** pg_get_replication_slots(PG_FUNCTION_ARGS)
bool            active;
Oid                     database;
const char *slot_name;
-
-             char            restart_lsn_s[MAXFNAMELEN];
int                     i;

SpinLockAcquire(&slot->mutex);
--- 141,146 ----

Unrelated change.

Funnily, the patch attached in my previous mail did not include all
the diffs, it is an error with filterdiff that I use to generate
context diff patches... My original branch includes the following
diffs as well in slotfuncs.c for the second patch:
diff --git a/src/backend/replication/slotfuncs.c
b/src/backend/replication/slotfuncs.c
index 98a860e..68ecdcd 100644
--- a/src/backend/replication/slotfuncs.c
+++ b/src/backend/replication/slotfuncs.c
@@ -141,8 +141,6 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)
                bool            active;
                Oid                     database;
                const char *slot_name;
-
-               char            restart_lsn_s[MAXFNAMELEN];
                int                     i;

SpinLockAcquire(&slot->mutex);
@@ -164,9 +162,6 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)

memset(nulls, 0, sizeof(nulls));

-               snprintf(restart_lsn_s, sizeof(restart_lsn_s), "%X/%X",
-                                (uint32) (restart_lsn >> 32),
(uint32) restart_lsn);
-
                i = 0;
                values[i++] = CStringGetTextDatum(slot_name);
                if (database == InvalidOid)
@@ -180,7 +175,7 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)
                else
                        nulls[i++] = true;
                if (restart_lsn != InvalidTransactionId)
-                       values[i++] = CStringGetTextDatum(restart_lsn_s);
+                       values[i++] = restart_lsn;
                else
                        nulls[i++] = true;

Anything else?
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2014-02-04 19:17:51 +0900, Michael Paquier wrote:

On Tue, Feb 4, 2014 at 6:15 PM, Andres Freund <andres@2ndquadrant.com> wrote:

+ /*----------------------------------------------------------
+  *  Relational operators for LSNs
+  *---------------------------------------------------------*/

Isn't it just operators? They aren't really relational...

Operators for LSNs?

Fine with me.

+ #define DatumGetLogSeqNum(X) ((XLogRecPtr) GET_8_BYTES(X))

I am not a fan of LogSegNum. I think at this point fewer people
understand that than LSN. There's also no reason to invent a third term
for LSNs. We'd have LSN, XLogRecPtr, and LogSeqNum.

So let's go with DatumGetLSN and LSNGetDatum instead...

Sup.

*** a/src/backend/replication/slotfuncs.c
--- b/src/backend/replication/slotfuncs.c
***************
*** 141,148 **** pg_get_replication_slots(PG_FUNCTION_ARGS)
bool            active;
Oid                     database;
const char *slot_name;
-
-             char            restart_lsn_s[MAXFNAMELEN];
int                     i;

SpinLockAcquire(&slot->mutex);
--- 141,146 ----

Unrelated change.

Funnily, the patch attached in my previous mail did not include all
the diffs, it is an error with filterdiff that I use to generate
context diff patches... My original branch includes the following

Ah, then it makes more sense.

diffs as well in slotfuncs.c for the second patch:
diff --git a/src/backend/replication/slotfuncs.c
b/src/backend/replication/slotfuncs.c
index 98a860e..68ecdcd 100644
--- a/src/backend/replication/slotfuncs.c
+++ b/src/backend/replication/slotfuncs.c
@@ -141,8 +141,6 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)
bool            active;
Oid                     database;
const char *slot_name;
-
-               char            restart_lsn_s[MAXFNAMELEN];
int                     i;

SpinLockAcquire(&slot->mutex);
@@ -164,9 +162,6 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)

memset(nulls, 0, sizeof(nulls));

-               snprintf(restart_lsn_s, sizeof(restart_lsn_s), "%X/%X",
-                                (uint32) (restart_lsn >> 32),
(uint32) restart_lsn);
-
i = 0;
values[i++] = CStringGetTextDatum(slot_name);
if (database == InvalidOid)
@@ -180,7 +175,7 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)
else
nulls[i++] = true;
if (restart_lsn != InvalidTransactionId)
-                       values[i++] = CStringGetTextDatum(restart_lsn_s);
+                       values[i++] = restart_lsn;
else
nulls[i++] = true;

Isn't that missing a LSNGetDatum()? Also, isn't it lacking the
corresponding pg_proc change?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Feb 4, 2014 at 7:22 PM, Andres Freund <andres@2ndquadrant.com> wrote:

On 2014-02-04 19:17:51 +0900, Michael Paquier wrote:

@@ -180,7 +175,7 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)
else
nulls[i++] = true;
if (restart_lsn != InvalidTransactionId)
-                       values[i++] = CStringGetTextDatum(restart_lsn_s);
+                       values[i++] = restart_lsn;
else
nulls[i++] = true;

Isn't that missing a LSNGetDatum()?

Oops yes. Will fix.

Also, isn't it lacking the corresponding pg_proc change?

restart_lsn is the 6th argument of pg_get_replication_slots, and the
list of arguments of this function is already changed like that in my
patch:
{25,25,26,16,28,25} => {25,25,26,16,28,3220}
Regards,
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers