catalog_xmin
> value. Should I expect the 'xmin' value to be null? Is there another way
> to monitor the replication latency when using BDR?
>
> Thanks,
> Steve Boyle
>
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
d on one node, I
> would expect the 'xmin' value not to be null but is.
>
> What is the best way to monitor replication latency when using Postgresql
> BDR?
>
> Regards,
>
> Bill
>
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
with an error.
If your apps aren't written that way then you clearly don't mind showing
errors to the user that much after all.
> Is there a mechanism a new node gets added on the fly ?
>
It's been added in the coming 0.9.0 release.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
in the pending 0.9.0 release. However,
all nodes are expected to be up and reachable when you add a new node. Node
addition won't complete until they are. Allowing node addition while one or
more peers are down is not on the current roadmap. If you have a dead node
you must remove it before add
e?
At this time I think you'd have to patch the BDR apply worker to do what
you wanted.
There are already a few areas where downstream filtering or apply hooks are
of interest, so this might be an area that can be enhanced in future.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
how and
when they upgrade. See http://yum.baseurl.org/wiki/Faq for more on version
pinning.
The release announcement for BDR 0.9.0 will have a lot more detail.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ey are run in.
Thanks for writing a clear and detailed report with errors, versions, and
command shown. It's much appreciated.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 25 March 2015 at 20:14, Peter Mogensen wrote:
>
>
> On 2015-03-25 12:32, Craig Ringer wrote:
>
>> On 25 March 2015 at 19:15, Peter Mogensen wrote:
>>
>> Say ... I have a table in a BDR replicated database with an "ON UPDATE"
>>> trigger.
eam commit's
LSN at the C level from the BDR apply worker during transaction replay,
though. The LSN provides strict ordering for a node.
I'd start by looking into whether commit timestamps can meet your needs.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
(Please reply-to-all to keep the thread on pgsql-general)
On 26 March 2015 at 18:32, Peter Mogensen wrote:
>
>
> On 2015-03-26 10:14, Craig Ringer wrote:
>
>> I see what you're getting at. You want to prevent stale data from being
>> reinsterted into a cache b
On 26 March 2015 at 19:08, Peter Mogensen wrote:
>
>
> On 2015-03-26 11:57, Craig Ringer wrote:
>
>> If that's the case then BDR shouldn't make any difference.
>>
>
> It does. Because now with BDR you can't compare txid_current() as saved on
> the
I'll make the docs more explicit about that.
> I need to be able run a query on node ‘B’ to determine if it node ‘B’ is
> behind. I am not sure the above query will work for that use case.
It won't, and you really can't.
--
Craig Ringer http://www.
ted.
>
Just make direct libpq connections to each node from the monitoring host.
You should generally be doing that anyway for your node health monitoring.
If you can't make inbound connections, do it on a push model, e.g. nsca-ng
and Icinga's passive mode. This is something that'
ion sets
before starting to add data to tables.
All this applies to 0.9.0 and is, of course, subject to change in future
releases, time and resources permitting.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
set, table sync when replication sets
are changed, etc.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 28 April 2015 at 05:38, Jim Nasby wrote:
> On 4/26/15 7:49 AM, Craig Ringer wrote:
>
>> There are also some improvements needed to the user interface - in
>> particular, providing a function interface for changing replication set
>> memberships for connections so the
On 29 April 2015 at 09:14, Jim Nasby wrote:
> On 4/27/15 7:54 PM, Craig Ringer wrote:
>
>> If 'default replication set' is the idea of "here's what tables
>> *should* be getting replicated regardless of whether that's
>> happening or
BDR is the perfect solution for our
> infrastructure's needs for backup and availability
>
You might want to consider BDR's single-master UDR mode too, or tools like
Londiste. Don't add multi-master unless you really need it. Significant
limitations are introduced around how and when you can do DDL, etc, when
doing multi-master BDR, per the manual.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
t. It's certainly not going to when
comparing between nodes, especially in an async system.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
to either support parallel join of multiple
nodes or identify and reject it.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 12 May 2015 at 14:36, Wayne E. Seguin wrote:
> Also,
>
> Is there a way to remove these things from the init target node easier?
>
> d= p=504 a=ERROR: 55000: previous init failed, manual cleanup is required
> d= p=504 a=DETAIL: Found bdr.bdr_nodes entry for bdr
> (6147869128174526660,1,16908
On 12 May 2015 at 22:21, Wayne E. Seguin wrote:
> Craig,
>
> It's alive!!!
>
> One more question on this thread, where can I find the meanings of
> node_status in the documentation?
>
node_status is really internal, but it's covered briefly in the docs:
http://bdr-project.org/docs/stable/catalo
On 13 May 2015 at 09:29, Wayne E. Seguin wrote:
> *awesome*, the question was for my own curiosity so thanks for this!
>
No worries.
I know it's trite, but for internal-ish detail like that the best reference
remains the source code. I'd like to think the sources are fairly sa
On 15 May 2015 at 04:26, Dennis wrote:
>
> What am I missing? How are the steps different from setting database
> replication?
>
>
Please show the log output from both nodes, and the contents of "SELECT *
FROM bdr.bdr_nodes" and "SELECT * FROM bdr.bdr_connectio
or this use case too. If you
don't need multi-master, don't use multi-master.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
derstand.
If you mean join and remove nodes, 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
the command filter off.
BEGIN;
SET LOCAL bdr.permit_unsafe_ddl_commands = true;
SET LOCAL bdr.skip_ddl_locking = true;
security label for 'bdr' on database bdr_testdb is '{"bdr": false}';
COMMIT;
Out of interest, why do you want to detach a node and keep using it as
a st
king control of the application.
Absolutely. The trouble is that all such things have trade-offs.
For example, with the ability to re-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
iscussion in one
place.
https://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 subscri
ime 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-general
des and bdr.bdr_connections, and remove the bdr security
label with:
SECURITY LABEL FOR bdr ON DATABASE thedb IS NULL;
then restart the DB. You may also wish to remove 'bdr' from
'shared_preload_libraries'.
--
Craig Ringer http://www.2ndQuadr
it?
2ndQuadrant maintains repmgr. I think it's a decent 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 look
oss-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 mak
me what would be the best approch for this.
>From your description it sounds like 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 makin
e optimisation. I can't know without a lot more info.
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 Deve
ple
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
een 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-general
r_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 http
e 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)
To make cha
ot use FDWs in a BDR-enabled database.
> (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
On 2 September 2015 at 20:40, Andres Freund 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
>> databases on a PostgreS
; 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 mailing list (pg
ling 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
CE and use it 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 Developmen
er).
Correct.
> Is there any 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
tition 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 Development, 24x7 Support, Tr
On 7 September 2015 at 20:34, Ray Stell wrote:
>
>
> On 9/6/15 10:55 PM, Craig Ringer wrote:
>>
>> On 4 September 2015 at 21:46, Ray Stell wrote:
>>>>>>
>>>>>> FATAL: role "postgresql" does not exist
>>>>>
>
> $ 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
inly on RHEL/CentOS/Fedora, but Debian/Ubuntu
packages 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
>>
>>> Is it a feature or a bug?
>>
>> I think it's an oversight. Replication sets were added later than the
>> TRUNCATE trigger, so the design for the latter does not consider the
>> former as far as I know.
>
> Ok. May I fill a bug report?
> Basically, how do I reset BDR completely? It seems to retain 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.
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 to your subscr
1_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_replication
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 oth
b.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 more slots than needed to
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 point,
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 Suppor
7163,): 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-general@postgresql.org)
To
.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-general@postgresql.or
he 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
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
s, but seem
to be ignoring that because it's not the solution you have already decided
you need for your problem.
I doubt anybody will implement this for you, especially since I don't think
it's really possible in PostgreSQL's block-based physical replication
architecture. So sa
t.
>
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
t 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
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
NTO _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 the SQL-standard spelling any
bles 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 Ringer
hanged() 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 Ringer
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 prob
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
#x27;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
tuple it isn't a last-update-wins resolution
anymore.
What you can do is define a custom conflict handler that always keeps the
remote tuple on one node and the local tuple on the other, based on
inspecting the local node id. You *must* make sure the resolution is
consistent on all node
store them temporarily, dump the tables that aren't in
the first node'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 alwa
er.
>>
>
It does, with the caveat 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
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.
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.
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?
rely 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
e?
Can you show the output of
select * 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
ial 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
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-s
hem. It does not preserve full 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
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
il 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
On 15 January 2016 at 03:41, Nikhil 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 http://www.2nd
have physical standbys of
pglogical/bdr nodes. It may be possible to backport this to 9.4bdr but I'm
not aware of any plans to do so and available time/resources are mainly
focused on driving 9.6/pglogical forward. Get in touch if you think this is
something you could use more urgently.
I re
rately 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
ce 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
sysid; *then* you make a
snapshot and restore it, then 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
ne 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
On 28 January 2016 at 21:16, Kaushal Shriyan
wrote:
>
>
> On Thu, Jan 28, 2016 at 6:32 PM, Craig Ringer
> wrote:
>
>> On 28 January 2016 at 19:16, Kaushal Shriyan
>> wrote:
>>
>>> Hi,
>>>
>>> Can somebody please help me und
ually.
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
N TABLE table1 TO user2 WITH GRANT OPTION
> <http://www.postgresql.org/mailpref/pgsql-general>
Yup. Deparse bug.
Do you know what the original statement was?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
me}node01port5600_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
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
ded by how many people are willing to simply ignore
errors and carry on with the transaction without even properly verifying
that the error was the exact one they expected though. Seriously bad
application development and it *will* bite them. The best, most correct
thing to do remains to retry the whol
gainst 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
ider and subscriber on BDR,
but we haven't put the test infrastructure together to validate that and
make it an officially supported configuration yet. It's certainly desired
and on the roadmap.
Using UDR with BDR doesn't work well; the issues we found there are part of
why pglog
reate the database if you need to
attempt setup again.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ith 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
1 - 100 of 1788 matches
Mail list logo
