To the wonderful BDR folks,
I have a 5 node pg+bdr cluster that I've spun up. I have verified that each
node can connect via psql to each other node. I am having an issue creating
the bdr group and having the nodes join each other.
The steps I am taking are as follows (I used pg compiled using
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,) with state=i in remote bdr.bdr_nodes
d= p=504 a=HINT:
Also, what is the proper way to locate and remove these replication slots
as mentioned in this log?
On Mon, May 11, 2015 at 11:36 PM, Wayne E. Seguin wayneeseg...@gmail.com
wrote:
Also,
Is there a way to remove these things from the init target node easier?
d= p=504 a=ERROR: 55000:
On 2015-05-12 06:06, Craig Ringer wrote:
On 11 May 2015 at 21:10, Peter Mogensen a...@one.com wrote:
So ... I can easily get the current txid of the SELECT transaction by
calling txid_current().
Note that by doing so, you force txid allocation for a read-only query that
might otherwise
On 12 May 2015 at 14:36, Wayne E. Seguin wayneeseg...@gmail.com 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
On 12 May 2015 at 14:33, Wayne E. Seguin wayneeseg...@gmail.com wrote:
7. on nodes 1-4 I am doing (adjusted for the nodes IP):
SELECT bdr.bdr_group_join(
local_node_name := 'pgbdr1',
node_external_dsn := 'host=10.244.2.6 port=5432 user=postgres
dbname=pgbdr',
join_using_dsn
On Tue, May 12, 2015 at 04:07:52PM +0800, Anil Menon wrote:
Thank you very much - looks like I will have to prefix all cols.
You should anyway.
Queries with unaliased columns make it impossible to analyze without
in-depth knowledge of the database.
Consider:
select c1, c2, c3, c4, c5
from t1
On Wed, May 6, 2015 at 7:24 PM Jeff Janes jeff.ja...@gmail.com wrote:
I've booked-marked these but haven't really looked into them to any
extent. It would be awesome if you put the SQL one somewhere on
http://wiki.postgresql.org. That way it is easier to find, and anyone
who finds it can
Melvin Davidson wrote:
Can anyone tell me why there is no relcreated column in pg_class to track
the creation date of an object?
It seems to me it would make sense to have one as it would facilitate
auditing of when objects are created. In addition, it would also facilitate
the dropping of
Hello Steve,
Great monitoring query (https://gist.github.com/skehlet/36aad599171b25826e82).
I suggest modifying the value autovacuum_freeze_table_age to
LEAST(autovacuum_freeze_table_age,(0.95*autovacuum_freeze_max_age))
AS autovacuum_freeze_table_age since PostgreSQL implicitly
limits
Can anyone tell me why there is no relcreated column in pg_class to track
the creation date of an object?
It seems to me it would make sense to have one as it would facilitate
auditing of when objects are created. In addition, it would also facilitate
the dropping of objects that have exceeded a
I thank everyone for their feedback regarding the omission of object
creation date from the catalog.
I do respect the various reasons for not including it, but I feel it is my
duty to draw out this issue a bit longer.
I would like to counter the argument that a restore from a dump will
override
On 12 May 2015 at 22:21, Wayne E. Seguin wayneeseg...@gmail.com 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:
Yep.
Still created once - instantiated repeated times, but created once. Try
federated metadata records only one original creation date which is an
explicit attribute of a record. Last copied, updated, edited are different.
Creation date can be when first entered into a spreadsheet, or
*awesome*, the question was for my own curiosity so thanks for this!
On Tue, May 12, 2015 at 18:27 Craig Ringer cr...@2ndquadrant.com wrote:
On 12 May 2015 at 22:21, Wayne E. Seguin wayneeseg...@gmail.com wrote:
Craig,
It's alive!!!
One more question on this thread, where can I find the
On 13 May 2015 at 09:29, Wayne E. Seguin wayneeseg...@gmail.com 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
On 05/12/2015 06:33 PM, Melvin Davidson wrote:
I thank everyone for their feedback regarding the omission of object
creation date from the catalog.
I do respect the various reasons for not including it, but I feel it is
my duty to draw out this issue a bit longer.
I would like to counter the
On 05/12/2015 12:51 PM, Melvin Davidson wrote:
Can anyone tell me why there is no relcreated column in pg_class to
track the creation date of an object?
So what date would it track?:
1) The date in the original database?
2) The date the table was restored to another database cluster?
3) The
On 05/12/2015 12:51 PM, Melvin Davidson wrote:
Can anyone tell me why there is no relcreated column in pg_class to
track the creation date of an object?
Meant to add to my previous post, back before I 'discovered' version
control I use to put the creation date in the table COMMENT:
Adrian,
You are over thinking this. An object is only created once! That is what
I meant by relcreatedate. If it is dropped, then it is deleted from the
catalogs. If it is modified, then it does NOT affect the creation date.
Everything else is superfluous.
It is also not unusual for tables to
Melvin Davidson melvin6...@gmail.com writes:
You are over thinking this. An object is only created once!
Yeah? Would you expect that pg_dump followed by pg_restore would preserve
the original creation date? What about pg_upgrade?
This has come up many times before, and we've always decided
On 05/12/2015 03:44 PM, Melvin Davidson wrote:
Adrian,
You are over thinking this. An object is only created once! That is
what I meant by relcreatedate. If it is dropped, then it is deleted from
the catalogs. If it is modified, then it does NOT affect the creation
date. Everything else is
Craig,
It's alive!!!
One more question on this thread, where can I find the meanings of
node_status in the documentation?
pgbdr=# SELECT * FROM bdr.bdr_nodes;
node_sysid | node_timeline | node_dboid | node_status | node_name
|node_local_dsn
Craig,
I was starting the first node then letting all of the other nodes join as
quick as they could which clearly won't work. It also explains why it
worked when I did it manually, I can only do it sequentially myself ;) I
had suspected a race condition and it seems I was in the right area :)
On Tue, May 12, 2015 at 6:33 PM, Melvin Davidson melvin6...@gmail.com
wrote:
I thank everyone for their feedback regarding the omission of object
creation date from the catalog.
I do respect the various reasons for not including it, but I feel it is my
duty to draw out this issue a bit
Craig, thank you so much for the quick response!
Adding these cleanup functions sounds wonderful, thank you for looking into
that.
One question, why template0 vs template1 ? (My guess is because you want it
to be devoid of pretty much everything?)
On Tue, May 12, 2015 at 1:31 AM, Craig Ringer
Thank you very much - looks like I will have to prefix all cols.
Regards
AK
On Tue, May 12, 2015 at 3:05 AM, Victor Yegorov vyego...@gmail.com wrote:
2015-05-11 19:26 GMT+03:00 Anil Menon gakme...@gmail.com:
manualscan= select count(*) From public.msgtxt where msgid in (select
msgid From
27 matches
Mail list logo
