On 7/25/19 4:01 PM, PegoraroF10 wrote:
Nope, no one message near those statements.
I haven´t changed anything on Postgres.conf related with autovacuum.
You probably should also look at this system view:
https://www.postgresql.org/docs/11/monitoring-stats.html#PG-STAT-ALL-TABLES-VIEW
to see w
On 7/25/19 4:01 PM, PegoraroF10 wrote:
Nope, no one message near those statements.
I haven´t changed anything on Postgres.conf related with autovacuum.
So what are the settings?
--
Adrian Klaver
adrian.kla...@aklaver.com
Nope, no one message near those statements.
I haven´t changed anything on Postgres.conf related with autovacuum.
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
On 7/25/19 3:16 PM, PegoraroF10 wrote:
So, what should I tune on autovacuum ?
My script was running strangely. Postgres log shows me the time spent to
create functions. That happens when creating triggers and tables too.
Sometimes it´s too fast and sometimes ...
I didn't realize there is too fa
So, what should I tune on autovacuum ?
My script was running strangely. Postgres log shows me the time spent to
create functions. That happens when creating triggers and tables too.
Sometimes it´s too fast and sometimes ...
statement: create or replace function valoresdfe... 0 mins 1.135 secs
-Original Message-
From: Tom Lane
Sent: Thursday, July 25, 2019 2:47 PM
To: Adrian Klaver
Cc: Kevin Brannen ; pgsql-generallists.postgresql.org
Subject: Re: SELECT INTO question
Adrian Klaver mailto:adrian.kla...@aklaver.com>>
writes:
> On 7/25/19 12:23 PM, Kevin Brannen wrote:
>>
Adrian Klaver writes:
> On 7/25/19 12:23 PM, Kevin Brannen wrote:
>> We're trying to understand what happened with a SELECT INTO. The problem
>> can be see with this example:
>>
>> nms=# select into t2 from t1;
>> SELECT 5
>> # select * from t2;
>> --
>> (5 rows)
> The list of output expression
On 7/25/19 10:24 AM, Thomas Tignor wrote:
Hi Adrian,
Thanks for responding. Below is the schema data for the tables where we
always see corruption. You'll notice they have triggers for a postgres
extension called Slony-I which provides replication service. It's not
clear if/how that's a factor
On 7/25/19 12:23 PM, Kevin Brannen wrote:
Hi,
We’re trying to understand what happened with a SELECT INTO. The problem
can be see with this example:
# create table t1 (id int, v int);
CREATE TABLE
# insert into t1 (select x, x from generate_series(1, 5) as g(x));
INSERT 0 5
# select * fro
Hi,
We're trying to understand what happened with a SELECT INTO. The problem can be
see with this example:
# create table t1 (id int, v int);
CREATE TABLE
# insert into t1 (select x, x from generate_series(1, 5) as g(x));
INSERT 0 5
# select * from t1;
id | v
+
1 | 1
2 | 2
3 |
Hi Adrian,Thanks for responding. Below is the schema data for the tables where
we always see corruption. You'll notice they have triggers for a postgres
extension called Slony-I which provides replication service. It's not clear
if/how that's a factor, though.
ams=# \d ams.alert_instance
On 7/25/19 12:43 AM, Cyril Champier wrote:
*Adrian*:
If order is not an issue in the production code why test for it in the
test code?
In many cases, it would not be a problem in tests if we had an unordered
array comparison helper.
But in other cases, it is a production issue.
In ru
Peter:
So I would need to create a pg extension encapsulating this hook callback?
If this is the case, it seems it will be much more complicated than
expected, and I wont be able to do it :(
But thanks for the suggestion anyway.
On Thu, Jul 25, 2019 at 12:21 PM Peter Eisentraut <
peter.eisentr...@
On 2019-07-25 09:43, Cyril Champier wrote:
> It might be an interesting exercise to implement this as a post-parsing
> hook.
>
>
> I known nothing about that, but that sounds interesting, do you have any
> documentation pointer to help me implement that?
Look for post_parse_analyze_hook
> On 24 Jul 2019, at 10:08, jay chauhan wrote:
>
> Hi Thomas, David/Team,
>
> Thanks you for your response. However we need your confirmation whether my
> Error/issue as mentioned below will be resolved if we upgrade our PostgreSQL
> Version.
It won’t, you are talking about Oracle-specific
*Adrian*:
>
> If order is not an issue in the production code why test for it in the
> test code?
In many cases, it would not be a problem in tests if we had an unordered
array comparison helper.
But in other cases, it is a production issue.
In ruby ActiveRecord for exemple, you can do `Patient.f
16 matches
Mail list logo
