kdb part error while loading splayed tables from HDB - kdb

I am saving a table which is enumerated and to be splayed on my hdb. After which we load the hdb directory
There was a corruption which caused
'2022.01.01T00:00:01.000 part
(.Q.L) error"
https://code.kx.com/q/ref/dotq/#ql-load/
This is due to load, and I tried corrupting partition to replicate:
Corrupted .d file
Corrupted splayed column(s)
Removed entire partition
Most of the above cases are handled in our exception.
".\2022.01.1\tbl. OS reports: No such file or directory"
but I couldn't replicate the use case where .Q.l happened nor find why it happened from my logs.
Can someone please suggest what kind of corruption could have caused the part error during load.

One possible cause would be a partition folder without correct read permissions:
$ mkdir -p badHDB/2001.01.01/tab1
$ mkdir -p badHDB/20011.01.01/tab2
$ mkdir -p badHDB/2002.01.01
$ chmod 000 badHDB/2002.01.01
Running it we see the error:
q badHDB
'part
[2] (.Q.L)
[0] \l badHDB
You could write a small function to try to narrow down the issues:
// https://code.kx.com/q/ref/system/#capture-stderr-output
q)tmp:first system"mktemp"
q)tab:flip `part`date`osError`files`error!flip {d:1_string x;{y:string y;(y;"D"$y),{r:system x;$[0~"J"$last r;(0b;-1_r;"");(1b;();first r)]} "ls ",x,"/",y," > ",tmp," 2>&1;echo $? >> ",tmp,";cat ",tmp}[d] each key x} `:badHDB
This would result in:
part date osError files error
-----------------------------------------------------------------------------------------------------------
"2001.01.01" 2001.01.01 0 ,"tab1" ""
"20011.01.01" 0 ,"tab2" ""
"2002.01.01" 2002.01.01 1 () "ls: cannot open directory 'badHDB/2002.01.01': Permission denied"
For a larger HDB filter down to partitions with issues:
select from tab where or[null date;osError]

Related

Problems encountered in recovering three tables from a dump file

I'm trying to restore tables from a dump file. It's illustrated by a footnote in the paper "VCCFinder-Finding Potential Vulnerabilities in Open-Source Projects to Assist Code Audits", that the dump file that the team created with pg_dump could be read with pg_restore. As it's shown in paper footnote with red line to emphasize. That's where I've started.
1. Use pg_restore command
By typing the command mentioned in your paper: VCCFinder: Finding Potential Vulnerabilities in Open-Source Projects to Assist Code Audits:
pg_restore -f vcc_base I:\OneDrive\PractiseProject\x_prjs\m_firmware_scan\m_firmware_scan.ref\vcc-database\vccfinder-database.dump
Windows CMD had returned an error message:
pg_restore: error: input file appears to be a text format dump. Please use psql.
As I had tried the operation in different version, including v14.4, v9.6, v9.4 and v9.3, the outcome is the same error message.
2.Use psql command
Then I turned to another direction: using psql. After typing command,
psql -v ON_ERROR_STOP=1 -U postgres < I:\OneDrive\PractiseProject\x_prjs\m_firmware_scan\m_firmware_scan.ref\vcc-database\vccfinder-database.dump
apart from postgreSQL 14.4 environment, the returned error message is:
psql: SCRAM authentication requires libpq version 10 or above
Under postgreSQL 14.4 environment, the returned message became:
SET
SET
SET
SET
SET
SET
ERROR: schema "export" already exists
If I remove the -v ON_ERROR_STOP=1 option, and returned message would be like this:
SET
SET
SET
SET
SET
SET
ERROR: schema "export" already exists
SET
SET
SET
ERROR: type "public.hstore" does not exist
LINE 27: patch_keywords public.hstore
^
ERROR: relation "cves" already exists
ERROR: relation "repositories" already exists
ERROR: relation "commits" does not exist
invalid command \n
invalid command \N
invalid command \N
...
(Solved) I have tried to solve the unreadable code problem shown in above error messages by typing chcp 65001, chcp 437 and etc to change character set into UTF8 or American English in Windows CMD, but it's not helpful. But after viewing the source code of the dump file in Visual Studio, it's not difficult to infer that those error messages were caused by psql commands in the dump file.
After the error messages became understandable, I focused on one particular error message:
ERROR: type "public.hstore" does not exist
LINE 27: patch_keywords public.hstore
So I manually created a "hstore" type below the "pulic SCHEMA", after that error messages turned into these:
SET
SET
SET
SET
SET
SET
SET
ERROR: schema "export" already exists
SET
SET
SET
ERROR: relation "commits" already exists
ERROR: relation "cves" already exists
ERROR: relation "repositories" already exists
ERROR: malformed record literal: ""do"=>"1", "if"=>"0", "asm"=>"41", "for"=>"5", "int"=>"13", "new"=>"0", "try"=>"0", "auto"=>"0", "bool"=>"0", "case"=>"0", "char"=>"1", "else"=>"0", "enum"=>"0", "free"=>"0", "goto"=>"0", "long"=>"15", "this"=>"0", "true"=>"0", "void"=>"49", "alloc"=>"0", "break"=>"0", "catch"=>"0", "class"=>"0", "const"=>"0", "false"=>"0", "float"=>"0", "short"=>"0", "throw"=>"0", "union"=>"0", "using"=>"0", "while"=>"1", "alloca"=>"0", "calloc"=>"0", "delete"=>"0", "double"=>"0", "extern"=>"4", "friend"=>"0", "inline"=>"18", "malloc"=>"0", "public"=>"0", "return"=>"4", "signed"=>"1", "sizeof"=>"0", "static"=>"32", "struct"=>"4", "switch"=>"0", "typeid"=>"0", "default"=>"0", "mutable"=>"0", "private"=>"0", "realloc"=>"0", "typedef"=>"0", "virtual"=>"0", "wchar_t"=>"0", "continue"=>"0", "explicit"=>"0", "operator"=>"0", "register"=>"0", "template"=>"0", "typename"=>"0", "unsigned"=>"23", "volatile"=>"23", "namespace"=>"0", "protected"=>"0", "const_cast"=>"0", "static_cast"=>"0", "dynamic_cast"=>"0", "reinterpret_cast"=>"0""
DETAIL: Missing left parenthesis.
CONTEXT: COPY commits, line 1, column patch_keywords: ""do"=>"1", "if"=>"0", "asm"=>"41", "for"=>"5", "int"=>"13", "new"=>"0", "try"=>"0", "auto"=>"0", "bo..."
ERROR: syntax error at or near "l022_save"
LINE 1: l022_save, pl022_load, s);
^
invalid command \n
invalid command \N
invalid command \N
...
Now the three tables have been created, but there is no content in them.
3. Install hstore
After searching for "hstore"hstore type does not exist with hstore installed postgresql, I realized that the "hstore" should be installed, but not be manually created. So I typed this in psql command line:
postgres=# create EXTENSION hstore; And there were new error messages:
SET
SET
SET
SET
SET
SET
SET
ERROR: schema "export" already exists
SET
SET
SET
CREATE TABLE
ERROR: relation "cves" already exists
ERROR: relation "repositories" already exists
ERROR: missing data for column "hunk_count"
CONTEXT: COPY commits, line 23201: "11388700 178 \N other_commit 1d6198c3b01619151f3227c6461b3d53eeb711e5\N blueswir1#c046a42c-6fe2-441..."
ERROR: syntax error at or near "l022_save"
LINE 1: l022_save, pl022_load, s);
^
invalid command \n
invalid command \N
invalid command \N
...
And still, there is no content in those three tables.
4. Generate and view tables
After looking into the source code of the dump file, and trying to fix the "hunk_count" problem but end up with failure. It occurs to me that the above error messages just caused by one paticular row of code. So I had deleted the row and the old error messages were gone but there were new error messages caused by another row. Evetually I have deleted 10 rows in total, comparing to the total row number: 351409, those deleted parts are negligible. And three tables weren't empty anymore, as it's shown in pgAdmin 4.
However, the pgADmin only demonstrated the structure of those tables, I still didn't know how to view the content in them. By refering to 2 Ways to View the Structure of a Table in PostgreSQL, I typed
SELECT
*
FROM
export.repositories/ export.cves/ export.commits
WHERE
TRUE
to generate and view corresponding tables in pgAdmin 4. For example, final cve table:
5. In the end
Looking back at these steps, these are all easy steps, but for a guy who was not familiar with the tools or operations, it could cost several days to search and type, step by step for one simple purpose. I wish this post could be useful to someone like me.
However, I am not so familiar with psql commands or anything about postgreSQL, as a matter of fact, I had never used them before. So I'm wondering if someone could point out some mistakes I may have made in those attempts, or provide some suggestions for my dilemma.
First , ensure your dump format.
Try to read header (first 5 chars) of dump file.
If it is signed as PGDMP then it is binary/custom dump else it is sql (human readable format).
- use pg_restore for binary dump import.
$ pg_restore -U postgres -d <dbname> file.dump
- use psql to import plain text sql dump.
$ psql -U postgres -d <dbname> < file.dump
Solved, as I've demonstrated above.

mapping values are not allowed in this context in "<unicode string>"

In my loop, I run a dbt command and save the output to a .yml file. The following command works and generates a schema in my .yml file accurately:
for file in models/l30_mart/*.sql; do
table=$(basename "$file" .sql)
dbt run-operation generate_model_yaml --args "{\"model_name\": \"$table\"}" > test.yml
done
However, in the example above, I am saving the test.yml file in the root directory. When I try to save the file in another path for example models/l30_mart/test.yml like this, it doesn't work:
for file in models/l30_mart/*.sql; do
table=$(basename "$file" .sql)
dbt run-operation generate_model_yaml --args "{\"model_name\": \"$table\"}" > models/l30_mart/test.yml
done
In this case, when I open the test.ymlfile, I see this:
12:06:42 Running with dbt=1.0.1
12:06:43 Encountered an error:
Compilation Error
The schema file at models/l30_mart/test.yml is invalid because no version is specified. Please consult the documentation for more information on schema.yml syntax:
https://docs.getdbt.com/docs/schemayml-files
What am I missing out on?
If I try something like this to save different files with the extracted tablename variable as the filename, it also doesn't work:
for file in models/l30_mart/*.sql; do
table=$(basename "$file" .sql)
dbt run-operation generate_model_yaml --args "{\"model_name\": \"$table\"}" > models/l30_mart/$table.yml
done
In this case, the files either have this output:
20:39:44 Running with dbt=1.0.1
20:39:45 Encountered an error:
Compilation Error
The schema file at models/l30_mart/**firsttable.yml** is invalid because no version is specified. Please consult the documentation for more information on schema.yml syntax:
https://docs.getdbt.com/docs/schemayml-files
or this (eg in the secondtablename.yml file):
20:39:48 Running with dbt=1.0.1
20:39:49 Encountered an error:
Parsing Error
Error reading dbt_4flow: l30_mart/firstablename.yml - Runtime Error
Syntax error near line 2
------------------------------
1 | 20:39:44 Running with dbt=1.0.1
2 | 20:39:45 Encountered an error:
3 | Compilation Error
4 | The schema file at models/l30_mart/firsttablename.yml is invalid because no version is specified. Please consult the documentation for more information on schema.yml syntax:
5 |
Raw Error:
------------------------------
mapping values are not allowed in this context
in "<unicode string>", line 2, column 31
Note that the secondtablename.yml mentions the firsttablename.yml.
I don't know dbt but the explanation that seems likely is that dbt for some reason parses all *.yml files in that target directory when you call it. Since the shell opens the pipe to the *.yml file before calling dbt, the file already exists (but initially empty) when dbt is called. Since dbt expects the file to contain a version, you get an error.
To check whether this assessment is correct, write into a temporary file:
for file in models/l30_mart/*.sql; do
target_file=$(mktemp)
table=$(basename "$file" .sql)
dbt run-operation generate_model_yaml --args "{\"model_name\": \"$table\"}" > $target_file
mv $target_file models/l30_mart/test.yml
done
(Be aware of mktemp shenanigans if you're using macOS)
Edit: Since dbt seems to be affected by the files existing, you can also try to generate all files and move them into the correct directory afterwards:
target_dir=$(mktemp -d)
for file in models/l30_mart/*.sql; do
table=$(basename "$file" .sql)
dbt run-operation generate_model_yaml --args "{\"model_name\": \"$table\"}" > $target_dir/$table.yml
done
mv $target_dir/*.yml models/l30_mart/
rmdir $target_dir

Postgresql 11.1: "Problem running post-install step. Installation may not complete correctly. Error with configuration or permissions."

I checked the log file and I think this is the part that caused the problem:
Setting up database
[15:30:54] Configuring pg11 to point to existing data dir D:\John's Files\My Documents\Code\Databases\PostgreSQL\data\pg11
Setting PostgreSQL port
= 5432
Executing C:\Installed Software\Developer Software\PostgreSQLv11.1/pgc config pg11 --datadir "D:\John's Files\My Documents\Code\Databases\PostgreSQL\data\pg11"
Script exit code: 1
Script output: ################################################
# FATAL SQL Error in check_release
# SQL Message = near "s": syntax error
# SQL Statement = SELECT r.component FROM releases r, versions v
WHERE r.component = v.component
AND r.component LIKE '%D:\John's Files\My Documents\Code\Databases\PostgreSQL\data\pg11%' AND v.is_current = 1
################################################
Script stderr: Program ended with an error exit code
Error with configuration or permissions. Please see log file for more information.
Problem running post-install step. Installation may not complete correctly
Error with configuration or permissions. Please see log file for more information.
I think the problem is the apostrophe in "John's". Does anyone know if that's right? Is there a fix to this problem? I don't want to rename my directory because Postgresql can't handle apostrophes.

PGLOADER error sqlite3.dll but am not using sqlite

I am trying to use pgloader for Postgresql on Windows, downloaded from http://pgloader.io/.
The reason I'm trying to use pgloader rather than COPY is that I want to do imports from delimited files with subsets of the columns from the source files to be inserted (rather than all), and in some cases, conversions from strings to dates at insertion based on the source format (or one data type to another in general).
I am having trouble getting pgloader to work at all, let alone do what I want it to do. I started by trying to get a simple load working.
I am running postgresql 9.3 portable on Windows.
I've created a test table called fish in the public schema, the database is called test.
create table fish (
fish_id int,
fish_descr varchar(20)
);
On my computer I have a file called more_fish.txt with 2 rows:
2|Sooodles
3|Poodles
(it is pipe delimited).
I want to insert those 2 rows into the fish table.
Running the following COPY works as intended and inserts the 2 rows:
copy fish FROM 'C:\Users\ShWiVeL\Desktop\more_fish.txt' delimiter '|';
So as to ensure I have the basics of pgloader down before attempting format conversions at insertion I am trying to just get the above example working using pgloader.
I am running the following in the command line (I am using Windows):
cd C:\Users\ShWiVeL\Desktop\postgresql\postgresql\PostgreSQLPortable\App\PgSQL\bin
pgloader commands.load
The commands.load file is in that bin folder (as well as pgloader.exe) and contains the following:
LOAD CSV
FROM 'C:\Users\ShWiVeL\Desktop\more_fish.txt' WITH ENCODING iso-646-us
HAVING FIELDS
(
fish_id, fish_descr
)
INTO postgresql://postgres#localhost:5432/test?fish
TARGET COLUMNS
(
fish_id, fish_descr
)
WITH truncate,
skip header = 0,
fields terminated by '|'
SET work_mem to '32 MB', maintenance_work_mem to '64 MB';
The above uses one of the examples in the pgloader documentation just modified for what I thought would be an easy test.
I get the following error:
C:\Users\ShWiVeL\Desktop>cd C:\Users\ShWiVeL\Desktop\postgresql\postgresql\PostgreSQLPortable\App\PgSQL\bin
C:\Users\ShWiVeL\Desktop\postgresql\postgresql\PostgreSQLPortable\App\PgSQL\bin>pgloader commands.load
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {26922DB9}>:
Error opening shared object "sqlite3.dll":
The specified module could not be found.
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE ] Skip this shared object and continue.
1: [RETRY ] Retry loading this shared object.
2: [CHANGE-PATHNAME] Specify a different pathname to load the shared object from.
0
(SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"sqlite3.dll" :NAMESTRING "sqlite3.dll" :HANDLE NIL :DONT-SAVE NIL))
0]
I don't see why I am getting an error re: sqlite. I did not specify that as a source database in any way.
Does anyone know how to do this very basic COPY using pgloader: (or why I'm getting the above error when running the above)
copy fish FROM 'C:\Users\ShWiVeL\Desktop\more_fish.txt' delimiter '|';
User: postgres
Port: default 5432
Database name: test
Table name: fish
Schema: public
Edit based on comments
Running pgloader --verbose commands.load had no impact.
I tried putting sqlite3.dll into the bin folder, result changed to this:
C:\Users\ShWiVeL\Desktop>cd C:\Users\ShWiVeL\Desktop\postgresql\postgresql\PostgreSQLPortable\App\PgSQL\bin
C:\Users\ShWiVeL\Desktop\postgresql\postgresql\PostgreSQLPortable\App\PgSQL\bin>pgloader --verbose commands.load
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {26922DB9}>:
Error opening shared object "libeay32.dll":
%1 is not a valid Win32 application.
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE ] Skip this shared object and continue.
1: [RETRY ] Retry loading this shared object.
2: [CHANGE-PATHNAME] Specify a different pathname to load the shared object from.
0
(SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libeay32.dll" :NAMESTRING "libeay32.dll" :HANDLE NIL :DONT-SAVE NIL))
0]
Tried downloading libeay32.dll from https://openvpn.net/release/openssl/ and putting it into the bin folder, result changed to:
C:\Users\ShWiVeL\Desktop>cd C:\Users\ShWiVeL\Desktop\postgresql\postgresql\PostgreSQLPortable\App\PgSQL\bin
C:\Users\ShWiVeL\Desktop\postgresql\postgresql\PostgreSQLPortable\App\PgSQL\bin>pgloader --verbose commands.load
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {26922DB9}>:
Problem running initialization hook #<FUNCTION (LAMBDA ()
:IN
"//vboxsrv/vagrant/src/hooks.lisp")
{2275BA15}>:
Unable to load foreign library (LIBSSL).
Error opening shared object "libssl32.dll":
The specified procedure could not be found.
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Skip this initialization hook.
0
(SB-INT:CALL-HOOKS "initialization" (#<FUNCTION (LAMBDA NIL :IN "//vboxsrv/vagrant/src/hooks.lisp") {2275BA15}> SB-BSD-SOCKETS-INTERNAL::CALL-WSA-STARTUP SB-WIN32::INITIALIZE-CONSOLE-CONTROL-HANDLER) :ON-ERROR :ERROR)
0]
(libssl32.dll is and was already in the bin folder)

error in tables while ugprading database

Recently I tried to upgrade my tiki-wiki installation from 12.2 directly to 13.1 (that's a 3 step upgrade) and got errors in 5 tables. The way I did it was
export my working db;
import it in a new -empty- one;
connect with the 13.1 installation.
In the final stage of db connection I got 5 errors and when I started my 13.1 installation I was unable to edit any page (the edit window opens blank, buttons are invisible, cursor can't be placed anywhere). I really don't know if this problem has to do with these 5 errors (yes, I have asked tiki-wiki forum, still searching there).
Then, I went back, upgraded from 12.2 to 12.3 (one step upgrade) and everything was fine (no errors during db upgrade, editing pages possible).
Are these errors (see below) really important? Could they have anything to do with new installation not working properly? Any advise that could help me resolve the issue?
The errors:
20131218_stored_queries_tiki, create table 'tiki_search_queries etc.
20140109_query_unique_name_tiki (...) Duplicate column name 'description'
20140117_monitor_tiki, create table 'tiki_user_monitors' etc
20140206_add_parser_column_tiki (...) Table'tiki_output' already exists
20140214_goals_tiki, create table 'tiki_goals' etc.
The errors like duplicate column and table already exist are safe to be ignored while upgrading Tiki. You can mark them in the installer using the checkboxes. I don’t think they have anything to do with your blank page issue. Check your server log for fatal errors. Most common reason for blank page is low memory limit. But can be something else too.
Please make sure that the ownership and permissions of the upgraded files match what was there originally. Use:
chown -R name.name *
to change the file ownership where [name] matches what was there before and set file permissions with:
Directories:
find . -type d -exec chmod 755 {} \;
Files:
find . -type f -exec chmod 644 {} \;
some servers use 775 and 664.