On Mon, Feb 18, 2019 at 2:19 PM Michael Paquier wrote:
> On Sun, Feb 17, 2019 at 10:54:54AM -0800, Andres Freund wrote:
> > On 2019-02-17 23:29:09 +1300, Thomas Munro wrote:
> >> Hmm. Well, at least ENOSPC should be treated the same way as EIO.
> >> Here's an experiment that seems to confirm some
On Fri, Feb 15, 2019 at 12:03:39PM -0800, Andre Piwoni wrote:
> My slave nodes were created using pg_basebackup with --wal-method=stream.
> If I understand right this option streams WAL files generated during backup
> and this WAL file was 00010002 but its contents were
> different
On Sun, Feb 17, 2019 at 10:54:54AM -0800, Andres Freund wrote:
> On 2019-02-17 23:29:09 +1300, Thomas Munro wrote:
>> Hmm. Well, at least ENOSPC should be treated the same way as EIO.
>> Here's an experiment that seems to confirm some speculations about NFS
>> on Linux from the earlier threads:
>
On Fri, Feb 15, 2019 at 04:18:40PM -0500, Hugh Ranalli wrote:
> I did see that. However, I'm not *trying* to use it. I set up accounts with
> scram-sha-256 passwords, and when trying to connect I get this message.
> Hence why I tried to disable it.
tls-server-end-point is implemented as channel bi
"Riaan Stander" writes:
> I've got a scenario where I'm building a table structure that allows for
> building a tree. In order to properly separate the different column
> requirements I've looked at using table inheritance.
> [ but can't point a foreign key at an inheritance tree ]
> My question i
Good day
I've got a scenario where I'm building a table structure that allows for
building a tree. In order to properly separate the different column
requirements I've looked at using table inheritance.
Example structure:
CREATE TABLE base_table
(
idbigint primary key,
paren
Hello,
It seems that pgss doesn't track commit (nor rollback) commands from
pl/pgsql blocks.
using psql in version 11.1:
select pg_stat_statements_reset();
do $$ begin commit; end $$;
select calls,query from pg_stat_statements;
...
I don't know how difficult it would be to fix it,
but this coul
On Sun, Feb 17, 2019 at 6:32 AM Vijaykumar Jain wrote:
> I am yet to figure out the reason, what we have done is implement fake
> columns to represent samples and giving them random numbers and keeping
> other bulls to fake limit.
>
> Most of the queries that were impacted were the ones that did
Ok.
I’ll try to work on it this week and see if i am able to reproduce anything.
On Mon, 18 Feb 2019 at 2:30 AM Jeff Janes wrote:
>
>
> On Sun, Feb 17, 2019 at 2:37 PM Vijaykumar Jain
> wrote:
>
>>
>> Ok, i raked this from the logs where enabled log_min_duration_statement =
>> 10s
>>
>> 2019-01
On Sun, Feb 17, 2019 at 2:37 PM Vijaykumar Jain wrote:
>
> Ok, i raked this from the logs where enabled log_min_duration_statement =
> 10s
>
> 2019-01-31 12:48:18 UTC LOG: duration: 29863.311 ms statement: EXPLAIN
> SELECT blah, FROM public.view WHERE ((scheduled_bdt >= '2019-01-20'::date))
> A
On Sunday, 17 February 2019 20:58:47 EET Jeff Janes wrote:
> A question for the PostgreSQL hackers would be, Is it necessary and
> desirable that the EXPLAIN be issued in the same transaction as the
> eventual DECLARE and FETCHes? I don't think it is. I guess if the foreign
> side table definitio
Regards,
Vijay
On Mon, Feb 18, 2019 at 12:56 AM Jeff Janes wrote:
> On Sun, Feb 17, 2019 at 1:52 PM Vijaykumar Jain
> wrote:
>
>> Assuming your questions as 1,2,3, please find my answers below.
>>
>> 1)"explain" on foreign servers run as "idle in transactions". coz they
>> were running very lo
Hey Jeff,
yes, we now relaxed the idle in transaction setting to 15 mins.
i was hesitant to increase the settings as it blocked auto vaccum. We use
hot_standby_feedback = true also as we split reads/writes and allow long
running queries on read replicas, this too affects auto vaccum.
so overall,
On Sun, Feb 17, 2019 at 1:52 PM Vijaykumar Jain wrote:
> Assuming your questions as 1,2,3, please find my answers below.
>
> 1)"explain" on foreign servers run as "idle in transactions". coz they
> were running very long (in the order of some minutes) , pgbouncer (in tx
> level pooling) setting k
Jeff Janes writes:
> A question for the PostgreSQL hackers would be, Is it necessary and
> desirable that the EXPLAIN be issued in the same transaction as the
> eventual DECLARE and FETCHes? I don't think it is.
It seems like a good idea to me. I certainly don't think "I've got
an idle-in-trans
On Sun, Feb 17, 2019 at 12:41 PM Jeff Janes wrote:
> On Mon, Feb 4, 2019 at 2:15 AM Vijaykumar Jain
> wrote:
>
>>
>> now we have some long running queries via FDW that take minutes and get
>> killed explain runs as idle in transaction on remote servers.
>>
>
> Are you saying the EXPLAIN itself g
Hi,
On 2019-02-17 23:29:09 +1300, Thomas Munro wrote:
> Hmm. Well, at least ENOSPC should be treated the same way as EIO.
> Here's an experiment that seems to confirm some speculations about NFS
> on Linux from the earlier threads:
I wish we'd' a good way to have test scripts in the tree for som
Assuming your questions as 1,2,3, please find my answers below.
1)"explain" on foreign servers run as "idle in transactions". coz they were
running very long (in the order of some minutes) , pgbouncer (in tx level
pooling) setting kill them (as idle in tx time limit exceeded of 5 mins) or
else res
On Mon, Feb 4, 2019 at 2:15 AM Vijaykumar Jain wrote:
>
> now we have some long running queries via FDW that take minutes and get
> killed explain runs as idle in transaction on remote servers.
>
Are you saying the EXPLAIN itself gets killed, or execution of the plan
generated based on the EXPLA
On Thu, Feb 14, 2019 at 4:58 PM Michael Lewis wrote:
> This is beyond my expertise except to say that if your storage is SSDs in
> AWS, then you definitely want random_page_cost close to the same as
> seq_page_cost (1 by default) assuming your data is likely to be in cache as
> discussed in the d
If this one appears in the list, then it means the problem is with AOL.
I am yet to figure out the reason, what we have done is implement fake
columns to represent samples and giving them random numbers and keeping
other bulls to fake limit.
Most of the queries that were impacted were the ones that did not push
order by and limit to foreign servers.
I am also trying t
Related to this question:
Postgresql cursors are in most cases I've tried extremely slow. The cause is as
described in my previous answer, in my experience. Is there any plan or way to
improve this situation? For example, for FDW one would expect the plan on the
remote side to be similar, if no
On Sun, Feb 17, 2019 at 4:56 AM Tom Lane wrote:
> Thomas Munro writes:
> >>> Really? The specification says that it starts I/O, not that it waits
> >>> around for any to finish.
>
> > Right, there was some discussion of that, and I didn't (and still
> > don't) think it'd be wise to rely on undoc
24 matches
Mail list logo
