I have installed PostgreSQL 13 and created a new database, a few tables and inserted data on those tables. I used transactions to insert data, but still pg_commit_ts is empty.
what is the function of this directory and why is it empty?
The directory is empty because track_commit_timestamp is off. It is used to persist commit timestamps.
Related
I have a postgres 9.3 database in a windows installation. The complete installation is on a raid installed.
We wanted to replace that raid with new drives since the old ones started to die. We copied all data from the raid to a new drive with the file explorer (wasn't me...), then replaced all drives and created a new raid, put back on all the old data and changed the drive letter back to the old one. Thinking that everything would work as normal.
Sadly not with postgres. The copying with file explorer destroyed all symlinks in the pg_tblspc folder. They arent symlinks anymore, they are just empty folders. So I have now 147 broken symlinks...
I checked how the symlinks working and compared to a working postgres installation. I found out that every table has an OID. For each OID there are 2 symlinks in that folder. The symlinks have an increased number.
For example, the OID of a table is 17530, then I have 2 symlinks 17538 and 17541. These pointing towards the data folder with the database name. In the folder with the database name I have 2 folders again. One of these symlinks pointing to one of these folders.
The increased numbers are always so same. So its always OID +8 and +11 (on other working installation its always +4 and +7).
All the table management is done by a program (FTK). So if you do stuff in there, its creating/deleting/updating the databases and tables for you. I think that its always 2 folders in there is because FTK is doing that in that way.
My question is now: Can I just manually create these symlinks? And then everything should work? Or is there maybe a function from postgres, where I can point to the "new" folder and it recreates the symlinks? It looks like the symlinks are managed by postgres itself. But so far I couldnt find anything about a repair function
Mistake number one was not to take a backup. Mistake number two was to create 147 tablespaces. But let's no dwell on that. What can you do?
First, facts. In the directory pg_tblspc is one symbolic link per tablespace, not per table. The name of the symbolic link is the object ID of the tablespace. You can find the object IDs with
SELECT oid, spcname FROM pg_tablespace;
Then you have to figure out what directory belong to which tablespace. There i no help for that, since that is the information that got lost. Once you know the path for a tablespace:
change to the pg_tblspc directory
run
ln -s /path/to/tablespace 12345
where 12345 is the OID of the tablespace.
Needless to say, PostgreSQL must be shut down when you do that. Once you have re-created the symbolic links for all tablespaces, you should be good.
At the pgdata root there is the pg_snapshots folder. Which PostgreSQL functionality is using that folder, what kind of data is written in there.
pg_snapshot stores data for query snapshots that have been exported with pg_export_snapshot. The purpose of exported snapshots is that several database sessions can see exactly the same state of the database. This is for example used for parallel pg_dump with the "directory" format, but it can also be useful to synchronize the original data copy with the capture of data modifications via logical decoding.
My DB2 backups are starting to take up too much space, and I'd like to start pruning some of the older files. In the past I had simply deleted some files, but that led to some issues when trying to use one of the backup files (unfortunately the details escape me).
I read here that I can get DB2 to manage this. I did the following:
db2 update db cfg for db_name using AUTO_DEL_REC_OBJ ON
db2 update db cfg for db_name using NUM_DB_BACKUPS 6
db2 update db cfg for db_name using REC_HIS_RETENTN 21
Our backups run twice weekly, so I was thinking I would save 3 weeks worth. After setting these values, I ran a backup:
db2 backup db db_name user username using password online to file_path include logs without prompting
The backup ran correctly and created a new backup file, but none of the existing files were deleted (I have backups more than 21 days old).
As per this link I expected the Auto Delete to occur at the time I ran the backup. My LOGARCHMETH1 is set to USEREXIT.
My questions are:
Why did my previous files not get removed (and what do I need to change to get them to be removed automatically)?
Can I safely remove log files by simply deleting them from the filesystem?
I have a directory where postgres was writing to a file: 15426233.4
-rw------- 1 postgres sql 1.0G Feb 4 13:41 15426233
-rw------- 1 postgres sql 149M Feb 4 13:41 15426233.4
-rw------- 1 postgres sql 1.0G Feb 4 13:41 15426233.3
drwx------ 3 postgres sql 75K Feb 4 13:40 .
-rw------- 1 postgres sql 1.0G Feb 4 13:34 15426233.2
-rw------- 1 postgres sql 1.0G Feb 4 13:28 15426233.1
Initially this file 15426233.4 was under /data5/PG_9.1/15411/15426233.4. Due to disk space getting filled up under /data6 partition I ended up moving to /data8 however normally we run a symlink so that /data5/PG_9.1/15411/15426233.4 would now symlink to /data8/PG_9.1/15411/15426233.4. Due to lack of disk space the symlink creation failed but move still happened. A while later postgres started writing to a new file /data5/PG_9.1/15411/15426233.4. Is there a way I can stop the db, consolidate the data in /data5/PG_9.1/15411/15426233.4 to /data8/PG_9.1/15411/15426233.4, then create a symlink /data5/PG_9.1/15411/15426233.4 that points to /data8/PG_9.1/15411/15426233.4 and restart the postgres db?
Never, ever, mess with individual files in the data directory. And never ever change catalog tables (pg_tablespace) manually. Everything you need to do can be done through SQL or by handling the complete data directory.
You have several ways to move data to a bigger disk:
Tablespaces
When you create a new tablespace you can put that on the other disk. Then move the tables in question to the new tablespace:
create tablespace bigdata location '/path/to/bigdisk';
Then move the tables to the tablespace:
alter table bigtable set tablespace bigdata;
There is no need to mess around with the data directory manually.
Move the data directory
Caution!
Only do this after stopping Postgres!
Once you have stopped the Postgres server, copy the complete(!) existing data directory to the new disk (make sure you have Postgres stopped before you do that). It's safe to copy the data and later delete the original if everything is OK rather than moving it right away.
After copying the data, adjust postgresql.conf to point it to the new data directory: http://www.postgresql.org/docs/current/static/runtime-config-file-locations.html
Rename the old data to make sure you will see an error if the configuration wasn't changed properly.
Start Postgres again.
The physical layout of the disk storage is documented in the manual:
http://www.postgresql.org/docs/current/static/storage.html
i want to drop a database in oracle 10g..
i saw the command
DROP database.
How to run this query and drop database.
If i tried this query, it is showing error as invalid query.
Oracle documentation states:
Dropping a database involves removing
its datafiles, redo log files, control
files, and initialization parameter
files. The DROP DATABASE statement
deletes all control files and all
other database files listed in the
control file. To use the DROP DATABASE
statement successfully, all of the
following conditions must apply:
The database must be mounted and closed.
The database must be mounted exclusively--not in shared mode.
The database must be mounted as RESTRICTED.
An example of this statement is:
DROP DATABASE;
The DROP DATABASE statement has no
effect on archived log files, nor does
it have any effect on copies or
backups of the database. It is best to
use RMAN to delete such files. If the
database is on raw disks, the actual
raw disk special files are not
deleted.
If you used the Database Configuration
Assistant to create your database, you
can use that tool to delete (drop)
your database and remove the files.