RE: pg_wal fills up on big update query

[Daniel Fink (PDF)]

Hi Rob,

Thanks, I will try.
It’s a bit of a  bummer though, because I just started to use flywaydb to
manage migrations, and it wraps all migrations into a single transaction.
So I have to do this outside of the tool.
I will still try to evaluate if locking has any effect, to have a better
understanding of how postgres works under the hood.

Best Regards,
Daniel

-Original Message-
From: Luca Ferrari [mailto:fluca1...@gmail.com]
Sent: Friday, August 9, 2019 3:58 PM
To: Daniel Fink (PDF) 
Cc: pgsql-general 
Subject: Re: pg_wal fills up on big update query

On Wed, Aug 7, 2019 at 3:34 PM Daniel Fink (PDF) 
wrote:
> My current idea is to lock both tables completely from access (the queried
> and the updated one) so that postgresql does not have to ensure isolation
> for concurrent queries by keeping a copy of each row.

I'm not sure that locking will prevent the snapshotting and the WAL
machinery, but someone more expert on the are could clarify this.
Since the column is nullable, I would apply it outside of the transaction,
and then do the update. If that still fails, I would try to split the update
on small chunks (after all, it's an update, so it is smething you can line
up data).

Luca

-- 
This message may contain confidential and privileged information. If it has 
been sent to you in error, please reply to advise the sender of the error 
and then immediately permanently delete it and all attachments to it from 
your systems. If you are not the intended recipient, do not read, copy, 
disclose or otherwise use this message or any attachments to it. The sender 
disclaims any liability for such unauthorized use.  PLEASE NOTE that all 
incoming e-mails sent to PDF e-mail accounts will be archived and may be 
scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any 
concerns about this process, please contact us at legal.departm...@pdf.com 
<mailto:legal.departm...@pdf.com>.

RE: pg_wal fills up on big update query

[Daniel Fink (PDF)]

Hi Rob,



Thanks, I will try.

It’s a bit of a  bummer though, because I just started to use flywaydb to
manage migrations, and it wraps all migrations into a single transaction.

So I have to do this outside of the tool.



Best Regards,

Daniel



*From:* Rob Sargent [mailto:robjsarg...@gmail.com]
*Sent:* Wednesday, August 7, 2019 4:22 PM
*To:* Daniel Fink (PDF) 
*Cc:* pgsql-general@lists.postgresql.org
*Subject:* Re: pg_wal fills up on big update query






On Aug 7, 2019, at 7:34 AM, Daniel Fink (PDF)  wrote:

Hi all,



I have a migration where I

·   Add a new nullable column to a table

·   update almost every row in this big table (8 million rows) from
another table where I set this new column



I have also a replication setup running.

The database has a size of around 20GB.

While the migration is running, it more than doubles is size and fills up
all space.

Then the migration fails and is rolled back.



What is the best way of keeping this from happening?

My current idea is to lock both tables completely from access (the queried
and the updated one) so that postgresql does not have to ensure isolation
for concurrent queries by keeping a copy of each row.

Is my thinking here correct?



Thanks in advance and Best Regards,



Do the update in small chunks

-- 
This message may contain confidential and privileged information. If it has 
been sent to you in error, please reply to advise the sender of the error 
and then immediately permanently delete it and all attachments to it from 
your systems. If you are not the intended recipient, do not read, copy, 
disclose or otherwise use this message or any attachments to it. The sender 
disclaims any liability for such unauthorized use.  PLEASE NOTE that all 
incoming e-mails sent to PDF e-mail accounts will be archived and may be 
scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any 
concerns about this process, please contact us at legal.departm...@pdf.com 
<mailto:legal.departm...@pdf.com>.

pg_wal fills up on big update query

[Daniel Fink (PDF)]

Hi all,



I have a migration where I

· Add a new nullable column to a table

· update almost every row in this big table (8 million rows) from
another table where I set this new column



I have also a replication setup running.

The database has a size of around 20GB.

While the migration is running, it more than doubles is size and fills up
all space.

Then the migration fails and is rolled back.



What is the best way of keeping this from happening?

My current idea is to lock both tables completely from access (the queried
and the updated one) so that postgresql does not have to ensure isolation
for concurrent queries by keeping a copy of each row.

Is my thinking here correct?



Thanks in advance and Best Regards,

Daniel

-- 
This message may contain confidential and privileged information. If it has 
been sent to you in error, please reply to advise the sender of the error 
and then immediately permanently delete it and all attachments to it from 
your systems. If you are not the intended recipient, do not read, copy, 
disclose or otherwise use this message or any attachments to it. The sender 
disclaims any liability for such unauthorized use.  PLEASE NOTE that all 
incoming e-mails sent to PDF e-mail accounts will be archived and may be 
scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any 
concerns about this process, please contact us at legal.departm...@pdf.com 
.

RE: bdr replication breaks down

[Daniel Fink (PDF)]

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 [mailto:aagu...@opensysperu.com]
Sent: Monday, February 11, 2019 2:21 PM
To: Daniel Fink (PDF)
Cc: pgsql-general
Subject: Re: bdr replication breaks down

What's the command you are running to trigger such behaviour?

Regards,

Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.

(+51-1) 337-7813 Anexo 4002
www.ocs.pe

- Original Message -
From: "Daniel Fink (PDF)" 
To: "pgsql-general" 
Sent: Monday, 11 February, 2019 05:18:30
Subject: bdr replication breaks down

Hi all,



I have a bdr replication setup that worked fine until recently.

But it seems like one command cannot be replicated, and it breaks down the
whole process on all hosts where it is sent to.

I appended part of the log file, it gets repeated over and over.

Can I somehow omit this command and try if the next one works?



Best Regards,

Daniel Fink



< 2019-02-08 00:00:01.658 CET >ERROR:  schema "pg_temp_30" does not exist

< 2019-02-08 00:00:01.658 CET >CONTEXT:  apply QUEUED_DROP in commit
7D/2E3143B0, xid 106791715 commited at 2019-01-28 10:12:34.348577+01 (action
#2) from node (6208877715678412212,1,2942745)

< 2019-02-08 00:00:01.661 CET >LOG:  worker process: bdr
(6449651545875285115,1,16388,)->bdr (6208877715678412212,1, (PID 27640)
exited with exit code 1

< 2019-02-08 00:00:06.666 CET >LOG:  starting background worker process "bdr
(6449651545875285115,1,16388,)->bdr (6208877715678412212,1,"

< 2019-02-08 00:00:07.641 CET >ERROR:  schema "pg_temp_30" does not exist

< 2019-02-08 00:00:07.641 CET >CONTEXT:  apply QUEUED_DROP in commit
7D/2E3143B0, xid 106791715 commited at 2019-01-28 10:12:34.348577+01 (action
#2) from node (6208877715678412212,1,2942745)

< 2019-02-08 00:00:07.644 CET >LOG:  worker process: bdr
(6449651545875285115,1,16388,)->bdr (6208877715678412212,1, (PID 27645)
exited with exit code 1

< 2019-02-08 00:00:12.649 CET >LOG:  starting background worker process "bdr
(6449651545875285115,1,16388,)->bdr (6208877715678412212,1,"

< 2019-02-08 00:00:13.633 CET >ERROR:  schema "pg_temp_30" does not exist

< 2019-02-08 00:00:13.633 CET >CONTEXT:  apply QUEUED_DROP in commit
7D/2E3143B0, xid 106791715 commited at 2019-01-28 10:12:34.348577+01 (action
#2) from node (6208877715678412212,1,2942745)




*DANIEL FINK*

*Senior Software Engineer*

*tel* (+49) 89.767062.20
*fax*(+49) 89.767062.11
email daniel.f...@pdf.com

*PDF Solutions GmbH*
* (**a PDF Solutions Company)*
Managing Director: Kimon Michaels
Schwanthalerstr. 10
D-80336 München, Germany

München HRB 87307
DE 128214899

*www.pdf.com <http://www.pdf.com/>*

--
This message may contain confidential and privileged information. If it has
been sent to you in error, please reply to advise the sender of the error
and then immediately permanently delete it and all attachments to it from
your systems. If you are not the intended recipient, do not read, copy,
disclose or otherwise use this message or any attachments to it. The sender
disclaims any liability for such unauthorized use.  PLEASE NOTE that all
incoming e-mails sent to PDF e-mail accounts will be archived and may be
scanned by us and/or by external service providers to detect and prevent
threats to our systems, investigate illegal or inappropriate behavior,
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any
concerns about this process, please contact us at legal.departm...@pdf.com
<mailto:legal.departm...@pdf.com>.

-- 
This message may contain confidential and privileged information. If it has 
been sent to you in error, please reply to advise the sender of the error 
and then immediately permanently delete it and all attachments to it from 
your systems. If you are not the intended recipient, do not read, copy, 
disclose or otherwise use this message or any attachments to it. The sender 
disclaims any liability for such unauthorized use.  PLEASE NOTE that all 
incoming e-mails sent to PDF e-mail accounts will be archived and may be 
scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any 
concerns about this process, please contact us at legal.departm...@pdf.com 
<mailto:legal.departm...@pdf.com>.

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

[Daniel Fink (PDF)]

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 removed the failing
workers.

Thanks for your help.

Best Regards,
Daniel

-Original Message-
From: Alvaro Aguayo Garcia-Rada [mailto:aagu...@opensysperu.com]
Sent: Tuesday, February 12, 2019 4:15 PM
To: Daniel Fink, PDF
Cc: pgsql-general
Subject: Re: BDR 1.0: background worker wants to start that should not be
there

Hi.

You have deleted the node from BDR setup, but you still have to delete it
from the postgres logical replication:

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot('YOURSLOT');

As a remark, based on my BDR experience, when your cluster has been damaged,
your best option is to rebuild it.

Saludos,

Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.

(+51-1) 337-7813 Anexo 4002
www.ocs.pe

- Original Message -----
From: "Daniel Fink, PDF" 
To: "pgsql-general" 
Sent: Tuesday, 12 February, 2019 09:52:09
Subject: BDR 1.0: background worker wants to start that should not be there

Hi all,



After I used bdr.bdr_part_by_node_names(*p_nodes text[]*) and removed the
nodes from bdr.bdr_nodes table I still get log errors about the nonexistent
pg_replication_slot:



< 2019-02-12 06:26:21.166 PST >LOG:  starting background worker process "bdr
(6208877715678412212,1,22576474,)->bdr (6449651545875285115"



How does postgresql deduce which workers need starting?

Is there a table I am missing?



Best Regards,




*DANIEL FINK*

*Senior Software Engineer*

*tel* (+49) 89.767062.20
*fax*(+49) 89.767062.11
email daniel.f...@pdf.com

*PDF Solutions GmbH*
* (**a PDF Solutions Company)*
Managing Director: Kimon Michaels
Schwanthalerstr. 10
D-80336 München, Germany

München HRB 87307
DE 128214899

*www.pdf.com <http://www.pdf.com/>*

--
This message may contain confidential and privileged information. If it has
been sent to you in error, please reply to advise the sender of the error
and then immediately permanently delete it and all attachments to it from
your systems. If you are not the intended recipient, do not read, copy,
disclose or otherwise use this message or any attachments to it. The sender
disclaims any liability for such unauthorized use.  PLEASE NOTE that all
incoming e-mails sent to PDF e-mail accounts will be archived and may be
scanned by us and/or by external service providers to detect and prevent
threats to our systems, investigate illegal or inappropriate behavior,
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any
concerns about this process, please contact us at legal.departm...@pdf.com
<mailto:legal.departm...@pdf.com>.

-- 
This message may contain confidential and privileged information. If it has 
been sent to you in error, please reply to advise the sender of the error 
and then immediately permanently delete it and all attachments to it from 
your systems. If you are not the intended recipient, do not read, copy, 
disclose or otherwise use this message or any attachments to it. The sender 
disclaims any liability for such unauthorized use.  PLEASE NOTE that all 
incoming e-mails sent to PDF e-mail accounts will be archived and may be 
scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any 
concerns about this process, please contact us at legal.departm...@pdf.com 
<mailto:legal.departm...@pdf.com>.

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

[Daniel Fink (PDF)]

Hi all,



After I used bdr.bdr_part_by_node_names(*p_nodes text[]*) and removed the
nodes from bdr.bdr_nodes table I still get log errors about the nonexistent
pg_replication_slot:



< 2019-02-12 06:26:21.166 PST >LOG:  starting background worker process
"bdr (6208877715678412212,1,22576474,)->bdr (6449651545875285115"



How does postgresql deduce which workers need starting?

Is there a table I am missing?



Best Regards,




*DANIEL FINK*

*Senior Software Engineer*

*tel* (+49) 89.767062.20
*fax*(+49) 89.767062.11
email daniel.f...@pdf.com

*PDF Solutions GmbH*
* (**a PDF Solutions Company)*
Managing Director: Kimon Michaels
Schwanthalerstr. 10
D-80336 München, Germany

München HRB 87307
DE 128214899

*www.pdf.com *

-- 
This message may contain confidential and privileged information. If it has 
been sent to you in error, please reply to advise the sender of the error 
and then immediately permanently delete it and all attachments to it from 
your systems. If you are not the intended recipient, do not read, copy, 
disclose or otherwise use this message or any attachments to it. The sender 
disclaims any liability for such unauthorized use.  PLEASE NOTE that all 
incoming e-mails sent to PDF e-mail accounts will be archived and may be 
scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any 
concerns about this process, please contact us at legal.departm...@pdf.com 
.

RE: bdr replication breaks down

[Daniel Fink (PDF)]

94967295

rmgr: Heaplen (rec/tot): 26/58, tx:  106791715, lsn:
7D/2E313898, prev 7D/2E313850, bkp: , desc: delete: rel
1663/2942745/12877; tid 65/72 KEYS_UPDATED

rmgr: Heap2   len (rec/tot): 34/66, tx:  106791715, lsn:
7D/2E3138D8, prev 7D/2E313898, bkp: , desc: new_cid: rel
1663/2942745/12747; tid 12/9; cmin: 4294967295, cmax: 2, combo: 4294967295

rmgr: Heaplen (rec/tot): 26/58, tx:  106791715, lsn:
7D/2E313920, prev 7D/2E3138D8, bkp: , desc: delete: rel
1663/2942745/12747; tid 12/9 KEYS_UPDATED

rmgr: Heap2   len (rec/tot): 34/66, tx:  106791715, lsn:
7D/2E313960, prev 7D/2E313920, bkp: , desc: new_cid: rel
1663/2942745/12877; tid 65/71; cmin: 4294967295, cmax: 2, combo: 4294967295

rmgr: Heaplen (rec/tot): 26/58, tx:  106791715, lsn:
7D/2E3139A8, prev 7D/2E313960, bkp: , desc: delete: rel
1663/2942745/12877; tid 65/71 KEYS_UPDATED

rmgr: Heap2   len (rec/tot): 34/66, tx:  106791715, lsn:
7D/2E3139E8, prev 7D/2E3139A8, bkp: , desc: new_cid: rel
1663/2942745/12759; tid 74/33; cmin: 4294967295, cmax: 3, combo: 4294967295

rmgr: Heaplen (rec/tot): 26/58, tx:  106791715, lsn:
7D/2E313A30, prev 7D/2E3139E8, bkp: , desc: delete: rel
1663/2942745/12759; tid 74/33 KEYS_UPDATED

rmgr: Heap2   len (rec/tot): 34/66, tx:  106791715, lsn:
7D/2E313A70, prev 7D/2E313A30, bkp: , desc: new_cid: rel
1663/2942745/12759; tid 74/34; cmin: 4294967295, cmax: 3, combo: 4294967295

rmgr: Heaplen (rec/tot): 26/58, tx:  106791715, lsn:
7D/2E313AB8, prev 7D/2E313A70, bkp: , desc: delete: rel
1663/2942745/12759; tid 74/34 KEYS_UPDATED

rmgr: Heap2   len (rec/tot): 34/66, tx:  106791715, lsn:
7D/2E313AF8, prev 7D/2E313AB8, bkp: , desc: new_cid: rel
1663/2942745/12759; tid 74/35; cmin: 4294967295, cmax: 3, combo: 4294967295

rmgr: Heaplen (rec/tot): 26/58, tx:  106791715, lsn:
7D/2E313B40, prev 7D/2E313AF8, bkp: , desc: delete: rel
1663/2942745/12759; tid 74/35 KEYS_UPDATED

rmgr: Heap2   len (rec/tot): 34/66, tx:  106791715, lsn:
7D/2E313B80, prev 7D/2E313B40, bkp: , desc: new_cid: rel
1663/2942745/12770; tid 14/33; cmin: 4294967295, cmax: 3, combo: 4294967295

rmgr: Heaplen (rec/tot): 26/58, tx:  106791715, lsn:
7D/2E313BC8, prev 7D/2E313B80, bkp: , desc: delete: rel
1663/2942745/12770; tid 14/33 KEYS_UPDATED

rmgr: Heap2   len (rec/tot): 34/66, tx:  106791715, lsn:
7D/2E313C08, prev 7D/2E313BC8, bkp: , desc: new_cid: rel
1663/2942745/12877; tid 65/73; cmin: 4294967295, cmax: 3, combo: 4294967295

rmgr: Heaplen (rec/tot): 26/58, tx:  106791715, lsn:
7D/2E313C50, prev 7D/2E313C08, bkp: , desc: delete: rel
1663/2942745/12877; tid 65/73 KEYS_UPDATED

rmgr: Heap2   len (rec/tot): 34/66, tx:  106791715, lsn:
7D/2E313C90, prev 7D/2E313C50, bkp: , desc: new_cid: rel 1664/0/12906;
tid 1/49; cmin: 4294967295, cmax: 3, combo: 4294967295

rmgr: Heaplen (rec/tot): 26/58, tx:  106791715, lsn:
7D/2E313CD8, prev 7D/2E313C90, bkp: , desc: delete: rel 1664/0/12906;
tid 1/49 KEYS_UPDATED

rmgr: Heaplen (rec/tot):160/  1660, tx:  106791715, lsn:
7D/2E313D18, prev 7D/2E313CD8, bkp: 1000, desc: insert: rel
1663/2942745/2943410; tid 0/7

rmgr: Transaction len (rec/tot):352/   384, tx:  106791715, lsn:
7D/2E3143B0, prev 7D/2E313D18, bkp: , desc: commit: 2019-01-28
01:12:34.348577 PST; inval msgs: catcache 7 catcache 6 catcache 7 catcache
6 catcache 7 catcache 6 catcache 46 catcache 45 catcache 64 catcache 63
catcache 64 catcache 63 catcache 49 relcache 23783862 snapshot 2608
snapshot 1214 snapshot 2608 snapshot 2608 relcache 23783862 snapshot 2608

rmgr: Standby len (rec/tot): 44/76, tx:  0, lsn:
7D/2E314530, prev 7D/2E3143B0, bkp: , desc: nontransactional message
with 35 bytes



*From:* Daniel Fink (PDF) [mailto:daniel.f...@pdf.com]
*Sent:* Monday, February 11, 2019 11:19 AM
*To:* pgsql-general@lists.postgresql.org
*Subject:* bdr replication breaks down



Hi all,



I have a bdr replication setup that worked fine until recently.

But it seems like one command cannot be replicated, and it breaks down the
whole process on all hosts where it is sent to.

I appended part of the log file, it gets repeated over and over.

Can I somehow omit this command and try if the next one works?



Best Regards,

Daniel Fink



< 2019-02-08 00:00:01.658 CET >ERROR:  schema "pg_temp_30" does not exist

< 2019-02-08 00:00:01.658 CET >CONTEXT:  apply QUEUED_DROP in commit
7D/2E3143B0, xid 106791715 commited at 2019-01-28 10:12:34.348577+01
(action #2) from node (6208877715678412212,1,2942745)

< 2019-02-08 00:00:01.661 CET >LOG:  worker process: bdr
(6449651545875285115,1,16388,)->bdr (6208877715678412212,1, (PID 27640)
exited with exit code 1

< 2019-02-08 00:00:06.666 CET >LOG:  starting ba

bdr replication breaks down

[Daniel Fink (PDF)]

Hi all,



I have a bdr replication setup that worked fine until recently.

But it seems like one command cannot be replicated, and it breaks down the
whole process on all hosts where it is sent to.

I appended part of the log file, it gets repeated over and over.

Can I somehow omit this command and try if the next one works?



Best Regards,

Daniel Fink



< 2019-02-08 00:00:01.658 CET >ERROR:  schema "pg_temp_30" does not exist

< 2019-02-08 00:00:01.658 CET >CONTEXT:  apply QUEUED_DROP in commit
7D/2E3143B0, xid 106791715 commited at 2019-01-28 10:12:34.348577+01
(action #2) from node (6208877715678412212,1,2942745)

< 2019-02-08 00:00:01.661 CET >LOG:  worker process: bdr
(6449651545875285115,1,16388,)->bdr (6208877715678412212,1, (PID 27640)
exited with exit code 1

< 2019-02-08 00:00:06.666 CET >LOG:  starting background worker process
"bdr (6449651545875285115,1,16388,)->bdr (6208877715678412212,1,"

< 2019-02-08 00:00:07.641 CET >ERROR:  schema "pg_temp_30" does not exist

< 2019-02-08 00:00:07.641 CET >CONTEXT:  apply QUEUED_DROP in commit
7D/2E3143B0, xid 106791715 commited at 2019-01-28 10:12:34.348577+01
(action #2) from node (6208877715678412212,1,2942745)

< 2019-02-08 00:00:07.644 CET >LOG:  worker process: bdr
(6449651545875285115,1,16388,)->bdr (6208877715678412212,1, (PID 27645)
exited with exit code 1

< 2019-02-08 00:00:12.649 CET >LOG:  starting background worker process
"bdr (6449651545875285115,1,16388,)->bdr (6208877715678412212,1,"

< 2019-02-08 00:00:13.633 CET >ERROR:  schema "pg_temp_30" does not exist

< 2019-02-08 00:00:13.633 CET >CONTEXT:  apply QUEUED_DROP in commit
7D/2E3143B0, xid 106791715 commited at 2019-01-28 10:12:34.348577+01
(action #2) from node (6208877715678412212,1,2942745)




*DANIEL FINK*

*Senior Software Engineer*

*tel* (+49) 89.767062.20
*fax*(+49) 89.767062.11
email daniel.f...@pdf.com

*PDF Solutions GmbH*
* (**a PDF Solutions Company)*
Managing Director: Kimon Michaels
Schwanthalerstr. 10
D-80336 München, Germany

München HRB 87307
DE 128214899

*www.pdf.com *

-- 
This message may contain confidential and privileged information. If it has 
been sent to you in error, please reply to advise the sender of the error 
and then immediately permanently delete it and all attachments to it from 
your systems. If you are not the intended recipient, do not read, copy, 
disclose or otherwise use this message or any attachments to it. The sender 
disclaims any liability for such unauthorized use.  PLEASE NOTE that all 
incoming e-mails sent to PDF e-mail accounts will be archived and may be 
scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any 
concerns about this process, please contact us at legal.departm...@pdf.com 
.

Enabling bdr in multiple databases on the same postgresql instance/cluster

[Daniel Fink (PDF)]

Hi all,



I already have a running cluster of BDR nodes.

Now we want to add an additional database on the same hosts.



Can I just create a new database and then create/join nodes as in this
description:

http://bdr-project.org/docs/1.0.3/quickstart-enabling.html



Best Regards,




*DANIEL FINK*

*Senior Software Engineer*

*tel* (+49) 89.767062.20
*fax*(+49) 89.767062.11
email daniel.f...@pdf.com

*PDF Solutions GmbH*
* (**a PDF Solutions Company)*
Managing Director: Kimon Michaels
Schwanthalerstr. 10
D-80336 München, Germany

München HRB 87307
DE 128214899

*www.pdf.com *

-- 
This message may contain confidential and privileged information. If it has 
been sent to you in error, please reply to advise the sender of the error 
and then immediately permanently delete it and all attachments to it from 
your systems. If you are not the intended recipient, do not read, copy, 
disclose or otherwise use this message or any attachments to it. The sender 
disclaims any liability for such unauthorized use.  PLEASE NOTE that all 
incoming e-mails sent to PDF e-mail accounts will be archived and may be 
scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”).  If you have any 
concerns about this process, please contact us at legal.departm...@pdf.com 
.