On Tue, Jan 5, 2016 at 10:24 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Jan 5, 2016 at 7:49 PM, Haribabu Kommi <kommi.harib...@gmail.com> > wrote: >> On Sat, Dec 19, 2015 at 12:54 AM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >>> On Fri, Dec 18, 2015 at 8:39 AM, Robert Haas <robertmh...@gmail.com> wrote: >>>> On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier >>>> <michael.paqu...@gmail.com> wrote: >>>>> On Tue, Dec 15, 2015 at 5:27 AM, Gurjeet Singh wrote: >>>>>> The function, maybe. But emitting an all-nulls row from a view seems >>>>>> counter-intuitive, at least when looking at it in context of relational >>>>>> database. >>>>> >>>>> OK, noted. Any other opinions? >>>> >>>> I wouldn't bother with the view. If we're going to do it, I'd say >>>> just provide the function and let people SELECT * from it if they want >>>> to. >>> >>> OK, I took some time to write a patch for that as attached, added in >>> the next CF here: >>> https://commitfest.postgresql.org/8/447/ >>> I am fine switching to an SRF depending on other opinions of people >>> here, it just seems like an overkill knowing the uniqueness of the WAL >>> sender in a server. >>> >>> I have finished with a function and a system view, this came up more >>> in line with the existing things like pg_stat_archiver, and this makes >>> as well the documentation clearer, at least that was my feeling when >>> hacking that. >> >> I also feel showing NULL values may not be good, when there is >> no walreceiver. Instead of SRF function to avoid showing NULL vallues >> how about adding "WHERE s.pid IS NOT NULL" to the system view. >> pid value cannot be NULL, until unless there is no walreceiver. > > Yeah, I would not mind switching it to that. A couple of other stat > catalog views do it as well.
Following are my observations on the latest patch. + If no WAL receiver is present on the server queried, + a single tuple filled with <literal>NULL</> values is returned instead. + </para> The above documentation change is not required if we change the system view. + s.received_up_to_lsn, The column name can be changed as "received_lsn" similar to "received_tli". up_to may not be required. + XLogRecPtr received_up_lsn; + TimeLineID received_up_tli; same as like above comment. + /* lock? */ I find out that walrcv data is updated only under mutex. it is better to take that mutex to provide a consistent snapshot data to user. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers