On Fri, Nov 13, 2015 at 1:54 AM, Tom Lane wrote:
> I wrote:
>> After looking around, I suspect what actually happened in your test
>> was that we kept pumping pqReadData until it realized it was seeing EOF,
>> whereupon it did pqDropConnection(), and guess what that does:
>
>> /* Discard any
vacuumdb: don't prompt for passwords over and over
Having the script prompt for passwords over and over was a preexisting
problem when it processed multiple databases or when it processed
multiple analyze stages, but the parallel mode introduced in commit
a179232047 made it worse.
Fix the annoyan
vacuumdb: don't prompt for passwords over and over
Having the script prompt for passwords over and over was a preexisting
problem when it processed multiple databases or when it processed
multiple analyze stages, but the parallel mode introduced in commit
a179232047 made it worse.
Fix the annoyan
Move each SLRU's lwlocks to a separate tranche.
This makes it significantly easier to identify these lwlocks in
LWLOCK_STATS or Trace_lwlocks output. It's also arguably better
from a modularity standpoint, since lwlock.c no longer needs to
know anything about the LWLock needs of the higher-level
Tag refs/tags/REL9_5_BETA2 was created.
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Thu, Nov 12, 2015 at 11:54 AM, Tom Lane wrote:
> I wrote:
>> After looking around, I suspect what actually happened in your test
>> was that we kept pumping pqReadData until it realized it was seeing EOF,
>> whereupon it did pqDropConnection(), and guess what that does:
>
>> /* Discard an
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
In commit 210eb9b743c0645d I centralized libpq's logic for closing down
the backend communication socket, and made the new pqDropConnection
routine always reset the I/O buffers to empty. Many of the call sites
previously had n
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
In commit 210eb9b743c0645d I centralized libpq's logic for closing down
the backend communication socket, and made the new pqDropConnection
routine always reset the I/O buffers to empty. Many of the call sites
previously had n
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
In commit 210eb9b743c0645d I centralized libpq's logic for closing down
the backend communication socket, and made the new pqDropConnection
routine always reset the I/O buffers to empty. Many of the call sites
previously had n
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
In commit 210eb9b743c0645d I centralized libpq's logic for closing down
the backend communication socket, and made the new pqDropConnection
routine always reset the I/O buffers to empty. Many of the call sites
previously had n
I wrote:
> After looking around, I suspect what actually happened in your test
> was that we kept pumping pqReadData until it realized it was seeing EOF,
> whereupon it did pqDropConnection(), and guess what that does:
> /* Discard any unread/unsent data */
> conn->inStart = conn->inCu
Robert Haas writes:
> On Thu, Nov 12, 2015 at 9:29 AM, Tom Lane wrote:
>> Just for the record, this patch changes no behavior whatsoever.
> Actually, yes it does. I tested. Without the patch, the message sent
> by ac1d7945f866b1928c2554c0f80fd52d7f92 isn't received by psql.
> With the patc
On Thu, Nov 12, 2015 at 9:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> libpq: Notice errors a backend may have sent just before dying.
>> At least since the introduction of Hot Standby, the backend has
>> sometimes sent fatal errors even when no client query was in
>> progress, assuming that t
Robert Haas writes:
> libpq: Notice errors a backend may have sent just before dying.
> At least since the introduction of Hot Standby, the backend has
> sometimes sent fatal errors even when no client query was in
> progress, assuming that the client would receive it. However,
> pqHandleSendFail
Make idle backends exit if the postmaster dies.
Letting backends continue to run if the postmaster has exited prevents
PostgreSQL from being restarted, which in many environments is
catastrophic. Worse, if some other backend crashes, we no longer have
any protection against shared memory corrupti
libpq: Notice errors a backend may have sent just before dying.
At least since the introduction of Hot Standby, the backend has
sometimes sent fatal errors even when no client query was in
progress, assuming that the client would receive it. However,
pqHandleSendFailure was not in sync with this
Provide readfuncs support for custom scans.
Commit a0d9f6e434bb56f7e5441b7988f3982feead33b3 added this support for
all other plan node types; this fills in the gap.
Since TextOutCustomScan complicates this and is pretty well useless,
remove it.
KaiGai Kohei, with some modifications by me.
Branc
17 matches
Mail list logo
