Jeff Janes writes:
> On Tue, Jun 28, 2016 at 6:24 PM, wrote:
>> PostgreSQL 9.3.4, compiled by Visual C++ build 1600, 64-bit
> The current minor version of that branch is 9.3.13, so you are 9 bug
> fix releases behind.
Definitely a fair complaint.
> I don't know if this matters, because I see
On Tue, Jun 28, 2016 at 6:24 PM, wrote:
>
>
> PostgreSQL version:
> PostgreSQL 9.3.4, compiled by Visual C++ build 1600, 64-bit
The current minor version of that branch is 9.3.13, so you are 9 bug
fix releases behind.
I don't know if this matters, because I see that my first guess of
your probl
devel.brai...@xoxy.net writes:
> As you can see from the logs I posted, it appears the execution plan was
> cached (LOG: duration: 122006.000 ms bind cached-1453392550: select).
> Maybe those aren't processed by auto_explain?
In that, "cached-1453392550" is a statement name given by the clie
On Wed, Jun 29, 2016 at 3:00 AM, Niels Kristian Schjødt
wrote:
> About a day ago, there seems to have been some trouble in the network of my
> database (postgresql 9.3).
>
> I’m running my db with a streaming replication setup with wall shipping.
>
> I sync wal logs to a mounted networkdrive using
On 29 June 2016 at 16:32, Igor Neyman wrote:
> Did you try AUTO_EXPLAIN extension
> (https://www.postgresql.org/docs/9.3/static/auto-explain.html) for
> diagnostic purposes?
> With auto_explain.loganalize = true it will log automatically EXPLAIN
> ANALYZE output, rather than just EXPLAIN output.
On 29 June 2016 at 14:45, Kevin Grittner wrote:
> Please monitor for the start of such an event and capture the full
> contents of pg_stat_activity and pg_locks during that 2 minute
> window.
I had already looked at that manually and found nothing unusual. To be more
thorough, I now had a batch f
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of
devel.brai...@xoxy.net
Sent: Tuesday, June 28, 2016 9:24 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Random slow queries
Hi,
I have a weird slow q
On Tue, Jun 28, 2016 at 8:24 PM, wrote:
> The problem:
> Most queries execute fast, however sometimes queries on the job
> table (which contains the job queue) take exactly 122 seconds
> (+ 0-50ms) to execute for no clear reason.
> Have I missed something obvious?
Please monitor for the start
About a day ago, there seems to have been some trouble in the network of my
database (postgresql 9.3).
I’m running my db with a streaming replication setup with wall shipping.
I sync wal logs to a mounted networkdrive using archive_command = 'rsync -a %p
/mnt/wal_drive/wals/%f http://www.hive
