[HACKERS] Does pglogical support PG 9.4.5?
Hi all,
I am test pglogical on PG 9.4.5, but I am not successfully even if I
install the latest version "postgresql94-pglogical-1.0.1-2".
Is there any one running pglogical on PG 9.4.5 successfully?
I describe my operation step, please help me to trouble shooting?
provider node: 10.10.10.11
subscriber node: 10.10.10.103
Config pg_hba.conf on provider node:
hostall postgres0.0.0.0/0 trust
hostreplication postgres10.10.10.103/0 trust
Config pg_hba.conf on subscriber node:
hostall postgres0.0.0.0/0 trust
hostreplication postgres10.10.10.11/0 trust
Config the postgres.conf according to README
1. Create subscribe node:
Provider: 10.10.10.11
SELECT pglogical.create_node(node_name := 'subscriber_test_3',dsn :=
'hostaddr= 10.10.10.103 port=5509 dbname=testdb user=postgres');
create_node
-
2393536845
2. Create replication ser
select pglogical.create_replication_set('replicate_gis_data', true, true,
true, true);
create_replication_set
2904604760
3. Add table into replication set
select
pglogical.replication_set_add_table('replicate_gis_data','test_table',
true);
===Executing on subscriber node
Enable the network connection on:
enbale network connection and replication connection without password
1. Create provider:
SELECT pglogical.create_node(node_name := 'provider_test_2',dsn :=
'hostaddr= 10.10.10.11 port=5508 dbname=testdb user=postgres');
create_node
-
3082486013
2. Create subscription to provider noede, executing on subscribe node
select pglogical.create_subscription('replicate_gis_data_from_11',
'hostaddr= 10.10.10.11 port=5508 dbname=testdb
user=postgres',E'{"replicate_gis_data"}');
Error Message on subscriber node
===
< 2016-01-12 19:45:41.396 UTC >DEBUG: shmem_exit(1): 2 before_shmem_exit
callbacks to make
< 2016-01-12 19:45:41.396 UTC >DEBUG: shmem_exit(1): 6 on_shmem_exit
callbacks to make
< 2016-01-12 19:45:41.396 UTC >DEBUG: proc_exit(1): 2 callbacks to make
< 2016-01-12 19:45:41.396 UTC >DEBUG: exit(1)
< 2016-01-12 19:45:41.396 UTC >DEBUG: shmem_exit(-1): 0 before_shmem_exit
callbacks to make
< 2016-01-12 19:45:41.396 UTC >DEBUG: shmem_exit(-1): 0 on_shmem_exit
callbacks to make
< 2016-01-12 19:45:41.396 UTC >DEBUG: proc_exit(-1): 0 callbacks to make
< 2016-01-12 19:45:41.397 UTC >DEBUG: reaping dead processes
< 2016-01-12 19:45:41.397 UTC >LOG: worker process: pglogical apply
26429:2377587811 (PID 967) exited with exit code 1
< 2016-01-12 19:45:41.397 UTC >DEBUG: StartTransaction
< 2016-01-12 19:45:41.397 UTC >LOG: unregistering background worker
"pglogical apply 26429:2377587811"
< 2016-01-12 19:45:41.397 UTC >DEBUG: name: unnamed; blockState:
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
< 2016-01-12 19:45:41.397 UTC >LOG: registering background worker
"pglogical apply 26429:2377587811"
< 2016-01-12 19:45:41.397 UTC >LOG: starting background worker process
"pglogical apply 26429:2377587811"
< 2016-01-12 19:45:41.397 UTC >DEBUG: CommitTransaction
< 2016-01-12 19:45:41.397 UTC >DEBUG: name: unnamed; blockState:
STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
< 2016-01-12 19:45:41.397 UTC >DEBUG: find_in_dynamic_libpath: trying
"/usr/pgsql-9.4/lib/pglogical"
< 2016-01-12 19:45:41.397 UTC >DEBUG: find_in_dynamic_libpath: trying
"/usr/pgsql-9.4/lib/pglogical.so"
< 2016-01-12 19:45:41.397 UTC >DEBUG: InitPostgres
< 2016-01-12 19:45:41.397 UTC >DEBUG: my backend ID is 8
< 2016-01-12 19:45:41.397 UTC >DEBUG: StartTransaction
< 2016-01-12 19:45:41.397 UTC >DEBUG: name: unnamed; blockState:
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
< 2016-01-12 19:45:41.397 UTC >DEBUG: CommitTransaction
< 2016-01-12 19:45:41.397 UTC >DEBUG: name: unnamed; blockState:
STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
< 2016-01-12 19:45:41.397 UTC >DEBUG: StartTransaction
< 2016-01-12 19:45:41.398 UTC >DEBUG: name: unnamed; blockState:
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
< 2016-01-12 19:45:41.398 UTC >DEBUG: CommitTransaction
< 2016-01-12 19:45:41.398 UTC >DEBUG: name: unnamed; blockState:
STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
< 2016-01-12 19:45:41.398 UTC >DEBUG: StartTransaction
< 2016-01-12 19:45:41.398 UTC >DEBUG: name: unnamed; blockState:
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
< 2016-01-12 19:45:41.398 UTC >DEBUG: CommitTransaction
< 2016-01-12 19:45:41.398 UTC >DEBUG: name: unnamed; blockState:
STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
< 2016-01-12 19:45:41.398 UTC >ERROR: subscriber replicate_gis_data_from_11
initialization failed during nonrecoverable step (s)
Re: [HACKERS] pglogical - logical replication contrib module
Hi Steve Singer, I find the pglogical package has updated, I reinstall the new RPM package and test again. But I find the same error in subscription node after I run pglogical.create_subscription command: Error message: < 2016-01-26 12:23:59.642 UTC >LOG: worker process: pglogical apply 19828:2377587811 (PID 12299) exited with exit code 1 < 2016-01-26 12:23:59.642 UTC >LOG: unregistering background worker "pglogical apply 19828:2377587811" < 2016-01-26 12:23:59.642 UTC >LOG: registering background worker "pglogical apply 19828:2377587811" < 2016-01-26 12:23:59.642 UTC >LOG: starting background worker process "pglogical apply 19828:2377587811" < 2016-01-26 12:23:59.643 UTC >ERROR: subscriber replicate_gis_data_from_11 initialization failed during nonrecoverable step (s), please try the setup again I also find the provide node has error message: < 2016-01-26 04:16:51.173 UTC >LOG: exported logical decoding snapshot: "0003F483-1" with 0 transaction IDs < 2016-01-26 04:16:51.282 UTC >LOG: unexpected EOF on client connection with an open transaction < 2016-01-26 04:16:51.549 UTC >LOG: logical decoding found consistent point at 4F/8CD1A090 < 2016-01-26 04:16:51.549 UTC >DETAIL: There are no running transactions. < 2016-01-26 04:16:51.549 UTC >LOG: exported logical decoding snapshot: "0003F484-1" with 0 transaction IDs < 2016-01-26 04:16:51.675 UTC >LOG: unexpected EOF on client connection with an open transaction < 2016-01-26 04:16:51.968 UTC >LOG: logical decoding found consistent point at 4F/8CD1A0F8 < 2016-01-26 04:16:51.968 UTC >DETAIL: There are no running transactions. < 2016-01-26 04:16:51.968 UTC >LOG: exported logical decoding snapshot: "0003F485-1" with 0 transaction IDs < 2016-01-26 04:16:52.399 UTC >ERROR: schema "topology" already exists < 2016-01-26 04:16:52.436 UTC >LOG: unexpected EOF on client connection with an open transaction I test pglogical according to README document. Could you tell me what is wrong? Thanks, Leo -- View this message in context: http://postgresql.nabble.com/pglogical-logical-replication-contrib-module-tp5879755p5884242.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pglogical - logical replication contrib module
I also run into same problem and waiting for bug fix. please update if new patch has published. THX -- View this message in context: http://postgresql.nabble.com/pglogical-logical-replication-contrib-module-tp5879755p5882564.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] "pg_upgrade" cannot write to log file pg_upgrade_internal.log
I run "pg_upgrade -xx" fromPostgreSQL8.3 to PostgreSQL9.4.5 on window server 2008. It will show some wrong information: cannot write to log file pg_upgrade_internal.log Failure, exiting. It seems that the upgrade can be successful on window 7. It seems to be a permissions problem. I get some information about restricting privileges from source code, and I find the changes "Run pg_upgrade and pg_resetxlog with restricted privileges on Windows, so that they don't fail when run by an administrator (refer to http://www.postgresql.org/docs/9.4/static/release-9-4-2.html )" for release 9.4.2. Why did you do this? How can I solve this problem? I hope you can help me. Best Regards, Leo
[HACKERS] Tuple hint bits (INFOMASK) upon transaction abort
I am studying the postgresql kernel and the following question arose... I hope somebody out there can help me find the answers to my doubts. Scenario: Transaction T1 updates a given tuple -- xmax is set to T1 on that tuple ... later on, T1 aborts... we believe that in this circumstance HEAP_XMAX_INVALID should be set on the tuple to signal that the tuple was not actually "deleted" by T1 since this aborted. The question is: Where is HEAP_XMAX_INVALID set on the tuple? We have dag around the code and we have noticed (e.g., heap_update, lines 1963-19673) that when a transaction T2, waiting for T1 to release the lock on the tuple, gets woken up by T1 abort, checks whether T1 did commit and in the negative takes care of updating the tuple infomask. Does this mean that in case of T1 abort, nobody explicitly updates the infomask hint bits of the tuples "deleted" by T1? Otherwise, I guess it would not make any sense to have following transactions do this work. On the other hand, this seems to me not sufficient (unless I am missing something of course : ). What if there were no transactions waiting for a lock on a tuple "deleted" by T1? In this case nobody would set HEAP_XMAX_INVALID on T1 tuples? This would mess up things also for what concerns snapshot visibility related functions which do check infomask's HEAP_XMAX_INVALID to determine tuple visibility (i.e. to understand if the xmax transaction has committed or not). Summing up, HEAP_XMAX_INVALID is set by some functions explicitely called to handle the abort or this work is done only by following transactions subsequently accessing the tuple? Thanks a lot in advance! Letizia Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
[HACKERS] Rome university
Hi, We're a team from Rome University (Italy) and we are working on an hacking of PostgreSQL MVCC. The basic idea is to have multiple instances of a same user transaction concurrently executing against the DB in order to achieve fault tolerance. We do not want to bother you with the details of our idea, but of course we'd be delighted to
provide you additional information wheter you were interested or even just curious! We're writing to you since we're studying the current MVCC implementation and we're stuck with a doubt that's driving us crazy since a couple of weeks so we'd be extremely grateful to anybody who could enlighten us. Our amlethic question is: tqual.c, HeapTupleSatisfies* (Self,Now etc). Let's focus on HeapTupleSatisfiesItself for simplicity. The piece of code that's unclear is the following: 144: else if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tuple)))145: {146: if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid
*/147: return true;148: 149: if (tuple->t_infomask & HEAP_IS_LOCKED) /* not deleter */150: return true;151: 152: Assert(!(tuple->t_infomask & HEAP_XMAX_IS_MULTI));153: 154: /* deleting subtransaction aborted? */155:
if (TransactionIdDidAbort(HeapTupleHeaderGetXmax(tuple)))156: {157: tuple->t_infomask |= HEAP_XMAX_INVALID;158: SetBufferCommitInfoNeedsSave(buffer);159:
return true;160: }161: 162: Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tuple)));163: 164: return false;165: } and the doubt is the following: how is it possible that -line 144- Xmin is the current transaction ( i.e. it has created this tuple, it is holding an exclusive lock on it since it has not committed yet) and that -line 149- there is a different (?) transaction that is also locking the tuple
(HEAP_IS_LOCKED=(HEAP_XMAX_EXCL_LOCK||HEAP_XMAX_SHARED_LOCK) )? Unless we are missing something, this situation is possible exclusively in case the XMAX transaction is a subtransaction of XMIN, which can access the tuple despite the exclusive lock held by XMIN. This seems correct according to the comment in line 154, which refers to a "subtransaction". Are we understanding correctly what this code is doing and the related underlying MVCC mechanisms? Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
[HACKERS] serial type as foreign key referential integrity violation
Hi all,
Just briefly describe my problem.
I have two tables.
create table A(
a1 serial primary key,
a2 varchars(10)
);
create table B(
b1 integer primary key,
b2 Integer,
foreign key(b2) references a(a1)
)
insert into A values('123');
select a1 from A where a2='123'
>--
>a1
>--
>1
>--
insert into B values (1,1);
ERROR!! referential integrity violation - key referenced from B not found in A.
but in table A , if I change it the PK to integer, everything would be fine.
any idea?
thanks a lot!
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
