WAL file naming is really an implementation detail. See the source code - starting with the implementation of pg_xlogfile_name in src/backend/access/transam/xlogfuncs.c, which uses XLogFileName in src/include/access/xlog_internal.h:
#define XLogFileName(fname, tli, logSegNo) \
snprintf(fname, MAXFNAMELEN, "%08X%08X%08X", tli, \
(uint32) ((logSegNo) / XLogSegmentsPerXLogId), \
(uint32) ((logSegNo) % XLogSegmentsPerXLogId))
From there you can see that in current PostgreSQL versions the archive name is eight zero-padded hex digits of timeline ID, then a somewhat oddly formatted value for the segment that works out to the high 32 bits of a 64-bit segment number zero-padded out to 8 hex digits, then the low 32 bits zero padded out to 8 hex digits. That format is really a historical quirk.
You can work that out because of the definition of XLogSegmentsPerXLogId:
#define XLogSegmentsPerXLogId (UINT64CONST(0x100000000) / XLOG_SEG_SIZE)
which is 1 << 32 i.e. 2^32, so really the XLogFileName is just taking the high and low 32 bits.
That said, you shouldn't need to do anything with WAL based on the file names, except use them to uniquely identify a WAL file, so I'm wondering why you're asking this. What're you trying to achieve?
Main problem was that I could not run psql command under no user.
Output I received was:
psql: FATAL: role "any role" does not exist
any role means that I tried to run psql under each user on my system(root,postgresql,my_user)
After all I haven't figured out what the problem was, I decided to reinstall PostgreSQL.
And this process turned out rather hard to.
So if you have problems with deleting and reinstalling PostgreSQL, read on.
Here what I had to do.
echo "deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main" > /etc/apt/sources.list.d/pgdg.list
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update
now we get error about missing postgresql-common
to fix it we need to install above package
lets determine its version
sudo apt-cache policy postgresql-common
and install it
sudo apt-get install postgresql-common=151.pgdg12.4+1
we can get error that postgresql-client-common not installed
so we need to do the same
determine it version
sudo apt-cache policy postgresql-client-common
and install
sudo apt-get install postgresql-client-common=151.pgdg12.4+1
after this we can install postgresql like this
sudo apt-get install postgresql-9.3 postgresql-contrib-9.3
Best Answer
If you had, say, a PostgreSQL 9.0 database using hstore, you would've loaded the hstore support by running the contrib's
.sqlscript.It was a major pain to dump and reload such databases, and especially to upgrade the contrib to a new version.
When extensions were introduced, there was a need to be able to convert the "unpackaged" contrib, i.e one loaded from an sql script, into an extension that could be recognised by the system, versioned, and upgraded using the extension control system.
That's what
from unpackagedis for. It registers an already-installed extension that was set up manually from a script.For more detail, see the documentation.