I had a server set up as a subscriber to our production server using postgreSQLs new logical replication feature. It seemed to be working well, however yesterday I needed to install the postgresql10-contrib10.4-1 package.
Now, for some reason the subscription is broken and errors out when I try to resubscribe with the following error message:
ERROR: could not create replication slot "subrep1": ERROR: could not load library "/usr/pgsql-10/lib/pgoutput.so": /usr/pgsql-10/lib/pgoutput.so: undefined symbol: is_publishable_relation
SQL state: XX000
First off, is this an issue with the publisher or the subscriber? The subscriber is pg 10.4 and the publisher is pg 10.2.
Any idea what is going on?
Please check publishers binaries. Might be the case when binaries were updated but service wasn't restarted
Related
When running dbt deps, I get back this error message:
Running with dbt=0.17.0
Error sending message, disabling tracking
Encountered an error:
Unable to connect to registry hub
What's happening here, and how can I work around it?
First of all, it's worth understanding what's going on here. It looks like you're trying to install a package from the dbt hub site (hub.getdbt.com) — if you open up your packages.yml file, you'll find something like this:
packages:
- hub: package-owner/package-name
version: 0.1.0
When you run dbt deps (at a high level):
dbt sends a request to hub.getdbt.com
From hub.getdbt.com, a request is sent to GitHub to download the package.
The package is copied into your project
This error occurs if dbt cannot connect to the hub site after sending a network request repeatedly. First off, we recommend you retry the dbt deps command — sometimes it's just a blip in connectivity that goes away on the second try.
If the error persists, there may be a few different reasons for it:
hub.getdbt.com might be unavailable. This happens but is relatively rare. You can navigate to hub.getdbt.com to check if this is the case. Also check the Netlify status page to see if there are any issues.
GitHub might be down — you can check this by going to the GitHub status page.
Finally, it may be that a firewall rule or antivirus software on your computer is rejecting the request. Talk to your IT team to find out if this is the case and whether that restriction can be removed.
We generally recommend using the hub syntax for packages, however if you need to work around it, you can consider using the git syntax (docs) or installing the package from a local directory (docs)
I am trying to set up replication between databases. I followed this tutorials:
https://learn.microsoft.com/en-us/sql/relational-databases/replication/tutorial-preparing-the-server-for-replication?view=sql-server-ver15
and after:
https://learn.microsoft.com/en-us/sql/relational-databases/replication/tutorial-replicating-data-between-continuously-connected-servers?view=sql-server-ver15
I went through first without any problems. Almost completed the second, but I stuck on step View the status of snapshot generation
When I try to strat snapshot agent, I get error:
Exception Message: An unspecified error had occurred in the native SQL Server connection component.
I tried to search on the internet MSSQL_REPL55012 (that's error code I get), but didn't succeed.
I tried to look in SQL Profiler, Jobs history, Replication Monitor, even ran failing job step from PowerShell, but couldn't get any more info on that.
What might be the issue? Anybody else stumbled upon that?
I am using:
SSMS version 15.0.18206.0
SQL Server engine 15.0.2000.5
I finally got it resolved. The issue was missing OLE DB driver.
I just downloaded latest driver. Then I got msoledbsqlr.rll driver in directory C:\Windows\SysWOW64\1033. Then I copied to C:\Program Files\Microsoft SQL Server\150\COM directory, so it can be found by snapshot.exe, which is executable run by Snapshot Agent.
Alternatvely, one can define environmental variable to point to C:\Windows\SysWOW64\1033 direcotry, so it will be found there.
Another issue might be that 64-bit SQL tries to use 32-bit drivers (msoledbsql.dll, msoledbsqlr.rll), but it wasn't issue in my case.
I know this question was answered but for future reference ,updating SQL server 2019 to latest CU solved for me.
I am trying to install Directus on a managed dedicated server and hit some issues. The error is:
Cannot install: "SQLSTATE[HY000]: General error: 1709 Index column size too large"
And this is displayed on the last step of the setup.
I followed this report: https://github.com/directus/api/issues/942 and spoke to our sysadmin.
Seems like it's a MariaDB 10.1 bug. This will be upgraded but not right away as the machines are managed. The best fix at the moment according to them would be to alter the row format (from COMPACT, to either COMPRESSED or DYNAMIC) of all of the tables in the database. This needs to be set to the individual tables in the db when they're created.
This is not an option however as the problem comes mid-install, and requires the tables to be dropped for the install to be re-attempted.
Is there something that could potentially be changed in the install script to set this row format on DB creation?
Perhaps this will help?
https://github.com/directus/api/issues/942
upgrading MariaDB to version 10.3 fixes this problem
upgrading MySQL to version 5.7 fixes this problem
Hope you are well.
I am trying to move a PostGIS data table from one server to another. I have installed postgresql on the target machine, configured it to allow sensible authentication (username/password). I have also used yum to install the postgis2_91 package (including debuginfo, devel, docs and utils).
When i initially tried to restore the sql dump to the target server i got a load of errors, i put this down to postgis not being installed as it was complaining about the "geometry" data type.
I believe i need to follow these instructions (from spatially enable database) http://trac.osgeo.org/postgis/wiki/UsersWikiPostGIS21CentOS6pgdg however, when i tried to run the command below I got an error saying "ERROR: must be owner of the spheroid", this is while I'm logged in as the "postgres" user which I believe has full permissions?
CREATE EXTENSION postgis;
Edit - I managed to fix this by completely removing postgres and postgis, then tried the procedure again and it worked. No idea why it didn't work but it is now resolved.
Any ideas?
Thanks
Paul
I'm trying to give pg_bulkload a try.
When I try to use the postgresql executable it provides, I get the following error:
/usr/local/src/pg_bulkload-3.0.1/bin> ./postgresql start -D /pg_data
server starting
/usr/local/src/pg_bulkload-3.0.1/bin>
FATAL: unrecognized configuration parameter "wal_level"
Google turned up an exact match for this error when someone was using a 9.0 version of psql to run a script on an instance of Postgres 8.4. I don't see how that could be related to my case--I have two versions of Postgres, but I'm sure I'm pointing at the right directory... any thoughts are very welcome.
As far as I can tell from the docs, PostgreSQL 9.x supports a configuration parameter named "wal_level", but version 8.4 does not. The postgresql.conf file for my 9.0.something server has that parameter; the one for my 8.4 server does not.
PostgreSQL 9.x server configuration
PostgreSQL 8.4 server configuration
Your error message suggests you're running version 8.4, but it's reading the configuration file for a 9.x server. Check your postgresql.conf and installation process. I'm thinking pg_bulkload might have "helped" you in ways you didn't anticipate.
I think that it can be a bit tricky to install pg_bulkload to the right place if you have more than one version of PostgreSQL installed on your machine. My first problem was that pg_bulkload (version 3.1.6) could not find pg_port library. I copied the library libpgport.a (a static library) to /usr/local/lib where it was found, but this approach is not recommended, because this is only a quick fix that doesn't work at the end. So, very soon there was another problem: "undefined reference to `pstrdup'". I reckon that in pg_bulkload there should be a possibility of pointing out where PostgreSQL is installed. Well, I changed Makefile of pg_bulkload in pg_bulkload-3.1.6/bin, namely line with PG_LIBS: PG_LIBS = $(libpq) -L/current location of your PostgreSQL/PostgreSQL/pgsql/lib -lpgport -lpgcommon. -lpgport has to be added before -lpgcommon. Last but not least, to compile and install pg_bulkload you shoud modify your PATH: PATH=/current location of your PostgreSQL/PostgreSQL/pgsql/bin:$PATH make USE_PGXS=1 [install]; This makes sure that your pg_bulkload will be added to the correct version of PostgreSQL (in my case 9.3). Enjoy!