When I pull my database from heroku to localhost, I get this message :
▸ WARNING: Extensions in newly created target database differ from existing source database.
▸ Target extensions:
▸
▸ Source extensions:
▸ extname
▸ ----------
▸ plpgsql
▸ unaccent
▸ (2 rows)
On localhost I get this:
select * from pg_available_extensions;
name | default_version | installed_version | comment
--------------------+-----------------+-------------------+----------------------------------------------------------------------
unaccent | 1.1 | | text search dictionary that removes accents
(52 rows) #cut for brievity
BUT :
select * from pg_extension;
extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition
---------+----------+--------------+----------------+------------+-----------+--------------
plpgsql | 10 | 11 | f | 1.0 | |
(1 row)
And on heroku:
DATABASE=> select * from pg_extension;
extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition
----------+----------+--------------+----------------+------------+-----------+--------------
plpgsql | 10 | 11 | f | 1.0 | |
unaccent | 10 | 5147991 | t | 1.1 | |
(2 rows)
So I guess the question is how to activate unaccent locally. The other question is: why do I get this message on plpgsql?
Related
(note: I've also posted this as a github issue https://github.com/timescale/timescaledb/issues/3653)
I have a hypertable request_logs configured with a 24 hour retention policy. The retention policy is being marked as running successfully, however no old data from the table is being removed. The table continues to grow day by day.
I checked and don't see any errors in the postgresql log files.
Could use additional guidance on where to look for information to troubleshoot this issue.
request_logs table structure
\d+ request_logs;
Table "public.request_logs"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
-----------+--------------------------+-----------+----------+---------+---------+--------------+-------------
time | timestamp with time zone | | not null | | plain | |
referer | bigint | | | | plain | |
useragent | bigint | | | | plain | |
Indexes:
"request_logs_time_idx" btree ("time" DESC)
Triggers:
ts_insert_blocker BEFORE INSERT ON request_logs FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Child tables: _timescaledb_internal._hyper_1_37_chunk,
_timescaledb_internal._hyper_1_38_chunk,
_timescaledb_internal._hyper_1_40_chunk
Access method: heap
This is the hypertable description retrieved by running select * from _timescaledb_catalog.hypertable;
id | schema_name | table_name | associated_schema_name | associated_table_prefix | num_dimensions | chunk_sizing_func_schema | chunk_sizing_func_name | chunk_target_size | compression_state | compressed_hypertable_id | replication_factor
----+-------------+--------------+------------------------+-------------------------+----------------+--------------------------+--------------------------+-------------------+-------------------+--------------------------+--------------------
1 | public | request_logs | _timescaledb_internal | _hyper_1 | 1 | _timescaledb_internal | calculate_chunk_interval | 0 | 0 | |
(1 row)
This is the retention_policy retrieved by running SELECT * FROM timescaledb_information.job_stats;.
hypertable_schema | hypertable_name | job_id | last_run_started_at | last_successful_finish | last_run_status | job_status | last_run_duration | next_start | total_runs | total_successes | total_failures
-------------------+-----------------+--------+-------------------------------+-------------------------------+-----------------+------------+-------------------+-------------------------------+------------+-----------------+----------------
public | request_logs | 1002 | 2021-10-05 23:59:01.601404+00 | 2021-10-05 23:59:01.638441+00 | Success | Scheduled | 00:00:00.037037 | 2021-10-06 23:59:01.638441+00 | 8 | 8 | 0
| | 1 | 2021-10-05 08:38:20.473945+00 | 2021-10-05 08:38:21.153468+00 | Success | Scheduled | 00:00:00.679523 | 2021-10-06 08:38:21.153468+00 | 45 | 45 | 0
(2 rows)
Relevant system information:
OS: Ubuntu 20.04.3 LTS
PostgreSQL version (output of postgres --version): 12
TimescaleDB version (output of \dx in psql): 2.4.1
Installation method: apt install process described https://docs.timescale.com/timescaledb/latest/how-to-guides/install-timescaledb/self-hosted/ubuntu/installation-apt-ubuntu/#installation-apt-ubuntu
It looks as though this might be related to a bug that has been fixed in version 2.4.2 of TimescaleDB. The GitHub report has been updated, if you find that the issue remains after upgrade, please update the issue on GitHub with your example. Thanks for reporting!
Transparency: I work for Timescale
I am trying to run a CREATE INDEX CONCURRENTLY command against a Postgres 9.2 database. I implemented a MigrationResolver as shown in issue 655. When this migration step is run via mvn flyway:migrate or similar, the command starts but hangs in waiting mode.
I verified that the command is executing via the pg_stat_activity table:
test_2015_04_13_110536=# select * from pg_stat_activity;
datid | datname | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | xact_start | query_start | state_change | waiting | state | query
-------+------------------------+-------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+-------------------------------+-------------------------------+-------------------------------+---------+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
21095 | test_2015_04_13_110536 | 56695 | 16385 | postgres | psql | | | -1 | 2015-04-13 11:10:01.127768-06 | 2015-04-13 11:13:08.936651-06 | 2015-04-13 11:13:08.936651-06 | 2015-04-13 11:13:08.936655-06 | f | active | select * from pg_stat_activity;
21095 | test_2015_04_13_110536 | 56824 | 16385 | postgres | | 127.0.0.1 | | 52437 | 2015-04-13 11:12:55.438927-06 | 2015-04-13 11:12:55.476442-06 | 2015-04-13 11:12:55.487139-06 | 2015-04-13 11:12:55.487175-06 | f | idle in transaction | SELECT "version_rank","installed_rank","version","description","type","script","checksum","installed_on","installed_by","execution_time","success" FROM "public"."schema_version" ORDER BY "version_rank"
21095 | test_2015_04_13_110536 | 56825 | 16385 | postgres | | 127.0.0.1 | | 52438 | 2015-04-13 11:12:55.443687-06 | 2015-04-13 11:12:55.49024-06 | 2015-04-13 11:12:55.49024-06 | 2015-04-13 11:12:55.490241-06 | t | active | CREATE UNIQUE INDEX CONCURRENTLY person_restrict_duplicates_2_idx ON person(name, person_month, person_year)
(3 rows)
An example project that replicates this problem can be found in my github: chrisphelps/flyway-experiment
My suspicion is that the flyway query against schema version which is idle in transaction is preventing postgres from proceeding with the index creation.
How can I resolve the conflict so that postgres will proceed with the migration? Has anyone been able to apply this sort of migration to postgres via flyway?
In the meantime, there is a Resolver included in flyway which looks for some magic in the filename.
Just add the prefix 'NT' (for No-Transaction) to your migration file, i. e.
V01__usual_migration_1.sql
V02__another_migration.sql
NTV03__migration_that_does_not_run_in_transaction.sql
V04__classical_migration_4.sql
etc.
I have recently installed postgres on my Mac and loaded a dump from our public website that I am trying to replicate locally. The pg_restore appeared to be successful, and I can see all my tables and user permissions in phpPgAdmin. They all look normal, and I can browse the data. However, when I access the database via psql I get no relations found. Similarly I have python scripts that access this database, and they also fail to find any tables.
I'm at a loss as to what to do.
Here are some psql commands I've done:
> psql -U mgd_dbo pub_mgd
psql (9.3.4)
Type "help" for help.
pub_mgd=# \d
No relations found.
pub_mgd=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
------------+------------+----------+------------------+-------+-------------------------
postgres | postgres | UTF8 | C | C | =CTc/postgres +
| | | | | postgres=CTc/postgres +
| | | | | mgd_dbo=CTc/postgres +
| | | | | mgd_public=CTc/postgres
pub_fe | postgres | LATIN9 | en_US.ISO8859-15 | C | =CTc/postgres +
| | | | | postgres=CTc/postgres +
| | | | | mgd_dbo=CTc/postgres +
| | | | | mgd_public=CTc/postgres
pub_mgd | postgres | LATIN9 | en_US.ISO8859-15 | C | =CTc/postgres +
| | | | | postgres=CTc/postgres +
| | | | | mgd_dbo=CTc/postgres +
| | | | | mgd_public=CTc/postgres
template0 | postgres | UTF8 | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
(5 rows)
pub_mgd=# \dn+
List of schemas
Name | Owner | Access privileges | Description
--------+----------+----------------------+------------------------
mgd | mgd_dbo | mgd_dbo=UC/mgd_dbo +|
| | mgd_public=U/mgd_dbo |
public | postgres | postgres=UC/postgres+| standard public schema
| | =UC/postgres |
(2 rows)
pub_mgd is the database I've loaded. mgd_public and mgd_dbo are the two different users our scripts use (mgd_public is a read-only user).
I've tried both users, and even as the postgres user. Yet, the results are the same, no relations.
I even tried to see if phpPgAdmin was somehow hitting a different postgres sever, so I added a new database through it, and verified that the new database appears when I do \l in psql.
Any suggestions as to what to check next?
Ask for the list of relations in the mgd schema
\d mgd.*
To make the mgd schema the default place it at the beginning of the search path
set search_path to mgd, "$user", public;
I tried to create a language pltcl in postgresql. But, I got this error.
postgres=# CREATE LANGUAGE 'pltcl';
ERROR: could not access file "$libdir/pltcl": No such file or directory
postgres=# select * from pg_pltemplate;
tmplname | tmpltrusted | tmpldbacreate | tmplhandler | tmplvalidator | tmpllibrary | tmplacl
-----------+-------------+---------------+-----------------------+-------------------+------------------+---------
plpgsql | t | t | plpgsql_call_handler | plpgsql_validator | $libdir/plpgsql |
pltcl | t | t | pltcl_call_handler | | $libdir/pltcl |
pltclu | f | f | pltclu_call_handler | | $libdir/pltcl |
plperl | t | t | plperl_call_handler | plperl_validator | $libdir/plperl |
plperlu | f | f | plperl_call_handler | plperl_validator | $libdir/plperl |
plpythonu | f | f | plpython_call_handler | | $libdir/plpython |
After referred the internet, I got the answer. That is,
In order to get pltcl.so you will need to compile the postgres code using --with-tcl configure switch. pltcl does not compile by default with postgres.
How to fix this problem?
You need to install the postgresql-pltcl-9.1 package, replacing the 9.1 with the postgres version you're using if it's different.
sudo apt-get install postgresql-pltcl-9.6 postgresql-plperl-9.6
How can I find what languages have been loaded into EnterpriseDB(PL/pgsql, SPL, Java)? EnterpriseDB is built on top of PostgreSQL if anyone knows of a way to find the loaded languages on PostgreSQL. It should work the same.
The installed languages are registered in pl_language, e.g.:
steve#steve#[local] =# select * from pg_language;
lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid | lanvalidator | lanacl
----------+----------+---------+--------------+---------------+--------------+--------
internal | 10 | f | f | 0 | 2246 |
c | 10 | f | f | 0 | 2247 |
sql | 10 | f | t | 0 | 2248 |
plpgsql | 10 | t | t | 73259 | 73260 |
(4 rows)
Check the "pg_language" system catalogue (hopefully EDB is not that different from Postgres).