48347's questions

Considerando a declaração do Oracle ALTER SYSTEM KILL SESSION ...como... até certo ponto comparável à declaração do PostgreSQL SELECT pg_terminate_backend():

Você conhece alguma analogia do Oracle (melhor que ALTER SYSTEM KILL SESSION) para o PostgreSQL SELECT pg_cancel_backend()?

Referência: 9.26. Funções de administração do sistema (Documentação do PostgreSQL)

pg_terminate_backend

Encerrar um back-end. Você pode executar isso em outro back-end que tenha exatamente a mesma função do usuário que está chamando a função. Em todos os outros casos, você deve ser um superusuário.

pg_cancel_backend

Cancelar a consulta atual de um back-end . Você pode executar isso em outro back-end que tenha exatamente a mesma função do usuário que está chamando a função. Em todos os outros casos, você deve ser um superusuário.

O meu MaximumUsedTransactionIDsparece continuar crescendo indefinidamente, mas tenho essas evidências me sugerindo que talvez não devesse estar acontecendo dessa maneira:

$ PGPASSWORD=$MY_USER_LAND_RDS_SUPER_USER_PASSWORD psql -h $MY_RDS_INSTANCE -d
my_main_data_base -U $MY_USER_LAND_RDS_SUPER_USER
psql (9.5.8, server 9.5.10)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 
256, compression: off)
Type "help" for help.

my_main_data_base=> SELECT datname FROM pg_database;
     datname
-------------------
 template0
 rdsadmin
 template1
 postgres
 my_main_data_base
 another_data_base
(6 rows)

my_main_data_base=> VACUUM FREEZE; SELECT relname, age(relfrozenxid) AS xid_ag
e FROM pg_class JOIN pg_stat_all_tables USING (relname) ORDER BY xid_age DESC 
LIMIT 5;
VACUUM
       relname        | xid_age
----------------------+---------
 pg_toast_1150794     |   63707
 a_user_table         |   63707
 another_user_table   |   63707
 pg_toast_1223948     |   63707
 pg_toast_1223998     |   63707
(5 rows)

my_main_data_base=> \q
$ PGPASSWORD=$MY_USER_LAND_RDS_SUPER_USER_PASSWORD psql -h $MY_RDS_INSTANCE -d
another_data_base -U $MY_USER_LAND_RDS_SUPER_USER
psql (9.5.8, server 9.5.10)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 
256, compression: off)
Type "help" for help.

another_data_base=> VACUUM FREEZE; SELECT relname, age(relfrozenxid) AS xid_ag
e FROM pg_class JOIN pg_stat_all_tables USING (relname) ORDER BY xid_age DESC 
LIMIT 5;
VACUUM
      relname       | xid_age
--------------------+---------
 pg_toast_2964      |   12350
 pg_toast_3592      |   12350
 pg_toast_2396      |   12350
 pg_db_role_setting |   12350
 pg_authid          |   12350
(5 rows)

another_data_base=> \q
$ _

$MY_USER_LAND_RDS_SUPER_USERé o que o AWS RDS me oferece como superusuário . É um superusuário do ponto de vista do RDS, mas não é um superusuário do ponto de vista do PostgreSQL.

Eu esperaria que agora tivesse MaximumUsedTransactionIDsdiminuído, mas isso não acontece. Ainda está por volta de ~80.000.000.

Eu planejei que, depois que ele chegar, 100.000.000eu fork uma versão de desenvolvimento da instância do RDS, onde a farei para que a AWS inicialize o autovacuum processo nela.

Perguntas

1. O que está acontecendo com MaximumUsedTransactionIDs? Por que não encolhe?

2. Vai autovacuumcuidar de MaximumUsedTransactionIDsuma vez inicializado?

3. É autovacuumirrelevante no meu cenário porque executo manualmente VACUUM FREEZEs não qualificados de tempos em tempos em todos os meus bancos de dados de terras do usuário?

4. Devo simplesmente ignorar MaximumUsedTransactionIDs?

5. Posso de alguma forma me conectar ao banco de dados rdsadminpara SELECT age(relfrozenxid) lá?

EDIT , atendendo sua primeira solicitação, adicionando...

$ PGPASSWORD=$MY_USER_LAND_RDS_SUPER_USER_PASSWORD psql -h $MY_RDS_INSTANCE -d
my_main_data_base -U $MY_USER_LAND_RDS_SUPER_USER
psql (9.6.6, server 9.5.10)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 
256, compression: off)
Type "help" for help.

postgresql=> SELECT datname, datfrozenxid FROM pg_database;
     datname       | datfrozenxid
-------------------+--------------
 template0         |         1822
 rdsadmin          |         1822
 template1         |         1822
 postgres          |         1822
 my_main_data_base |     76628948
 another_data_base |     76681257
(6 rows)

postgresql=> \q
$ _

Eu gostaria de marcar muitas consultas e principalmente visualizar tarefas de atualização de visualização como baixa prioridade no meu RDBMS, da mesma forma que executo o navegador da Web na máquina local como baixa prioridade (porque JS, CSS, GIF animado não merecem fatias de tempo de CPU) , da mesma forma que faço para compilações de software C/C++, usando nicesupervisores Darwin e Linux.

Posso fazer isso?

Posso fazer isso no Vanilla PostgreSQL?

Eu poderia até combinar a priorização inicial do trabalho com o aumento da prioridade normal após um determinado tempo limite? Rodovias como analogia do mundo real: em uma situação normal, existem faixas de tráfego lento e faixas de tráfego rápido; mas em uma situação de tráfego intenso, todas as faixas ficam relativamente lentas, a menos que seja para um trabalho excepcional de serviços de emergência muito específico que se apropria da faixa.

Isso é um descuido para a necessidade de outra família de DBMS (oo, colunar, dwh...)?

No Oracle 11, o que acontece se eu deixar sys.aud$ficar inchado para absorver o todo SYSTEM TABLESPACE?

Ele começa a reescrever os registros mais antigos? O Oracle pode ser configurado para fazer isso?

Ele para de auditar? O Oracle pode ser configurado para substituir os registros mais antigos?

O SGBD falha? Parece que não, isso impedirá outras ações até que um operador lide com a situação?

Link para a longa história aconteceu antes (e razão para ter) esta pergunta.

A AWS já faz vacuumloinstâncias do PostgreSQL RDS?

Como você deve ter notado, como um banco de dados totalmente gerenciado como um produto de serviço, o AWS Relational Data base Service (RDS) restringe a execução de comandos userland.

Eu estava preparando um banco de dados de produção e minha pg_largeobjecttabela inchou para 40% de toda a capacidade do dispositivo virtual de persistência.

Como posso executar vacuumlo(lindamente bem explicado em outra pergunta do DBA.SE aqui ) em uma instância do RDS executando o banco de dados PostgreSQL?

Como eu poderia dar uma olhada no conteúdo do LOB?

\d ticketgrantingticket

              Table "public.ticketgrantingticket"
          Column           |          Type          | Modifiers 
---------------------------+------------------------+-----------
id                         | character varying(765) | not null
number_of_times_used       | numeric(10,0)          | 
creation_time              | numeric(19,0)          | 
last_time_used             | numeric(19,0)          | 
previous_last_time_used    | numeric(19,0)          | 
ticketgrantingticket_id    | character varying(765) | 
expiration_policy          | oid                    | 
authentication             | oid                    | 
services_granted_access_to | oid                    | 
expired                    | boolean                | 
proxied_by                 | character varying(1)   | 
Indexes:
    "ticketgrantingticket_pkey" PRIMARY KEY, btree (id)

SELECT expiration_policy, 
       authentication, 
       services_granted_access_to 
FROM ticketgrantingticket LIMIT 2;

 expiration_policy | authentication | services_granted_access_to 
-------------------+----------------+----------------------------
           1165742 |        1165743 |                    1165744
           1165757 |        1165758 |                    1165759
(2 rows)

Isso mostra esses números por padrão.

Até agora, encontrei isso que acho que não está funcionando corretamente no meu cliente de alguma forma:

SELECT expiration_policy, 
       encode(authentication::bytea, 'escape'),
       services_granted_access_to 
FROM ticketgrantingticket LIMIT 2;

ERROR:  cannot cast type oid to bytea
LINE 1: SELECT expiration_policy, encode(authentication::bytea, 'esc...

Eu posso ver o mesmo no pgAdmin III.

Estou esperando blobs lá porque o IINM oidpode ser usado como uma referência de objeto grande. Estamos usando oidporque não sabíamos o que estávamos fazendo. Eu até agora avaliei que uma dessas três colunas será convertida de forma segura e lucrativa para bytea, mas não estou conseguindo espionar o conteúdo das outras duas colunas no sistema de origem (não postgres), então decido espioná-las neste (postgres ) sistema de destino.

Eu tenho executado um tipo de esquema intensivo, descartando e criando em um servidor PostgreSQL, mas agora reclama ..:

WARNING:  out of shared memory
ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.

Mas o problema permanece se o PostgreSQL for reiniciado com service postgresql restart, suspeito que max_locks_per_transaction não ajustará nada.

Estou um pouco estranho porque as listas de solução de problemas para esse erro não estão funcionando para mim.

MAIS INFO 1409291350: Faltam alguns detalhes mas mantenho o resultado do SQL principal.

postgres=# SELECT version();
PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2,
 64-bit

E:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:        14.04
Codename:       trusty