Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Hi Thomas, does that mean the bug is still there? Regards, Mike Yeap On Mon, Feb 25, 2019 at 4:06 PM Thomas Munro wrote: > On Thu, Feb 21, 2019 at 2:42 PM Mike Yeap wrote: > > openldap-clients.x86_64 2.4.44-21.el7_6 > @updates > > openldap-devel.i686

Re: atomically replace partition of range partitioned table

On Tue, 26 Feb 2019 at 12:03, Kevin Wilkinson wrote: > 1. create a new partition table by copying the old partition table, > ordered by index key. both tables will have the same partition key range. > 2. create a brin index on the new table. > 3. detach the old partition table from the parent and

Re: 9.0 standby - could not open file global/XXXXX

Hi, On 2019-02-25 20:06:42 +0100, Filip Rembiałkowski wrote: > There is a large (>5T) database on PostgreSQL 9.0.23. As Stephen said, this is long out of support. > 2. base backup is transferred directly to new server using > pg_start_backup + rsync + pg_stop_backup. Do you exclude any files?

atomically replace partition of range partitioned table

i have a range partitioned table with a brin index that i am using for "Internet-of-Things" kind of data (essentially timeseries data about some entities). the partition key is a timestamp. data is only loaded to the "current" partition and data is never modified. older partitions are static.

PostgreSQL DB Maintenance and Partitioning to keep data longer.

Hello pgsql-General Team, We have currently using Postgresql DB which is growing about 1.4 billion records/month with a total of about 16 to 17 billion records/year. The DB storage is growing about 6.8 TB/year including all indexes and data. Current total DB Storage we got is 60 TB. *Use

Re: 9.0 standby - could not open file global/XXXXX

Greetings, * Filip Rembiałkowski (filip.rembialkow...@gmail.com) wrote: > There is a large (>5T) database on PostgreSQL 9.0.23. First off, I hope you understand that 9.0 has been *long* out of support and that you *really* need to upgrade to a supported version of PostgreSQL (9.4 and up these

9.0 standby - could not open file global/XXXXX

Hi. There is a large (>5T) database on PostgreSQL 9.0.23. I would like to setup new WAL-shipping standby. https://www.postgresql.org/docs/9.0/warm-standby.html On my way I find unexpected issues. Here's the story, in short: 1. WAL archiving to remote archive is setup & verified 2. base backup

Re: Recommended way to enable data-checksums on Centos 7?

On 2/25/19 2:05 PM, Ken Tanzer wrote: On Mon, Feb 25, 2019 at 1:35 PM Adrian Klaver > wrote: If I am following correctly, what you want is something like the below from pg_ctl, correct?: https://www.postgresql.org/docs/11/app-pg-ctl.html

Re: Recommended way to enable data-checksums on Centos 7?

On Mon, Feb 25, 2019 at 1:35 PM Adrian Klaver wrote: > If I am following correctly, what you want is something > like the below from pg_ctl, correct?: > > https://www.postgresql.org/docs/11/app-pg-ctl.html > > pg_ctl init[db] [-D datadir] [-s] [-o initdb-options] ... > > > checksums are

Re: update table with suppress_redundant_updates_trigger()

On 2/25/19 10:42 AM, wambac...@posteo.de wrote: Hi, i'm doing a lot of updates in my database, but most of them are not necessary at all (sorry, just detected it) Would it not be easier to just not do the unnecessary updates? Or to put it another way what distinguishes

Re: Recommended way to enable data-checksums on Centos 7?

On 2/25/19 11:19 AM, Ken Tanzer wrote: On Sun, Feb 24, 2019 at 5:03 PM Adrian Klaver > wrote: On 2/24/19 2:39 PM, Ken Tanzer wrote: > I'm just wondering if there is a more preferred way to do this, Not seeing anything responsive to this

Re: Recommended way to enable data-checksums on Centos 7?

On Sun, Feb 24, 2019 at 5:03 PM Adrian Klaver wrote: > On 2/24/19 2:39 PM, Ken Tanzer wrote: > I'm just wondering if there is a more preferred way to do this, Not seeing anything responsive to this question, I'll assume that PGSETUP_INITDB_OPTIONS is the preferred method. > and/or > > any

update table with suppress_redundant_updates_trigger()

Hi, i'm doing a lot of updates in my database, but most of them are not necessary at all (sorry, just detected it) Therefore i installed a trigger to minimize real updates. create trigger suppress_redundant_updates_boundaries    before update on boundaries    for each row execute procedure

RE: bdr replication breaks down

Hi Alvaro, I could not determine what exactly the command was. But I "fixed" it by using bdr.skip_changes_upto() to skip this change from application. The replication resumed after that. Best Regards, Daniel -Original Message- From: Alvaro Aguayo Garcia-Rada

RE: BDR 1.0: background worker wants to start that should not be there

Hi Alvaro, Sorry for the late reply. Your mail was in the spam folder. I used the commands you suggested already. But I found another issue. I had two databases running BDR replication. I did not know that they have separate bdr.nodes tables. After I called bdr.bdr_part_by_node_names again, it

Re: Logical replication very slow

On 25/2/19 2:06 μ.μ., Boris Sagadin wrote: I think it should. I set it to unlogged on target/slave server only. One other table which is much smaller and already replicated receives changes from master. Ah, ok then. About settings copy_data to false, nice idea, I'll try that too and compare

Re: Logical replication very slow

I think it should. I set it to unlogged on target/slave server only. One other table which is much smaller and already replicated receives changes from master. About settings copy_data to false, nice idea, I'll try that too and compare speed. On Mon, Feb 25, 2019 at 9:51 AM Achilleas Mantzios

Re: Logical replication very slow

On 25/2/19 9:59 π.μ., Boris Sagadin wrote: Doing an initial replica. postgres 119454 93.5 25.9 34613692 32649656 ?   Rs   07:16  32:45  \_ postgres: 10/main: bgworker: logical replication worker for subscription 24783 sync 16500 I've cancelled the sync, set the tables to unlogged type and

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Thu, Feb 21, 2019 at 2:42 PM Mike Yeap wrote: > openldap-clients.x86_64 2.4.44-21.el7_6 > @updates > openldap-devel.i686 2.4.44-21.el7_6updates > openldap-devel.x86_64 2.4.44-21.el7_6updates >

Re: Logical replication very slow

Doing an initial replica. postgres 119454 93.5 25.9 34613692 32649656 ? Rs 07:16 32:45 \_ postgres: 10/main: bgworker: logical replication worker for subscription 24783 sync 16500 I've cancelled the sync, set the tables to unlogged type and started it again. I think it helped, still much