| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Satyanarayana Narlapuram <Satyanarayana(dot)Narlapuram(at)microsoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Adding connection id in the startup message |
| Date: | 2017-06-21 19:15:17 |
| Message-ID: | CA+TgmobR6jA0mO3dNt1t_tEPL8cOeTGSbibzcz=_4D40pWWo-Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 15, 2017 at 9:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Can you give a concrete example where this would have
> helped above and beyond knowing, eg, the source and time of the connection
> attempt?
I can imagine that in really high-volume use cases (such as the OP
apparently has) the number of client connections might be so large
that identification by timestamp isn't useful, and the source IP will
be obscured after the first hop through a connection pooler or other
middleware. If you've got 100 connections per second coming in,
matching things up by timestamp across different machines is going to
be tough.
But I agree with your other concerns. I think the problem is real,
but I'm not sure that this is the best solution. On the other hand,
I'm also not entirely sure I understand the proposal yet.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-06-21 19:16:54 | pgsql: Restart logical replication launcher when killed |
| Previous Message | Robert Haas | 2017-06-21 19:07:10 | Re: Adding connection id in the startup message |