On Tue, Jan 5, 2016 at 10:24 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Jan 5, 2016 at 7:49 PM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
>> On Sat, Dec 19, 2015 at 12:54 AM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> On Fri, Dec 18, 2015 at 8:39 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>> On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier
>>>> <michael.paquier@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
