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 S
Willy-Bas Loos 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
planning is to stop whe
Kevin Grittner writes:
> Willy-Bas Loos 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.
Yeah
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 u
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 mi
=?UTF-8?B?VG9yc3RlbiBGw7ZydHNjaA==?= 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 ones. I'd think it should
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 l
On Sun, Sep 14, 2014 at 3:23 PM, Kevin Grittner 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 don't mean
On September 14, 2014 5:01:54 PM EDT, cowwoc 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 if you ran a tem
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 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]
>> > wrote:
>> >Hi,
>> >
>> >I'd like to propose the ability to create temporary schemas.
>> >
>> >This would
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 runn
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 behav
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 suggest
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 s
If I set a custom GUC variable to a boolean value, such as:
SET myapp.audit = 'on';
is there a way to test it for truthiness in the same way the standard
built-in variables are? IOW, the docs say a boolean can be written as:
Boolean values can be written as on, off, true, false, yes, no, 1, 0
On Sun, Sep 14, 2014 at 11:17 PM, Abelard Hoffman
wrote:
> If I set a custom GUC variable to a boolean value, such as:
>
> SET myapp.audit = 'on';
>
> is there a way to test it for truthiness in the same way the standard
> built-in variables are? IOW, the docs say a boolean can be written as:
>
18 matches
Mail list logo
