Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > While we're talking about pgstats... There was some talk a while back
> > about the whole bufferer/collector combination perhaps being unnecessary
> > as well, and that it might be a good idea to simplify it down to just a
> > col
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> While we're talking about pgstats... There was some talk a while back
> about the whole bufferer/collector combination perhaps being unnecessary
> as well, and that it might be a good idea to simplify it down to just a
> collector. I'm not 100% sure
Agent M <[EMAIL PROTECTED]> writes:
> Please correct me if I am wrong, but using UDP logging on the same
> computer is a red herring. Any non-blocking I/O would do, no? If the
> buffer is full, then the non-blocking I/O send function will fail and
> the message is skipped.
Uh, not entirely. We
The general idea would be to still use UDP backend->stats but get rid
of
the pipe part (emulated by standard tcp sockets on win32), so we'd
still
have the "lose packets instead of blocking when falling behind".
Right.
Please correct me if I am wrong, but using UDP logging on the same
comput
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> While we're talking about pgstats... There was some talk a while back
> about the whole bufferer/collector combination perhaps being unnecessary
> as well, and that it might be a good idea to simplify it down to just a
> collector. I'm not 100% sure
While we're talking about pgstats... There was some talk a while back
about the whole bufferer/collector combination perhaps being unnecessary
as well, and that it might be a good idea to simplify it down to just a
collector. I'm not 100% sure what the end result of that discussion was,
thouhg, an
