This is probably off topic for pgsql-hackers.
For password crypto please go read the SCRAM thread and the PostgreSQL
10 release notes.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing lis
without the rest
of the (sysid,timeline,dboid) tuple.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http:/
On 12 October 2017 at 11:03, Andres Freund <and...@anarazel.de> wrote:
> On 2017-10-12 10:25:43 +0800, Craig Ringer wrote:
>> On 4 October 2017 at 00:21, milist ujang <ujang.mil...@gmail.com> wrote:
>> > On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer
On 4 October 2017 at 00:21, milist ujang <ujang.mil...@gmail.com> wrote:
> On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer <cr...@2ndquadrant.com> wrote:
>>
>>
>> Can you get stacks please?
>>
>> Use -g
>
>
> # Events: 2K c
tabases, in this machine there are around 250+ wal
> sender processes.
>
Not a great use case for BDR.
Consider pglogical.
>
> finally get which processes (wal senders) that are using mutexes:
>
> perf top -e task-clock -p 55382
>
>
Can you get stacks please?
Use -g
--
Craig Rin
reasons test_decoding isn't suitable as the base
for a replication solution. It has "test" in its name for a reason.
Your replication model, whatever it is, is broken, since it's not handling
special cases like unchanged TOASTed values in UPDATEs. This is a bug in
your replication tool.
--
have some issue if left
> un-chained? since at other side there are inactive replication identifier.
>
No, that's harmless.
However, if there's still an "other side" at all, you presumably have
broken replication.
--
Craig Ringer http://www.2ndQuadrant.co
est xmin is far in the past
>
Do you have any idle/old replication slots, perhaps from failed node joins
or abandoned nodes not properly parted?
SELECT *
FROM pg_replication_slots;
Also check
SELECT oid,*
FROM pg_database;
--
Craig Ringer http://www.2ndQuadrant.com/
Postgr
se (in this central cluster there are hundreds wal sender), what is
> the limit number of groups?
>
It's not a use case I've paid much attention to. I expect it'll be limited
by performance and memory, rather than have any firm limit.
Maybe you should look into pglogical. This seems like
On 7 September 2017 at 21:16, milist ujang <ujang.mil...@gmail.com> wrote:
> Hi Craig,
>
> On Wed, Sep 6, 2017 at 4:07 PM, Craig Ringer <cr...@2ndquadrant.com>
> wrote:
>
>>
>> You could drop and re-create the replication slot, I guess. But your
>> n
On 6 September 2017 at 08:47, milist ujang <ujang.mil...@gmail.com> wrote:
> Hi Craig
>
> On Wed, Sep 6, 2017 at 7:21 AM, Craig Ringer <cr...@2ndquadrant.com>
> wrote:
>>
>>
>> BDR can, see bdr.skip_changes_upto .
>>
>> Unluckily my bdr is 0
y diverged data.
Don't go in and randomly delete things in the postgres data directory, or
things will break.
The BDR manual warns of the importance of disk space monitoring...
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ey somehow related to the value
>max_wal_senders as well), with respect to, say, the max number of nodes
> intended to support?
>
>
I think that's covered in the docs, but it's safe to err fairly high. The
cost of extra slots is minimal.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
nd: IDENTIFY_SYSTEM
>
> 2017-07-12 10:37:46 PDT [24944:bdr
> (6408408103171110238,1,24713,):receive:::1(33884)]LOCATION:
> exec_replication_command, walsender.c:1309
>
> 2017-07-12 10:37:46 PDT [24944:bdr
> (6408408103171110238,1,24713,):receive:::1(33884)]DEBUG:
> 08003: unexpe
sful.
>
>
>
> I was under the impression that there is no need to perform manual cleanup
> before a removed node (with database dropped and recreated) rejoining a BDR
> group.
>
BDR1 requires that you manually remove the bdr.bdr_nodes entry if you
intend to re-use the
uld need to sync back up.
Monitoring is important.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.p
some other way, or not
> statically determined?
Each node replicates to all other nodes in an undefined order
determined by network timing etc.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-gener
ream, but it
might be a bit fiddly and complex for your needs.
Ideally we'd be able to fire triggers in BDR, but that's not
implemented or on the current roadmap and there's no funded work on it
at this point. There's some work to support it in pglogical though.
--
Craig Ringer
See also https://github.com/2ndQuadrant/bdr/issues/233
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Increase wal_sender_timeout to resolve the issue.
I've been investigating just this issue recently. See
https://www.postgresql.org/message-id/camsr+ye2dsfhvr7iev1gspzihitwx-pmkd9qalegctya+sd...@mail.gmail.com
.
It would be very useful to me to know more about the transaction that
caused this
the apply workers.
Right now bdr.bdr_connections_changed() doesn't know to check for a
changed DSN. I'd welcome a patch to address that, since I probably
won't have time to get to it soon.
We should have a bdr.bdr_connection_set_dsn(...) function, really.
Again, a patch would be welcomed.
--
Craig Ringe
But
for DDL that alters tables it's necessary to block concurrent DML.
BTW, now that it's clear in-core logical replication is going in
another direction there's now a bdr-l...@2ndquadrant.com mailing list;
see https://groups.google.com/a/2ndquadrant.com/forum/#!forum/bdr-list
.
--
Craig Ringe
t; DROP;
>
> INSERT INTO _words
> SELECT
> out_word AS word,
> max(out_score) AS score
> FROM check_words(in_uid, in_gid, in_tiles)
> GROUP BY word, gid;
>
>
Or use CREATE TABLE ... AS SELECT ...
That's
base
creation/drop, user creation/drop, etc, then it might make sense to extend
BDR or its successor to do this. But not at the moment.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
risons 9.4+). It doesn't support multimaster or DDL replication
like BDR does, though.
You can also look into Londiste and Slony-I.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
seems vague since BDR is a concept for which many
> implementations exist.
>
I think they're specifically referring to 2ndQ's BDR project here, rather
than bi-directional logical replication general.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
e
anything. What are you going to do about it?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
s.
I'd go further than that and say I can't see how something like this could
possibly work with physical (block based) replication. It's total
hand-waving.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
.
Hopefully this is the sort of thing we can move toward with built-in
logical replication in coming releases.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
d just using
'text' and adding a CHECK constraint on length. That's what I do most
places, not just BDR.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
and usually require changes.
Changing an expected error code will be the least of your worries.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
we could spawn a
> process per database and replicate.
> Not to mention we should be able, if necessary, to exclude one or more
> tables from the replication.
>
That should all be pretty simple with what's already there and supported in
BDR using replication sets.
--
Craig Ringer
On 14 April 2016 at 17:14, konstantin knizhnik <k.knizh...@postgrespro.ru>
wrote:
>
> On Apr 14, 2016, at 8:41 AM, Craig Ringer wrote:
>
> On 1 April 2016 at 19:50, Konstantin Knizhnik <k.knizh...@postgrespro.ru>
> wrote:
>
> Right now the main problem is paralle
<- [DB-4]
so each DB is written from only one node at a time, but both nodes have
writeable DBs. Right?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
too.
> There are also some minor technical issues which lead us to making few
> changes in pglogical code but we tried to do our best to keep original
> versions unchanged, so we can switch to public version in future.
>
Details?
Now is exactly the time to address those points.
--
mal replication. Look into repmgr,
pgbarman, etc. Read the manual on replication, backup and failover. Do
_not_ use shared storage.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
in more detail?
In general, with PostgreSQL "shared storage" is a shortcut to "massive
database corruption" unless you have extremely careful fencing and STONITH.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
t you will need to drop and re-create the database if you need to
attempt setup again.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ted and why it works the way it does.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
slot name against the bdr local node
identity for the parted node (see the bdr docs for relevant functions to
get node identity).
BDR makes a best-effort attempt at dropping slots when parting a node but
there are known race conditions. We really need a two-phase part, where we
first agree to part and *then* actually remove the node, but that's not yet
implemented.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ins to retry the whole transaction.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
database (a tool
> to back up all the relevant data was just finished recently and was
> not set up for this system yet).
>
Read and act on https://wiki.postgresql.org/wiki/Corruption immediately.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ort5600_replica_local_dsn = 'dbname={DevDBName}
> user=postgres port=5601'
> # (END) BDR connection settings for node 2, port 5601
>
The above is not used in BDR 0.9.x. Configuration is done at the SQL level.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
general>
Yup. Deparse bug.
Do you know what the original statement was?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
plicated data is treated equally.
There's no concept of replication priority, nor am I sure how we could
implement such a thing. Data is either replicated or not replicated.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 28 January 2016 at 21:16, Kaushal Shriyan <kaushalshri...@gmail.com>
wrote:
>
>
> On Thu, Jan 28, 2016 at 6:32 PM, Craig Ringer <cr...@2ndquadrant.com>
> wrote:
>
>> On 28 January 2016 at 19:16, Kaushal Shriyan <kaushalshri...@gmail.com>
>> wrote:
&
one server and copies it to another. One way. (By the
way, I strongly advise you to now use pglogical instead of UDR).
BDR:
A <==> B
UDR/pglogical:
A ==> B
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
g for sequences patch, and/or failover slots
would be valuable since they are all going to be important for BDR on 9.6.
If you want to use it please help make it happen.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
you run bdr_init_copy again to finish
bringup, resetting the sysid to the new value and finishing setup. There's
nothing like that now though.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
parately taken snapshots is hard to get right and could lead
to subtle data problems if you get it wrong.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 15 January 2016 at 03:41, Nikhil <nikhilsme...@gmail.com> wrote:
>
> pg_ctl: another server might be running; trying to start server anyway
>
>
It looks like you may have run bdr_init_copy on a non-empty data directory
containing an existing server.
--
Craig Ringer
rom being perfect as the node may fail right after
> this.
>
Correct, but it's still useful to do.
I'd check to see all nodes are connected in pg_stat_replication then I'd
issue the DDL with a statement_timeout set.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
P-JOIN>?
> Just want to confirm what the best practice is as I haven't seen anything
> in the documentation about this.
>
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
e the answer you hoped for, but at least there's
improvement on the horizon.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ull READ COMMITTED
semantics across nodes. This comes with big benefits in partition
tolerance, performance and latency tolerance, but it means you can't point
an existing app at more than one node and expect it to work properly.
The documentation tries over and over to emphasise this. Can you sugge
ance hit, the upstream stopping when the downstream isn't reachable,
etc.
Personally I don't think it's a good idea to try to combine BDR and
synchronous replication. There are too many pitfalls, especially around the
1-synchronous-replica limitation. It'll be better if/when core gets support
for n-safe synchro
that point from a clean initial state.
If I had to guess right now I'd say that the host pg3 isn't actually the
node node3 that you are connected to when you're joining the node, i.e. the
error message is correctly telling you that you've given the wrong external
DSN.
--
Craig Ringer
ect * from bdr.bdr_nodes;
select * from bdr.bdr_connections;
on the new node you're trying to join?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
'll skip 9.5 entirely and deliver an
improved BDR on top of 9.6 down the track, but that's not something that'll
be happening until 9.6 is much closer to ready.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
I really couldn't say with the available information.
Can you set provide a step-by-step process by which you set up these nodes?
​
Are you adding more than one node at once?
BDR isn't currently smart enough to handle that. Make sure to wait until
one node is fully synced up before adding another.
​
​If you're not sure what's going on on a node, look at its logs.
The background worker API and PostgreSQL's lack of autonomous transactions
makes it quite challenging for BDR workers to capture logs and expose them
to users at the SQL level. So always, if in doubt, examine the log files.
at that it can't be a drop-in replacement for a
failed node due to the timeline increment. The data is there, but it won't
participate in replication. See the steps outlined in my prior mail for
details.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
tent on all nodes or data will diverge. I do not recommend doing this.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
's replication sets, and restore them.
I'd really like to bring together a more complete picture here, but the
development time currently available has to focus on robustness work and on
progress toward 9.6. As always, contribution would be greatly valued,
whether in terms of docs or code.
--
Cr
's an
oversight in those checks. If you're able to reproduce this state I'd like
to hear details on how.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ing version of bdr: 0.9.2.0
Please update to 0.9.3, which fixes this issue, per
https://github.com/2ndQuadrant/bdr/issues/126
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-
6211167104388615363,1,17163,): perdb"
This is a bug fixed in 0.9.3.
https://github.com/2ndQuadrant/bdr/issues/126
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql
the approach used just isn't sufficient to handle FK relationships,
and that the current test suite doesn't cover this.
I'm going to write a test to confirm what I think is going on, then follow up.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
What's the *exact* BDR version?
When you say you "attempted to" - what was the outcome? Presumably an
ERROR from the TRUNCATE, right? That would roll back the transaction,
and in the process abort the DDL lock acquisition attempt.
Are you sure replication was working normally prior to this
docs appropriately.
https://github.com/2ndQuadrant/bdr/issues/133
The identifiers aren't currently dropped during node part, which
should be changed. It hasn't come up to date because frequent node
addition and removal is something to be avoided, and because most
deployments configure room for
BDR is currently memory-limited for extremely large transactions. At a
guess, I'd say one of your big tables is large enough that the logical
decoding facility BDR uses can't keep track of the transaction
properly.
There's no hard limit, it depends on details of the transaction and a
number of
6197393155020108291_1_48609__ | bdr| logical | 19685 |
> deliver | t | | 2280 | 0/28EA5E0
>
> How can I get rid of the stale node recovery on startup?
Can you show the output of
select * from pg_replication_identifiers;
please? On all nodes. Also pg_catalog.pg
han connections entries and those
associated with terminated nodes are ignored.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes t
the memory of
> the bdrdemo database somewhere.
Sort-of. What happens in your example is that when you part the nodes,
they're separated and stop communicating. So your second part command
never reaches the remaining node. That's expected and normal, but we
should issue an error when it's
I fill a bug report?
Please.
It's clearly a bug and will need to be addressed in the next point release.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ckages are also produced. We're a little behind at the moment and
haven't got 0.9.2 packages out. I'll be pushing 0.9.3 soon and will
produce 0.9.3 packages for Debian/Ubuntu as well as for
Fedora/RHEL/CentOS.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development
with latency tolerance and
partition tolerance is needed, yes, it could make a lot of sense.
You could use UUID keys or use normal sequences with different offsets
on the nodes. UUID will probably be easier to manage.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Devel
On 7 September 2015 at 20:34, Ray Stell <ste...@vt.edu> wrote:
>
>
> On 9/6/15 10:55 PM, Craig Ringer wrote:
>>
>> On 4 September 2015 at 21:46, Ray Stell <ste...@vt.edu> wrote:
>>>>>>
>>>>>> FATAL: role "pos
> $ git rev-parse --short HEAD
> 6a60690
>
> $ git branch
> * bdr-pg/REL9_4_STABLE
OK, that's PostgreSQL. What about the BDR extension its self?
SELECT bdr.bdr_version() will show you if you're starting up OK,
otherwise again the git rev please.
--
Craig Ringer
as the default RADIUS identifier, but I
fail to see how those could get passed as the login role identifier.
Are you running it under a unix user named "postgresql", by any chance?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, T
workaround?
Keep it simple. Use streaming replication and a hot standby.
> For "traditional" (non BDR) serial, there is a way to set into configuration
> what will be START and INCREMENT of all sequences?
No.
> Or each serial sequence must be individually ALTERed for each serial c
via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
o/bdr-plugin-source/
> PATH=/path/to/install:"$PATH" ./configure
> make -j4 -s all
Thanks, now fixed in the devel tree.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general ma
On 2 September 2015 at 20:40, Andres Freund <and...@anarazel.de> wrote:
> On 2015-09-02 20:27:40 +0800, Craig Ringer wrote:
>> The reason for this is that BDR replicates at a database level, but
>> CREATE SERVER and CREATE USER MAPPING are global, affecting all
>> databa
ng more of
the underlying functionality into PostgreSQL 9.6 and streamlining the
user experience.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
ase.
> (maybe one could create the FDW before configuring replication)
No.
It's possible to override the filter using documented settings, but I
don't advise doing so unless you're extremely sure you need this, and
understand exactly what you're getting into. If you break it, you get
to ke
unately,
have bdr_node_join wait until the join completes, because it's
necessary to co-ordinate with background workers, commit multiple
transactions, etc.
It's not clear from your description what you mean by "on an existing
database". Details?
--
Craig Ringer ht
that has been removed.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
simple
single-master replication will do just as well.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
.
Rather than starting with the solution (horizontal partitioning,
sharding) try starting with the problem and requirements, then looking
for solutions from there.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql
BDR is not particularly suitable
for your use case at this time.
We're looking at adding sharding down the track, but it's quite a way
down the track because there's a fair bit of work on making sure the
core functionality is rock solid and easy to manage.
--
Craig Ringer http
no cross-node
querying. So in practice it's no benefit over a bunch of standalone
databases.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
tool for the job.
Is it a good tool
or is there something better for the same use case that repmgr fulfills.
It's moderately easy to just do it by hand if you don't want to use
repmgr. I haven't looked for alternative tools for this use case.
--
Craig Ringer http://www
to remove 'bdr' from
'shared_preload_libraries'.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
://github.com/2ndQuadrant/bdr/issues/88
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
considerable time and hassle.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
-attach a node that you asked
about, doing so can't be done without accumulating lots of upstream
WAL. It'd be effectively identical to just shutting down the node then
starting it up again - with all the same costs and downsides.
--
Craig Ringer http://www.2ndQuadrant.com
you want to detach a node and keep using it as
a standalone DB?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
, join with bdr.bdr_group_join, remove
with bdr.bdr_part_by_node_names .
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
1 - 100 of 1783 matches
Mail list logo
