eter is on:
EXECUTE fooplan(1, 'Hunter Valley', 't', 200.00);
It should log parameters: 1, 'Hunter Valley', 't', 200.00
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
nk
from links,
lateral ts_parse('default', link)
where tokid = 6)
select score, token, link from l where rank = 1;
score |token| link
---+-+
1 | www.bar.com | http://www.bar.com/bar
1 | www.foo.com | http://www.f
no pending prepared transaction either.
Can you show the exact whole message?
Do I understand correctly. Are temp tables persist in pg_class even
after trying to drop temp tables in single-user mode?
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
rphan temporary tables.
2 - I think you have a long lived session with long lived temporary
tables. Autovacuum do not freeze temporary tables and it cannot move
relfrozenxid. That's why you get wraparound. To avoid it you need to
drop unnecessary temporary tables or do VACUUM in a long lived
r
--
emp_id
emp_name
dept
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
and
only to a PostgreSQL's backend process.
pg_ctl can send a specified signal to any process. From the documentation:
pg_ctl kill signal_name process_id
Here signal_name is HUP, INT and others.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
sion than:
psql "service=foo"
?
If not, I can make a shell alias that puts the "service=$@" into the
command.
Also you can set environment variable PGSERVICE=foo in your .bashrc. Or
you can just set variable PGHOST=db-host-1.example.com. In last case you
don't need
the `%` operator, the index is found and used. Can you explain why
this is happening? As far as I can tell from the documentation, the
`<->` operator should be using the index as well.
Yes <-> operator should use a GiST index. Can you show your query and
its plan?
--
Arthur Z
to me, it won't work without setting autovacuum = on except
for Template0 database. What is your opinion?
I think you are right, autovacuum won't vacuum and analyze a table
without setting autovacuum = on. But PostgreSQL might want to force
vacuum if a table is at risk of wraparound.
sent to pgsql-docs mailing list.
1 - https://www.postgresql.org/account/comments/new/10/libpq-ssl.html/
2 - https://www.postgresql.org/docs/10/static/libpq-ssl.html
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
ch for
pg_stat_statements cases.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
11 matches
Mail list logo