On 5/23/2017 11:39 PM, Ken Tanzer wrote:
Can I also ask y'all a more general question about this, specifically
related to how Postgres is packaged for RHEL/Centos? I've got both
9.6 and 9.2 installed. In this case though, it seems that the 9.2
version is privileged/selected by default. But
Hi,
On Tue, 2017-05-23 at 23:39 -0700, Ken Tanzer wrote:
> Can I also ask y'all a more general question about this, specifically
> related to how Postgres is packaged for RHEL/Centos? I've got both 9.6 and
> 9.2 installed. In this case though, it seems that the 9.2 version is
> privileged/sele
A few years ago, I was working with "big" servers. At least, they were
big for that age, with *128G* of RAM!!!1 Holy mackeral, right?!!?
Anyway, at that time, I tried allocating 64G to shared buffers and we
had a bunch of problems with inconsistent performance, including "stall"
periods where the
hello, at most 40% total memory, official doc also says so.you can testify it
using pg_prewarm and pgfincore .
btw, numa supported? if so, extra care is necessary when starting db cluster.
從我的 Samsung Galaxy 智慧型手機傳送。
原始訊息 自： Bill Moran 日期： 2017/5/24
20:24 (GMT+08:00) 至： pgsq
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]
Sent: Tuesday, May 23, 2017 5:48 PM
To: Igor Neyman ; pgsql-general@postgresql.org
Subject: Re: [GENERAL] logical replication in PG10 BETA
On 05/23/2017 08:15 AM, Igor Neyman wrote:
>
> -Original Message-
>
2017-05-24 15:02 GMT+02:00 stevenchang1213 :
> hello,
> at most 40% total memory, official doc also says so.
> you can testify it using pg_prewarm and pgfincore .
>
There are strong dependency on use case. 40% total memory is related to low
memory servers .. 64GB max.
High SB requires tuning oth
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]
Sent: Tuesday, May 23, 2017 7:42 PM
To: Igor Neyman ; George Neuner ;
pgsql-general@postgresql.org
Subject: Re: [GENERAL] logical replication in PG10 BETA
So take the local line out of pg_hba. Then from the machi
Adrian,
On Wed, May 24, 2017 at 12:09 AM, Adrian Klaver
wrote:
> On 05/23/2017 08:03 PM, Igor Korot wrote:
>>
>> Adrian,
>>
>> On Tue, May 23, 2017 at 10:45 PM, Igor Korot wrote:
>>>
>>> Adrian,
>>>
>>> On Tue, May 23, 2017 at 7:28 PM, Adrian Klaver
>>> wrote:
On 05/23/2017 04:15 PM,
On 05/24/2017 06:31 AM, Igor Neyman wrote:
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]
Sent: Tuesday, May 23, 2017 7:42 PM
To: Igor Neyman ; George Neuner ;
pgsql-general@postgresql.org
Subject: Re: [GENERAL] logical replication in PG10 BETA
So take the l
On 05/24/2017 06:58 AM, Igor Korot wrote:
Adrian,
On Wed, May 24, 2017 at 12:09 AM, Adrian Klaver
wrote:
It would help to know what you plan to do with the library.
I am still developing. There fore everything is build in Debug mode.
While on *nix this is not an issue, on Windows it is as
On Wed, May 24, 2017 at 10:14 AM, Adrian Klaver
wrote:
> On 05/24/2017 06:58 AM, Igor Korot wrote:
>>
>> Adrian,
>>
>> On Wed, May 24, 2017 at 12:09 AM, Adrian Klaver
>> wrote:
>
>
>
>>> It would help to know what you plan to do with the library.
>>
>>
>> I am still developing. There fore everyth
On 05/24/2017 07:18 AM, Igor Korot wrote:
On Wed, May 24, 2017 at 10:14 AM, Adrian Klaver
wrote:
On 05/24/2017 06:58 AM, Igor Korot wrote:
Adrian,
On Wed, May 24, 2017 at 12:09 AM, Adrian Klaver
wrote:
It would help to know what you plan to do with the library.
I am still developing
is there possibility btree_redo with XLOG_BTREE_DELETE info done between
standby_redo and the end of backup? I have PostgreSQL 9.3.14 which have
some patches to use and easy to happen.
//checkpoint
[26005-59251d35.6595-712522] 2017-05-24 05:42:22.343 GMT < > DEBUG: 0:
recovery snapshots are
New thread created.
Thank you.
On Wed, May 24, 2017 at 10:24 AM, Adrian Klaver
wrote:
> On 05/24/2017 07:18 AM, Igor Korot wrote:
>>
>> On Wed, May 24, 2017 at 10:14 AM, Adrian Klaver
>> wrote:
>>>
>>> On 05/24/2017 06:58 AM, Igor Korot wrote:
Adrian,
On Wed, May 24, 20
Hi, ALL,
Does anybody have a ready-to-use solution for libpq binaries for the
Debug build on Windows?
Thank you.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, 24 May 2017 21:02:45 +0800
stevenchang1213 wrote:
> hello, at most 40% total memory, official doc also says so.
The docs say, "it is unlikely that an allocation of more than 40% of RAM
to shared_buffers will work better than a smaller amount" which is a far
cry from defining a maximum am
y39chen writes:
> is there possibility btree_redo with XLOG_BTREE_DELETE info done between
> standby_redo and the end of backup? I have PostgreSQL 9.3.14 which have
> some patches to use and easy to happen.
> ...
> //inconsistent detected in btree_xlog_delete_get_latestRemovedXid()
> [26005-59251
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]
Sent: Wednesday, May 24, 2017 10:00 AM
To: Igor Neyman ; George Neuner ;
pgsql-general@postgresql.org
Subject: Re: [GENERAL] logical replication in PG10 BETA
On 05/24/2017 06:31 AM, Igor Neyman wrote:
>
> -Ori
On Wed, May 24, 2017 at 11:18 AM, Tom Lane wrote:
> y39chen writes:
>> is there possibility btree_redo with XLOG_BTREE_DELETE info done between
>> standby_redo and the end of backup? I have PostgreSQL 9.3.14 which have
>> some patches to use and easy to happen.
>> ...
>> //inconsistent detected
Michael Paquier writes:
> On Wed, May 24, 2017 at 11:18 AM, Tom Lane wrote:
>> This looks a whole lot like a bug we fixed in 9.3.15, cf
>> https://www.postgresql.org/message-id/flat/DB5PR07MB15416C65687A1EA9AC0D26F8D6E00%40DB5PR07MB1541.eurprd07.prod.outlook.com
> To which commit are you referri
1. cache miss due to 256kb ring buffer for large volume data io. that's why
warming tool is developed for covering the issue.2.pg_prewarm containing in
contrib module since 9.4, but patch for 9.2, which load relation data to share
buffer or is cache.3.pgfincore is a external module like rpm f
for ur reference
https://madusudanan.com/blog/understanding-postgres-caching-in-depth/
從我的 Samsung Galaxy 智慧型手機傳送。
原始訊息 自： stevenchang1213 日期：
2017/5/24 23:48 (GMT+08:00) 至： Bill Moran 副本：
pgsql-general@postgresql.org 主旨： Re: [GENERAL] Current best practice for
maximum sh
On Wed, May 24, 2017 at 08:24:15AM -0400, Bill Moran wrote:
> ... I tried allocating 64G to shared buffers and we had a bunch of problems
> with inconsistent performance, including "stall" periods where the database
> would stop responding for 2 or 3 seconds. After trying all sorts of tuning
> opt
On Wed, May 24, 2017 at 11:47 AM, Tom Lane wrote:
> Wup, sorry, I quoted the wrong thread mentioning
> btree_xlog_delete_get_latestRemovedXid. The right one is
>
> https://www.postgresql.org/message-id/flat/00F0B2CEF6D0CEF8A90119D4%40eje.credativ.lan
>
> and the patch is
>
> Author: Tom Lane
> B
Hi all,
I am writing a blog post about changes to the catalogs between v9.6.3
and the upcoming v10. I've diffed the catalogs.sgml and it looks
pretty informative so far, see
https://gist.github.com/sql-migrate/8e87214cc3127ba52fc93a589f040425.
I'm not too familiar with the release cycle and wheth
On Wed, May 24, 2017 at 9:22 AM, Neil Anderson
wrote:
> Hi all,
>
> I am writing a blog post about changes to the catalogs between v9.6.3
> and the upcoming v10. I've diffed the catalogs.sgml and it looks
> pretty informative so far, see
> https://gist.github.com/sql-migrate/8e87214cc3127ba52fc93
>
> Feature freeze is in effect and we have a Beta release out. Major bugs or
> major usability issues are the only things that would cause any change to
> the catalogs at this point and there likely won't be many, if any, of those
> (at least not ones that necessitate catalog changes - must disco
On Wed, May 24, 2017 at 6:24 AM, Bill Moran wrote:
>
> A few years ago, I was working with "big" servers. At least, they were
> big for that age, with *128G* of RAM!!!1 Holy mackeral, right?!!?
>
> Anyway, at that time, I tried allocating 64G to shared buffers and we
> had a bunch of problems with
I have this query that is not picking the right index unless I hard code dates:
SELECT "topics".* FROM "topics"
WHERE topics.last_unread_at >= '2017-05-11 20:56:24'
"Index Scan using index_topics_on_last_unread_at on topics
(cost=0.41..8.43 rows=1 width=725) (actual time=0.005..0.065 rows=5
loop
On Wed, May 24, 2017 at 1:42 PM, Sam Saffron wrote:
> I have this query that is not picking the right index unless I hard code
> dates:
>
>
> SELECT "topics".* FROM "topics"
> WHERE topics.last_unread_at >= '2017-05-11 20:56:24'
>
> "Index Scan using index_topics_on_last_unread_at on topics
> (co
Jeff Janes writes:
> On Wed, May 24, 2017 at 1:42 PM, Sam Saffron wrote:
>> I have this query that is not picking the right index unless I hard code
>> dates:
>> ...
> Maybe it should first execute the subquery and then re-plan the rest of the
> query based on the results. But there is no provi
Awesome, thanks! I will give that a shot
On Wed, 24 May 2017 at 6:14 pm, Tom Lane wrote:
> Jeff Janes writes:
> > On Wed, May 24, 2017 at 1:42 PM, Sam Saffron
> wrote:
> >> I have this query that is not picking the right index unless I hard code
> >> dates:
> >> ...
>
> > Maybe it should first
We have not noted any issues, but when I ran a pg_dump on an 8.3.3
database, it failed after an hour or so with the error:
ERROR: invalid page header in block 2264419 of relation "pg_largeobject"
pg_dump: The command was: FETCH 1000 IN bloboid
As we seem to have some data corruption issue, the
On 05/24/2017 08:30 AM, Igor Neyman wrote:
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]
Sent: Wednesday, May 24, 2017 10:00 AM
To: Igor Neyman ; George Neuner ;
pgsql-general@postgresql.org
Subject: Re: [GENERAL] logical replication in PG10 BETA
On 05/24/20
David Wall writes:
> We have not noted any issues, but when I ran a pg_dump on an 8.3.3
> database, it failed after an hour or so with the error:
8.3.3?
> cat /proc/version
> Linux version 2.6.18-92.1.10.el5.xs5.0.0.39xen (root@pondo-2) (gcc
> version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP
On 5/24/17 4:18 PM, Tom Lane wrote:
David Wall writes:
We have not noted any issues, but when I ran a pg_dump on an 8.3.3
database, it failed after an hour or so with the error:
8.3.3?
Yes, it's old.
cat /proc/version
Linux version 2.6.18-92.1.10.el5.xs5.0.0.39xen (root@pondo-2) (gcc
versio
Hello,
read it and test it , you will know why offical doc suggest no more
than 40% total memory for shared_buffers
http://raghavt.blogspot.tw/2012/04/caching-in-postgresql.html
And this is also a very good book -- http://www.interdb.jp/pg/index.html
IT job is just to keep repeating study
37 matches
Mail list logo
