My Postgres version is 9.6 ("PostgreSQL 9.6.16 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23), 64-bit"). I am trying to set the work_mem value for a session but it is not reflecting value. In a query window, I am doing following
show work_mem --displays "2MB"
SET work_mem = '256MB'; --displays "Query returned successfully with no result in 32 msec." in output pane
show work_mem --displays "2MB" again
The set command is successfully executed but value is not changed. please suggest something.
Related
I have 4 servers with the same versions of OS (Ubuntu 20.04), Postgis and Postgre:
POSTGIS="3.2.1 5fae8e5" [EXTENSION] PGSQL="130" GEOS="3.10.1-CAPI-1.16.0" PROJ="6.3.1" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)"
PostgreSQL 13.6 (Ubuntu 13.6-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit
The query below works on any server except one:
`
SELECT
st_asgeojson(st_transform("table-name".geom, 4326)) AS way
FROM "table-name"
`
The server with the issue responds this error:
SQL Error [XX000]: ERROR: could not form projection (LWPROJ) from 'srid=7801' to 'srid=4326'
I upgraded the postgis server to 3.3.2 but the result is the same.
Can you help me?
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 issued an SQL statement in DbVis:
select vestdate, name from person where vestdate is not null
And got many results where DbVisualizer showed vestdate as (null)!
After investigating, I discovered that the vestdate was '0001-01-01', so the query correctly returned these records, but DbVisualizer displays them as (null).
I have just switched from windows 8 to windows 10.
It works on windows 8 (displays '0001-01-01'), but not not windows 10 (displays null):
Product: DbVisualizer Pro 11.0.4 [Build #3103]
OS: Windows 8.1
OS Version: 6.3
OS Arch: amd64
Java Version: 1.8.0_252
Java VM: OpenJDK 64-Bit Server VM
Java Vendor: AdoptOpenJDK
Java Home: c:\program files\dbvisualizer\jre
DbVis Home: C:\Program Files\DbVisualizer
User Home: -------
PrefsDir: -------
SessionId: 55
BindDir: -------
Product: DbVisualizer Pro 11.0.5 [Build #3113]
OS: Windows 10
OS Version: 10.0
OS Arch: amd64
Java Version: 1.8.0_252
Java VM: OpenJDK 64-Bit Server VM
Java Vendor: AdoptOpenJDK
Java Home: c:\program files\dbvisualizer\jre
DbVis Home: C:\Program Files\DbVisualizer
User Home: -------
PrefsDir: -------
SessionId: 968
BindDir: -------
Any ideas how to make the program show me the real value, not the interpreted value of null?
The issue is explained in an IBM support document:
Problem
Trying to insert a date value into a date column before 1940 or after 2039 will represent the date as NULL within the respective database table.
Cause
This is caused by a limitation with the IBM i database Toolbox JDBC driver as detailed in the related link:
How does the Toolbox JDBC driver deal with dates before 1940 (or after 2039)?
The IBM i database supports several date formats. The Toolbox JDBC driver uses the date format that is set up as the default on the IBM i system. This default is usually set to "mdy" which only supports dates between 1940 and 2039. You can override the date format by specifying the "date format" property when opening the JDBC connection. The best choice is "iso", which supports a full four-digit date. The easiest way to do this is to add ";date format=iso" to the end of the URL used when connecting to the database.
Resolving The Problem
Appending the ";date format=iso" to the host connection property for the applicable database
via Preferences-> EGL-> SQL Database Connections will then show the respective dates correctly eg:
1939-01-01.
The issue can be fixed in DBVisualizer by doing the following:
Database -> Edit Database Connection(s)...
Select Properties tab
Select Driver Properties
Edit parameters date format and time format to be iso
Apply Changes
Disconnect and reconnect
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";