Tag Info

New answers tagged

0

From my experience, dereffing a psql variable inside a plpgsql declaration such as in CREATE FUNCTION BEGIN or DO BEGIN results in a syntax error: /tmp $ psql -U jmindek -v action=drop psql (9.3.4) Type "help" for help. jmindek=# select :'action'; ?column? ---------- drop (1 row) jmindek=# DO $$ BEGIN RAISE INFO 'The value in variable action is ...


0

This is a case where frankly the best thing to do is call for professional help. It is a best effort basis. If you are lucky someone can help process the data in the xlog files. The same would go through at least 9.3 The xlogs are normally run when the db starts. You can't just run them against an exiting db because they are binary patch files against ...


1

You could use the shell command time postgres@db:$ time psql db -c 'SELECT 1' ?column? ---------- 1 (1 row) real 0m0.108s user 0m0.040s sys 0m0.032s Or, to combine a meta command with an SQL command, you could pipe a string to psql: postgres@db:~/script$ echo '\timing \\ SELECT 1;' | LANG=C psql Timing is on. ?column? ---------- ...


1

Ok this is kind of a stupid question, but I'll leave it in case someone else makes a similarly dumb mistake. For the record, I'm not the one who created a set of models including user instead of users. Postgres has its own table user which it holds postgres users in. When you select * from user what you're getting is the result of the postgres user table. ...


1

I ran into the same problem. To clarify what Nyxynyx hints towards in his comment, the resolution was to give permissions to access the db cluster dir (the path that follows -D in the error): chown -R postgres:postgres /var/lib/postgresql/9.1/main



Top 50 recent answers are included