-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no REPLICA IDENTITY error #537
Comments
Can you double-check that all child tables have the primary key created? If you add the primary key to the template table after you create the partition set, it does not go back and create that primary key on any existing children, only new ones. |
It is there, premake was only 1 warehouse=> \d+ public.audit_log_p2025 I found this website regarding this specific error with 3 solutions which is to : https://mydbanotebook.org/post/replication-key/
I appreciate any suggestions as well from you. |
Any chance you could share either the publication/subscription commands you're using to create the logical set or, if it's already set up, the configuration settings for it? Trying to set this up the same way that you are so I can try to recreate the situation and see what the problem is. Also, what version of PostgreSQL are you running? |
Replication has been set up awhile back, in postgresql.conf wal_level=replica, asynchronous. Basic set up is the table on the OLTP side is NOT partitioned, but the replicated table in the warehouse is partitioned. DB is on PG14 Publisher/Subscriber Set-up: SCHEMA=generic_schema CREATE PUBLICATION ${SCHEMA}_pub ALTER PUBLICATION ${SCHEMA}_pub OWNER TO replication; database_name=> \dRp+ (2) Create subscription on Subscriber. SCHEMA=schema_name (3) Create tables on subscriber using pg_dump
SCHEMA=schema_name ALTER PUBLICATION ${SCHEMA}_pub (4) Alter subscription on subscriber database. SCHEMA=schema_name (5) Apply post-data section via pg_restore |
So, I'm not able to get the same error that you're getting. I'm able to reproduce a similar one, but only if the published table is missing the primary key. And reading back on your error again, it does seem to indicate something similar. Do the tables on the publisher side have primary/unique keys? SUBSCRIBER:
PUBLISHER:
SUBSCRIBER:
PUBLISHER:
SUBSCRIBER:
So you can see the setup worked, but I got an error if I tried to delete anything on the publication side. However, when I add a primary key there, then it works ok
However, this brings up another issue that I think you will have as well. Inserts seem to replicate ok, but deletes do not. Running select again, you can see they're still there
And trying to reinsert them again on the publisher works, but if you look in the subscriber logs, it's throwing a conflict error
SUBSCRIBER logs:
Not quite sure how to fix this and not sure if it's a bug or not. I'm actually surprised the inserts even work. My understanding is that logical pub/sub replication required fully matching schemas on both sides for the intended tables. If you set this logical replication up with a matching partition set on the publication side, I imagine this would work fine. My suggestion would be to make matching partition sets on both the publisher and subscriber. However, you can set the retention on the publisher side to be lower so you don't have to keep quite as much data around there. |
Thank you for taking the time and effort. On the publisher end, there is definitely a primary key(id). The schema is public. I'll have to re-read your results as a second reading (or multiple) will shed some more light. Thanks again for your time. |
Hello. I neglected to tell you an important replication setting. Any chance you can test replication on your end? wal_level=logical on OLTP is what is used for the logical extraction. |
This doesn't make any difference in this case. That controls the output of the WAL stream on the relevant system. |
When you created the table in the subscriber, do you have to start with a fresh table (in which you did) or can I use 'LIKE' [the original table inheritance table] ? CREATE TABLE IF NOT EXISTS public.audit_log_native (LIKE public.audit_log) public.audit_log is set up as table Inheritance and I'm migrating to native. I would not think it would matter but I'm not 100% sure. |
I don't see why you couldn't use a LIKE clause. The result of a table made like that is still a normal table. It's just copying the schema from the original table. |
We have tested twice and everything works well in sandbox, we are still troubleshooting why the error shows up post- migration in prod (we've since rollback due to it). Separate question, do you have documentation on migrating OLTP from declarative/table inheritance to native and using publish_via_partition_root=true to replicate to the warehoue? |
I don't have anything specific for that, no. |
Hi. Question, I have a table that has a composite primary key that includes the partition key. I created a native partitioned table and also added the composite primary key in the parent and it worked, so I did not need a template table. I also used create_parent and it added a template table as described in pg_partman.md doc. Since I don't need the template table, does it hurt to UPDATE part_config to point the p_template to the parent? Or could I delete the template table? Just wondering. |
I don't think I have things fully tested in 4.x without having the template table at least existing there, even if it doesn't use it. Version 5.x actually makes it fully optional, so I'd recommend just leaving it there for now until that new version is out. |
Hi. FYI, I took your advise in above post and it's working well. Different question. I'm migrating another table to native but the partition key is an integer (currently, we have an internal function that creates the monthly child tables like so: finance_p202301, for Jan, etc..) but we'd rather use pg_partman for maintenance. Could we use LIST or RANGE partitioning but how do we configure pg_partman? Thanks in advance. |
The only method pg_partman supports with an integer for the column but time-based is epoch partitioning. See the flags in the functions related to that for how to do that. If your integer column is epoch based (seconds, milliseconds, or nanoseconds), you could convert it. If it's something else, it does not at this time. Also, it only supports RANGE at this time. And for future reference, please make a new entry in Discussions if you just have a question instead of replying to existing issues. Thank you! |
Hi, will do. Is it possible to keep this ticket open? We are still testing the original problem, we should know the results next week and this ticket can be closed. I've appreciated all your input, and thank you very much. |
Sure it can be left open |
Hi. We found the root-cause/bug: "logical replication's checking of replica identity when the target table is partitioned". The fix is in v14.5 but the Warehouse is currently at PostgreSQL 14.4 (Ubuntu 14.4-1.pgdg20.04+1). We will proceed after we've upgraded to 14.8. |
Oh wow! Thanks for letting me know on that one. |
Hello. This might be a duplicate issue, but I'd like to post it. Today, I migrated a partitioned table from inheritance to native, the set up is this: the table in OLTP is NOT partitioned, it is replicated to the warehouse where the table is partitioned. I added a non-partitioned primary key in a template table, the control is a column_date, the child tables appear to be inheriting it. After the migration, error logs shows the following:
"the table "logical replication target relation ""public.table_name"" has neither REPLICA IDENTITY index nor PRIMARY KEY and published relation does not have REPLICA IDENTITY FULL"
Is there a workaround? Thank you in advance.
The text was updated successfully, but these errors were encountered: