I am trying to create a partitioned table in edb 9.6.10 . I am getting the following error when I am trying to do so
edb=# create table employee (id int, join_date timestamp(6)) PARTITION BY RANGE (join_date) INTERVAL ('1 day'::interval);
ERROR: syntax error at or near "INTERVAL"
LINE 1: ...date timestamp(6)) PARTITION BY RANGE (join_date) INTERVAL (...
^
Please let me know what I am doing wrong here.
As far as I can tell, the feature you are trying to use only exists in EDB's paid product, and even there it only became available in v12.
This PARTITION BY RANGE INTERVAL is only supported from version 12 and onward.
See the difference of behaviour for the same query in version11 and version12.
edb=# select version;
PostgreSQL 11.11 (EnterpriseDB Advanced Server 11.11.20) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
(1 row)
edb=# create table employee (id int, join_date timestamp(6)) PARTITION BY RANGE (join_date) INTERVAL ('1 day'::interval);
ERROR: syntax error at or near "INTERVAL"
LINE 1: ...date timestamp(6)) PARTITION BY RANGE (join_date) INTERVAL (...
and in Version12 we get
edb=# select version();
PostgreSQL 12.4 (EnterpriseDB Advanced Server 12.4.5) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
(1 row)
edb=# create table employee (id int, join_date timestamp(6)) PARTITION BY RANGE (join_date) INTERVAL ('1 day'::interval);
CREATE TABLE
Moreover, this 'INTERVAL' syntax is only available in EnterpriseDB paid product. In the case of community Postgres e.g V13 you will still get the same error.
[root#localhost bin]# ./psql -U postgres -d postgres -p 5432
psql (13.2)
Type "help" for help.
postgres=# create table employee (id int, join_date timestamp(6)) PARTITION BY RANGE (join_date) INTERVAL ('1 day'::interval);
ERROR: syntax error at or near "INTERVAL"
LINE 1: ...date timestamp(6)) PARTITION BY RANGE (join_date) INTERVAL (...
Related
I inserted the following postgres query in the queries.yaml file with Labels and metric.
pg_long_running_query_details:
query: "SELECT distinct a.datname as database , a.usename as user , round(extract(epoch from statement_timestamp()) - extract(epoch from a.query_start)) as age FROM pg_stat_activity a JOIN pg_locks l ON l.pid = a.pid WHERE age(statement_timestamp(), query_start) > interval U&'10 minutes' limit 5"
metrics:
- database:
usage: "LABEL"
description: "Name of the database"
- user:
usage: "LABEL"
description: "Name of the user"
- age:
usage: "GAUGE"
description: "The age in seconds"
I would expect pg_long_running_query_details_age metric flowing through prometheus. Not only there is no metric but no errors in the exporter too. The query works perfectly fine in psql cli.
When I remove the interval time, i can see the metric. So i'm guessing, its something to do with the single quotes.
What did you see instead? Under which circumstances?
No metric in the name 'pg_long.*'
Environment
Ubuntu
System information:
Linux 4.15.0-135-generic x86_64
postgres_exporter version:
Postgres Exporter - Wrouesnel v0.5.1.
postgres_exporter flags:
insert list of flags used here
PostgresSQL version:
PostgreSQL 11.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logs:
No error logs in the exporter.
I ran command import tables from "xxx.sql" into Postgres database test, it shows all tables are created but when I run \dt in database test, it shows "Didn't find any relations" but when I try to create table manually, it shows "relation xxx already exists"
test=# create table test.order_product
(
id serial primary key,
quantity integer,
order_id integer references test.order (id),
);
ERROR: relation "order_product" already exists
test=# select * from order_product;
ERROR: relation "order_product" does not exist
LINE 1: select * from order_product;
Does anyone know what is wrong?
Below is the version information:
PostgreSQL 12.4 (Debian 12.4-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
Question:
Is there a way for pg_dump commands not to use search_path to set a schema, and instead define the schema with the table name
My general context is that I'm trying to dump and restore a postgis database which contains many schemas (this is to migrate my database into an Amazon RDS). In each schema I have tables that have a geography column. The generated SQL from the dump is something like:
CREATE SCHEMA aaaa;
SET search_path = aaaa, pg_catalog;
SET default_tablespace = '';
SET default_with_oids = false;
--
-- TOC entry 346 (class 1259 OID 1135099)
-- Name: main; Type: TABLE; Schema: aaaa; Owner: -
--
CREATE TABLE main (
pk bigint NOT NULL,
geometry public.geography(Geometry,4283),
batch bigint NOT NULL,
json jsonb NOT NULL,
cache jsonb NOT NULL,
active bigint DEFAULT date_part('epoch'::text, now()) NOT NULL,
inactive bigint DEFAULT '8640000000000000'::bigint NOT NULL );
However, when restoring, I get the following error:
pg_restore: [archiver (db)] Error from TOC entry 346; 1259 1135099
TABLE main mapworks pg_restore: [archiver (db)] could not execute
query: ERROR: relation "spatial_ref_sys" does not exist LINE 3:
geometry public.geography(Geometry,4283),
^ QUERY: SELECT proj4text FROM spatial_ref_sys WHERE srid = 4283 LIMIT 1
Command was: CREATE TABLE main (
pk bigint NOT NULL,
geometry public.geography(Geometry,4283),
batch bigint NOT NULL,
jso...
Then things just go pear shaped from there.
What I've deduced so far is that because the 'public' schema is not included in the search path, the operation cant find the 'spatial_ref_sys' table.
Oddly enough, this works fine if the EPSG code is 4326.
So ... what can I do about this? Is there a way to tell pg_dump not to use search_path?
The server I'm dumping from:
PostgreSQL 9.6.1 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit
POSTGIS="2.3.1 r15264" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.1, released 2013/08/26" LIBXML="2.9.1" LIBJSON="0.11.99" (core procs from "2.3.0 r15146" need upgrade) TOPOLOGY (topology procs from "2.3.0 r15146" need upgrade) RASTER (raster procs from "2.3.0 r15146" need upgrade)
The server I'm restoring to:
PostgreSQL 9.6.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16), 64-bit
POSTGIS="2.3.0 r15146" GEOS="3.5.0-CAPI-1.9.0 r4084" PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 2.1.1, released 2016/07/07" LIBXML="2.9.1" LIBJSON="0.12" TOPOLOGY RASTER
I have a PostgreSQL database on a shared host and the result of using the upper function is different in my local database because of the locale setting.
Here is what I want, and have in my local environment:
SELECT version();
-- "PostgreSQL 8.4.16 on i386-apple-darwin10.8.0, compiled by GCC i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3), 64-bit"
SHOW LC_COLLATE;
-- "fr_FR.UTF-8"
SELECT upper('étienne');
-- "ÉTIENNE"
Here is what I have in the production environment:
SELECT version();
-- "PostgreSQL 9.0.13 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2, 64-bit"
SHOW LC_COLLATE;
-- "C"
SELECT upper('étienne');
-- éTIENNE
Now, because the production environment is in a shared host, I cannot change the locale due to the host policies. So, is there another way to have the expected result when using upper function?
For 9.1 and up, you can just choose collation locally for the query.
Sadly, considering your version numbers, that would require an upgrade, so may or may not be helpful.
SELECT UPPER('étienne' COLLATE "C") C_Collation,
UPPER('étienne' COLLATE "fr_FR") FR_Collation;
C_Collation FR_Collation
--------------------------------------
éTIENNE ÉTIENNE
An SQLfiddle to test with.
Note that you cannot override the collation (like demonstrated by other answers) in your versions 8.4 or 9.0. This feature was introduced with Postgres 9.1.
In earlier versions, you cannot change the collation chosen when the database was created. The COLLATE key word does not exist and you get an error if you try SET LC_COLLATE = ...:
ERROR: parameter "lc_collate" cannot be changed
You need a more current version to do that.
-> SQLfiddle
Sorry, but you are out of luck.
select upper('étienne') collate "fr_FR";
I have a PostgreSQL database on a shared host and the result of using the upper function is different in my local database because of the locale setting.
Here is what I want, and have in my local environment:
SELECT version();
-- "PostgreSQL 8.4.16 on i386-apple-darwin10.8.0, compiled by GCC i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3), 64-bit"
SHOW LC_COLLATE;
-- "fr_FR.UTF-8"
SELECT upper('étienne');
-- "ÉTIENNE"
Here is what I have in the production environment:
SELECT version();
-- "PostgreSQL 9.0.13 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2, 64-bit"
SHOW LC_COLLATE;
-- "C"
SELECT upper('étienne');
-- éTIENNE
Now, because the production environment is in a shared host, I cannot change the locale due to the host policies. So, is there another way to have the expected result when using upper function?
For 9.1 and up, you can just choose collation locally for the query.
Sadly, considering your version numbers, that would require an upgrade, so may or may not be helpful.
SELECT UPPER('étienne' COLLATE "C") C_Collation,
UPPER('étienne' COLLATE "fr_FR") FR_Collation;
C_Collation FR_Collation
--------------------------------------
éTIENNE ÉTIENNE
An SQLfiddle to test with.
Note that you cannot override the collation (like demonstrated by other answers) in your versions 8.4 or 9.0. This feature was introduced with Postgres 9.1.
In earlier versions, you cannot change the collation chosen when the database was created. The COLLATE key word does not exist and you get an error if you try SET LC_COLLATE = ...:
ERROR: parameter "lc_collate" cannot be changed
You need a more current version to do that.
-> SQLfiddle
Sorry, but you are out of luck.
select upper('étienne') collate "fr_FR";