Re: [HACKERS] expose confirmed_flush for replication slots

2015-08-10 Thread Andres Freund
On 2015-07-08 15:01:15 +0300, Marko Tiikkaja wrote: + if (confirmed_flush_lsn != InvalidTransactionId) + values[i++] = LSNGetDatum(confirmed_flush_lsn); + else + nulls[i++] = true; + Hm. That comparison is using the wrong

Re: [HACKERS] expose confirmed_flush for replication slots

2015-08-10 Thread Marko Tiikkaja
On 8/10/15 1:29 PM, Andres Freund wrote: On 2015-07-08 15:01:15 +0300, Marko Tiikkaja wrote: + if (confirmed_flush_lsn != InvalidTransactionId) + values[i++] = LSNGetDatum(confirmed_flush_lsn); + else + nulls[i++] = true; +

[HACKERS] expose confirmed_flush for replication slots

2015-07-08 Thread Marko Tiikkaja
Hi, I had some trouble today with a misbehaving logical replication client which had confirmed a flush of an LSN far into the future. Debugging it was a bit of a pain for a number of reasons, but I think the most important one was that confirmed_flush isn't exposed in

Re: [HACKERS] expose confirmed_flush for replication slots

2015-07-08 Thread Marko Tiikkaja
On 2015-07-08 14:57, I wrote: Adding this one to the next commit fest, but any feedback welcome in the meanwhile. Forgot to change PG_GET_REPLICATION_SLOTS_COLS; fixed in the attached patch. .m diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql index