Hi,
I noticed a strange behaviour regarding pg_stat_replication in 9.3. If
called from psql using the \watch command, I see all my replicas. From
time to time one of them drops out and reconnects in a short period of
time, typically ~30 sec.
If I use the same select in plpgsql like:
FOR r in
Willy-Bas Loos willy...@gmail.com wrote:
I can't understand what is confusing the planner.
Well, it doesn't do exhaustive proofs of whether two queries are
equivalent. If it did, it would still not have come up with a plan
like your second one, because it is not equivalent. The trick in
Kevin Grittner kgri...@ymail.com writes:
Willy-Bas Loos willy...@gmail.com wrote:
I can't understand what is confusing the planner.
Well, it doesn't do exhaustive proofs of whether two queries are
equivalent. If it did, it would still not have come up with a plan
like your second one,
On 09/14/2014 07:03 AM, Torsten Förtsch wrote:
Hi,
I noticed a strange behaviour regarding pg_stat_replication in 9.3. If
called from psql using the \watch command, I see all my replicas. From
time to time one of them drops out and reconnects in a short period of
time, typically ~30 sec.
If I
On 14/09/14 16:24, Andy Colson wrote:
I wonder if its a transaction thing? Maybe \watch is using a
transaction for each (or isn't using transactions at all), whereas the
plpgsql is one long transaction?
Also if one of your replicas is far away, it doesn't really surprise me
that it might
=?UTF-8?B?VG9yc3RlbiBGw7ZydHNjaA==?= torsten.foert...@gmx.net writes:
The replicas are far away, intercontinental far. I am not complaining
that the replica looses the connection. What makes me wonder is that
within a transaction, pg_stat_replication can forget rows but cannot
acquire new
On 14/09/14 18:55, Tom Lane wrote:
Are you watching the state in a loop inside a single plpgsql function?
If so, I wonder whether the problem is that the plpgsql function's
snapshot isn't changing. From memory, marking the function VOLATILE
would help if that's the issue.
The function is
Hi,
I'd like to propose the ability to create temporary schemas.
Unlike temporary tables, this feature would enable developers to create a
temporary schema once and execute CREATE TABLE statements without the
TEMPORARY parameter.
This would facilitate running unit tests, where developers would
On Sun, Sep 14, 2014 at 3:23 PM, Kevin Grittner kgri...@ymail.com wrote:
The fact that the
first query was complex enough that *you* weren't able to
accurately optimize it better before posting is pretty good
evidence that it's moving into the realm of expensive to
optimize.
Touche
BTW i
On September 14, 2014 5:01:54 PM EDT, cowwoc cow...@bbs.darktech.org wrote:
Hi,
I'd like to propose the ability to create temporary schemas.
This would facilitate running unit tests, where developers would like
to run
the same creation script for unit tests and production code but do not
What
Hi Nick,
I don't think this would help for three reasons:
1. I'm already planning to run unit tests against a separate (but
identical) database than production, so there's no danger of wiping
out the production database.
2. I need to create a new temporary schema per test, and run 4-10
On September 14, 2014 6:01:15 PM EDT, cowwoc cow...@bbs.darktech.org wrote:
On 14/09/2014 5:52 PM, Nick Guenther [via PostgreSQL] wrote:
On September 14, 2014 5:01:54 PM EDT, cowwoc [hidden email]
/user/SendEmail.jtp?type=nodenode=5819003i=0 wrote:
Hi,
I'd like to propose the ability
On 09/14/2014 02:01 PM, cowwoc wrote:
Hi,
I'd like to propose the ability to create temporary schemas.
Unlike temporary tables, this feature would enable developers to create a
temporary schema once and execute CREATE TABLE statements without the
TEMPORARY parameter.
This would facilitate
Hi Adrian,
Replies below.
On 14/09/2014 8:34 PM, Adrian Klaver wrote:
On 09/14/2014 02:01 PM, cowwoc wrote:
See http://dba.stackexchange.com/q/76494/4719 for a related discussion.
So from the above link and the discussion here so far I gather you want:
1) A CREATE TEMPORARY SCHEMA that
Hi,
The 1.0.2 release of the PgToolkit is on the way. Some significant
improvements of the tables and indexes bloat reducing tool have been
made.
Testers are very welcome. Use this link to get the testing version
https://github.com/grayhemp/pgtoolkit/branches/v1.0testing
Report bugs and
Hi,
Out of curiosity, why is Postgresql's Java support so poor? I am
specifically looking for the ability to write triggers in Java.
I took a look at the PL/Java project and it looked both incomplete and dead,
yet other languages like Javascript are taking off. I would have expected to
see very
16 matches
Mail list logo
