| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Function and view to retrieve WAL receiver status |
| Date: | 2015-12-18 13:54:09 |
| Message-ID: | CAB7nPqQboUByzBfKhxOf4S-d=uVYemZ+d3N6qkjcS6F3sgRXQw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 18, 2015 at 8:39 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)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.
Regards,
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-system-view-and-function-to-report-WAL-receiver-.patch | binary/octet-stream | 14.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2015-12-18 14:19:33 | Re: Patch: fix lock contention for HASHHDR.mutex |
| Previous Message | Teodor Sigaev | 2015-12-18 13:46:41 | Re: Patch: fix lock contention for HASHHDR.mutex |