PostgreSQL's table oid is not found in database - postgresql

I have a question about PostgreSQL's table oid.
I create a table. oid is 24622
(-rw------- 1 postgres postgres 8192 Nov 29 17:45 24622)
and I found also modified files at the same time.
(-rw------- 1 postgres postgres 73728 Nov 29 17:45 12741)
(-rw------- 1 postgres postgres 32768 Nov 29 17:45 12744)
(-rw------- 1 postgres postgres 65536 Nov 29 17:45 12764)
(-rw------- 1 postgres postgres 57344 Nov 29 17:45 12767)
but those tables are not found in same database, no one is found.
ksh2=# select oid,relname from pg_class where oid = '12741';
oid | relname
-----+---------
(0 rows)
How can I find those tables???
(I also change schema, and try to find, but no one is found)
Thank you.

A filename doesn't necessarily correspond with oid:
Note that while a table's filenode often matches its OID, this is not
necessarily the case; some operations, like TRUNCATE, REINDEX, CLUSTER
and some forms of ALTER TABLE, can change the filenode while
preserving the OID.
The filename is stored in the relfilenode column:
Name of the on-disk file of this relation; zero means this is a
"mapped" relation whose disk file name is determined by low-level
state
So try searching for the relfilenode:
select name, relkind from pg_class where relfilenode = 12741;
The relkind column tells you what type of object the file represents:
r = ordinary table
i = index
S = sequence
v = view
c = composite type
t = TOAST table
f = foreign table

Related

Why is id as SERIAL discontinuous values after failover in RDS Aurora PostgreSQL?

I'm testing failover using RDS Aurora PostgreSQL.
First, create RDS Aurora PostgreSQL and access the writer cluster to create users table.
$ CREATE TABLE users (
id SERIAL PRIMARY KEY NOT NULL,
name varchar(10) NOT NULL,
createAt TIMESTAMP DEFAULT Now() );
And I added one row and checked the table.
$ INSERT INTO users(name) VALUES ('test');
$ SELECT * FROM users;
+----+--------+----------------------------+
| id | name | createdAt |
+----+--------+----------------------------+
| 1 | test | 2022-02-02 23:09:57.047981 |
+----+--------+----------------------------+
After failover of RDS Aurora Cluster, I added another row and checked the table.
$ INSERT INTO users(name) VALUES ('temp');
$ SELECT * FROM users;
+-----+--------+----------------------------+
| id | name | createdAt |
+-----+--------+----------------------------+
| 1 | test | 2022-02-01 11:09:57.047981 |
| 32 | temp | 2022-02-01 11:25:57.047981 |
+-----+--------+----------------------------+
After failover, the id value that should be 2 became 32.
Why is this happening?
Is there any way to solve this problem?
That is to be expected. Index modifications are not WAL logged whenever nextval is called, because that could become a performance bottleneck. Rather, a WAL record is written every 32 calls. That means that the sequence can skip some values after a crash or failover to the standby.
You may want to read my ruminations about gaps in sequences.

SQLSTATE=23514 : Facing error on Set integrity

Can someone suggest me what is the problem, why I am not able to enable integrity, although no constraint found with name of CATEGORY.
create function FCOK_ACCOUNT_CATEGORY_C2(xmlrecord XML) returns integer language sql contains sql no external action deterministic return xmlcast(xmlquery('$d/row/c2' passing xmlrecord as "d") as integer);
reorg table FCOK_ACCOUNT_TEST inplace
db2pd -db admindb –reorg
Database Member 0 -- Database ADMINDB -- Active -- Up 10 days 03:14:17 -- Date 2021-07-26-19.28.05.648688
Table Reorg Information:
Address TbspaceID TableID PartID MasterTbs MasterTab TableName Type IndexID TempSpaceID
0x0A001F00174DF588 4 21566 n/a n/a n/a FCOK_ACCOUNT Offline 0 4
0x0A001F0027981508 3 26880 n/a n/a n/a FCOK_ACCOUNT_TEST Online 0 3
Table Reorg Stats:
Address TableName Start End PhaseStart MaxPhase Phase CurCount MaxCount Status Completion
0x0A001F00174DF588 FCOK_ACCOUNT 07/16/2021 18:38:46 07/16/2021 18:43:15 07/16/2021 18:39:40 3 IdxRecreat 0 0 Done 0
0x0A001F0027981508 FCOK_ACCOUNT_TEST 07/26/2021 18:13:16 07/26/2021 18:14:38 n/a n/a n/a 0 0 Done 0
bash-4.2$
set integrity for FCOK_ACCOUNT_TEST off;
ALTER TABLE FCOK_ACCOUNT_TEST ADD CATEGORY INTEGER generated always as (FCOK_ACCOUNT_CATEGORY_C2(XMLRECORD))
set integrity for FCOK_ACCOUNT_TEST immediate checked;
db2 "set integrity for DB2ADMIN.FCOK_ACCOUNT_TEST immediate checked"
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL3603N Integrity processing through the SET INTEGRITY statement has found
an integrity violation involving a constraint, a unique index, a generated
column, or an index over an XML column. The associated object is identified by
"DB2ADMIN.FCOK_ACCOUNT_TEST.CATEGORY". SQLSTATE=23514
bash-4.2$
bash-4.2$ db2 "select TYPE, ENFORCED from SYSCAT.TABCONST where CONSTNAME='CATEGORY'"
TYPE ENFORCED
0 record(s) selected.
bash-4.2$ db2 "select COLSEQ,COLNAME from SYSCAT.KEYCOLUSE where CONSTNAME='CATEGORY'"
COLSEQ COLNAME
0 record(s) selected.
bash-4.2$ db2 "reorg table db2admin.FCOK_ACCOUNT_TEST inplace"
SQL0668N Operation not allowed for reason code "1" on table
"DB2ADMIN.FCOK_ACCOUNT_TEST". SQLSTATE=57016

Restore database db2 get error SQLSTATE=57019

After install IBM data server, i have one administrator user. I log this user into win 10.
db2 => create database sss (successful)
db2 => connect to sss
db2 => restore database sss from d:\
Drive D: has backup file. I also used create database sss to make database before. When i backup, i let backup file in drive D:. But i get error :
SQL2523W Warning! Restoring to an existing database that is different from
the database on the backup image, but have matching names. The target database
will be overwritten by the backup version. The Roll-forward recovery logs
associated with the target database will be deleted.
Do you want to continue ? (y/n) y
SQL1051N The path "E:" does not exist or is not valid. SQLSTATE=57019
What is Drive E:. I never used that drive E:
My test.clp :
UPDATE COMMAND OPTIONS USING S ON Z ON SSS_NODE0000.out V ON;
SET CLIENT ATTACH_MEMBER 0;
SET CLIENT CONNECT_MEMBER 0;
RESTORE DATABASE SSS
-- USER <username>
-- USING '<password>'
FROM 'd:\'
TAKEN AT 20210603080520
-- ON 'E:'
-- DBPATH ON '<target-directory>'
INTO SSS
-- NEWLOGPATH 'E:\DB2\NODE0000\SQL00002\LOGSTREAM0000\'
-- WITH <num-buff> BUFFERS
-- BUFFER <buffer-size>
-- REPLACE HISTORY FILE
-- REPLACE EXISTING
REDIRECT
-- PARALLELISM <n>
WITHOUT ROLLING FORWARD
-- WITHOUT PROMPTING
;
-- ** storage group definition
-- ** Default storage group ID = 0
-- ** Number of storage groups = 1
-- ** Storage group name = IBMSTOGROUP
-- ** Storage group ID = 0
-- ** Data tag = None
-- -- SET STOGROUP PATHS FOR IBMSTOGROUP
-- ON 'E:'
-- ;
-- ** table space definition
-- ** Tablespace name = SYSCATSPACE
-- ** Tablespace ID = 0
-- ** Tablespace Type = Database managed
space
-- ** Tablespace Content Type = All permanent
data. Regular table space.
-- ** Tablespace Page size (bytes) = 4096
-- ** Tablespace Extent size (pages) = 4
-- ** Using automatic storage = Yes
-- ** Storage group ID = 0
-- ** Source storage group ID = -1
-- ** Data tag = None
-- ** Auto-resize enabled = Yes
-- ** Total number of pages = 32768
-- ** Number of usable pages = 32764
-- ** High water mark (pages) = 31016
-- ** Tablespace name = TEMPSPACE1
-- ** Tablespace ID = 1
-- ** Tablespace Type = System managed
space
-- ** Tablespace Content Type = System Temporary
data
-- ** Tablespace Page size (bytes) = 4096
-- ** Tablespace Extent size (pages) = 32
-- ** Using automatic storage = Yes
-- ** Total number of pages = 1
-- ** Tablespace name = USERSPACE1
-- ** Tablespace ID = 2
-- ** Tablespace Type = Database managed
space
-- ** Tablespace Content Type = All permanent
data. Large table space.
-- ** Tablespace Page size (bytes) = 4096
-- ** Tablespace Extent size (pages) = 32
-- ** Using automatic storage = Yes
-- ** Storage group ID = 0
-- ** Source storage group ID = -1
-- ** Data tag = -1
-- ** Auto-resize enabled = Yes
-- ** Total number of pages = 8192
-- ** Number of usable pages = 8160
-- ** High water mark (pages) = 544
-- ** Tablespace name = SYSTOOLSPACE
-- ** Tablespace ID = 3
-- ** Tablespace Type = Database managed
space
-- ** Tablespace Content Type = All permanent
data. Large table space.
-- ** Tablespace Page size (bytes) = 4096
-- ** Tablespace Extent size (pages) = 4
-- ** Using automatic storage = Yes
-- ** Storage group ID = 0
-- ** Source storage group ID = -1
-- ** Data tag = -1
-- ** Auto-resize enabled = Yes
-- ** Total number of pages = 8192
-- ** Number of usable pages = 8188
-- ** High water mark (pages) = 152
-- ** start redirected restore
RESTORE DATABASE SSS CONTINUE;
-- ** end of file
D:>db2 -tvf d:\test.clp
UPDATE COMMAND OPTIONS USING S ON Z ON SSS_NODE0000.out V ON
DB20000I The UPDATE COMMAND OPTIONS command completed successfully.
SET CLIENT ATTACH_MEMBER 0
DB20000I The SET CLIENT command completed successfully.
SET CLIENT CONNECT_MEMBER 0
DB20000I The SET CLIENT command completed successfully.
RESTORE DATABASE SSS FROM 'd:' TAKEN AT 20210603080520 INTO SSS REDIRECT WITHOUT ROLLING FORWARD
SQL2523W Warning! Restoring to an existing database that is different from
the database on the backup image, but have matching names. The target database
will be overwritten by the backup version. The Roll-forward recovery logs
associated with the target database will be deleted.
Do you want to continue ? (y/n) y
SQL1277W A redirected restore operation is being performed. During a table
space restore, only table spaces being restored can have their paths
reconfigured. During a database restore, storage group storage paths and DMS
table space containers can be reconfigured.
DB20000I The RESTORE DATABASE command completed successfully.
RESTORE DATABASE SSS CONTINUE
SQL1051N The path "E:" does not exist or is not valid. SQLSTATE=57019

PostgreSQL on Corda enterprise node throws relation errors

Running corda enterprise with PostgreSQL in docker container. I have followed the instruction in docs and have set database schema. On database start I see the following errors. Can anyone help what is going on there?
2018-10-11 06:57:57.491 UTC [1506] ERROR: relation "node_checkpoints" does not exist at character 22
2018-10-11 06:57:57.491 UTC [1506] STATEMENT: select count(*) from node_checkpoints
2018-10-11 06:58:22.440 UTC [1506] ERROR: relation "corda-schema.databasechangeloglock" does not exist at character 22
2018-10-11 06:58:22.440 UTC [1506] STATEMENT: select count(*) from "corda-schema".databasechangeloglock
It seems the database user name and schema name don't have the same value, ensure that correct default schema is set for the user by running as database administrator:
ALTER ROLE "[USER]" SET search_path = "[SCHEMA]";
Other possible issue is to mixing upper/lower case and other characters in schema name, could you ensure that schema name has all lower cases (e.g. corda-schema and not CORDA-SCHEMA or Corda-Schema).

Is there a way for pg_dump not to use search_path for schema

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