r 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 list (pgsql-general@postgresq
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://www.postgresql.org/mailpref/pgsql-general
On 12 October 2017 at 11:03, Andres Freund wrote:
> On 2017-10-12 10:25:43 +0800, Craig Ringer wrote:
>> On 4 October 2017 at 00:21, milist ujang wrote:
>> > On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
>> >>
>> >>
>>
On 4 October 2017 at 00:21, milist ujang wrote:
> On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
>>
>>
>> Can you get stacks please?
>>
>> Use -g
>
>
> # Events: 2K cpu-clock
> #
> # Overhead Command
here 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 Ringer
x27;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.
--
Craig Ringer
On 15 September 2017 at 11:46, milist ujang wrote:
> Hi Craig,
>
> Thanks again for pointing to inactive replication slot.
> After inactive replication slot been dropped, the relfrozenxid now moving.
>
> I wonder if replication identifier will have some issue if left
>
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/
PostgreSQL Development, 24x7 Support, Training & Services
here 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 li
On 7 September 2017 at 21:16, milist ujang wrote:
> Hi Craig,
>
> On Wed, Sep 6, 2017 at 4:07 PM, Craig Ringer
> wrote:
>
>>
>> You could drop and re-create the replication slot, I guess. But your
>> nodes would be hopelessly out of sync and need manual resync (
On 6 September 2017 at 08:47, milist ujang wrote:
> Hi Craig
>
> On Wed, Sep 6, 2017 at 7:21 AM, Craig Ringer
> wrote:
>>
>>
>> BDR can, see bdr.skip_changes_upto .
>>
>> Unluckily my bdr is 0.9.3
>
>
>> But PostgreSQL's logical decod
ata.
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
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
-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: unexpected EOF on client connection
&g
> 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 same node name.
--
Craig Ringe
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
Regards,
Craig
Developer
Koordinates
+64 21 256 9488 <+64%2021%20256%209488> / koordinates.com / @koordinates
<https://twitter.com/koordinates>
s faster?
So far we have experimented with the following:
- checkpoint_timeout : 3600
- autovacuum: 0
- max_wal_size: 128 (2GB)
- synchronous_commit: off
What other things would you recommend to improve performance of this sort
of thing?
--
Regards,
Craig
Developer
Koordinates
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.postgresql.org/mailpref/pgsql-general
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-general mailing list (pg
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 Ring
,
Craig
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of John R Pierce
Sent: Tuesday, January 10, 2017 1:48 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Table Design for Many Updates
On 1/10/2017 1:42 PM, David G. Johnston wrote
Thanks for the insights. I don’t think we have any where clauses that would
filter on a column from the related table.
Craig
From: David G. Johnston [mailto:david.g.johns...@gmail.com]
Sent: Tuesday, January 10, 2017 1:42 PM
To: Craig Boucher
Cc: pgsql-general@postgresql.org
Subject
eing
updated at a time, will I reap the benefits?
Thanks,
Craig
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 prob
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
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
On Tue, Aug 23, 2016 at 1:07 PM, Igor Neyman wrote:
>
>
> *From:* pgsql-general-ow...@postgresql.org [mailto:pgsql-general-owner@
> postgresql.org] *On Behalf Of *Craig James
> *Sent:* Tuesday, August 23, 2016 4:00 PM
> *To:* pgsql-general@postgresql.org
> *Subject:*
other thing I can think of is a delete trigger on each of the
partition child tables. That would work, but it's a nuisance.
Thanks,
Craig
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
ng a department description as part of the
primary key in the department table and having it repeated in millions of rows.
Though I always look for ways to use natural keys where they work well.
Thanks,
Craig
-Original Message-
From: Kevin Grittner [mailto:kgri...@gmail.com]
Sent: Monday, Augu
Thanks Tom for the link.
It could actually be beneficial if we need to migrate a customer from one
database to another because wouldn't have to worry about pk constraint
violations.
Craig
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Monday, August 8, 2016 1:
my primary key
was (customer_id, work_session_id) or if (work_session_id, customer_id) will
be fine. Customer_id will be repeated quite a bit in the table but
work_session_id should be unique across the whole table.
Thanks,
Craig
From: David G. Johnston [mailto:david.g.johns
MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT unq_department_customerid_departmentname UNIQUE (customer_id,
department_name)
)
Thanks,
Craig
From: David G. Johnston [mailto:david.g.johns...@gmail.com]
Sent: Monday, August 8, 2016 11:33 AM
To: Craig Bou
the tables can be in the millions.
Thanks,
Craig
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
On 07/04/2016 11:01 AM, Daniel Verite wrote:
Craig Boyd wrote:
So to put it another way: is there a list that shows what options are
available during the connection event or as part of the connection string?
Yes, but it belongs to the chapter on libpq. The psql docpage merely points
wn
failures to connect using options on this page then I have to assume
that these are options that can be changed post login.
Thanks for everyone's help. This makes a bit more sense. :)
Sincerely,
Craig
On 07/03/2016 06:51 PM, Scott Marlowe wrote:
On Sun, Jul 3, 2016 at 5:15 PM, Melvin Davidson <mailto:melvin6...@gmail.com>> wrote:
On Sun, Jul 3, 2016 at 6:54 PM, Craig Boyd mailto:cr...@mysoftforge.com>> wrote:
Hello All,
I am something of a newbie and
On 07/03/2016 06:15 PM, Melvin Davidson wrote:
On Sun, Jul 3, 2016 at 6:54 PM, Craig Boyd <mailto:cr...@mysoftforge.com>> wrote:
Hello All,
I am something of a newbie and I am trying to understand how to
pass connection options using the psql client. My understandi
Hello All,
I am something of a newbie and I am trying to understand how to pass
connection options using the psql client. My understanding is that it
is possible to do this as part of the psql connection event.
I am on Mint and my PostgreSQL Server version = 9.3.13.
I am trying to connect to
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
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
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
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
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
rsonally I recommend 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
locking, or
pg_largeobject ... yeah. Apps require audit 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
ers, with coverage of
DDL replication, problems with full table rewrites, etc, you will have.
I think it would be reasonable for pglogical to offer the option of sending
a minimal table metadata message that simply says that it expects the
downstream to deal with the upstream attnos exactly as-is, either by having
them exactly the same or managing its own translations. In this case column
mapping etc can be omitted. Feel free to send a patch.
> Multimater really needs to map local or remote OIDs. We do not need to
> provide any attribute mapping and handle catalog invalidations.
>
For synchronous tightly-coupled multi-master with a GTM and GLM that
doesn't allow non-replicated DDL, yes, I agree.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
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 http://www.2n
On 14 April 2016 at 17:14, konstantin knizhnik
wrote:
>
> On Apr 14, 2016, at 8:41 AM, Craig Ringer wrote:
>
> On 1 April 2016 at 19:50, Konstantin Knizhnik
> wrote:
>
> Right now the main problem is parallel apply: we need to apply changes
>> concurrently to av
- [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
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.
--
Craig Ringer
On 31 March 2016 at 10:43, Slava Bendersky wrote:
> Hello Craig,
> The current setup is two server which run libvirt and for storage which
> run glusterfs (storage server feed two virtual servers). Right now is no
> fencing in place. Each of the nodes have one PostgreSQL vm with bd
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
reate the database if you need to
attempt setup again.
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
#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
.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
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
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
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,
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
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
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
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
> 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.
>>
>>> 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?
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
> $ 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
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
>>>>>
>
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
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
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
1 - 100 of 1925 matches
Mail list logo
