meson setup build --prefix=/usr/local/pgsql cd build ninja su ninja install adduser postgres mkdir -p /usr/local/pgsql/data chown postgres /usr/local/pgsql/data su - postgres /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start /usr/local/pgsql/bin/createdb test /usr/local/pgsql/bin/psql test
A versão longa é o restante desta seção.
Configuração
A primeira etapa do procedimento de instalação é configurar a
árvore de construção para o sistema, e escolher as opções desejadas.
Para criar e configurar o diretório de construção, pode-se começar
com o comando meson setup.
meson setup build
O comando de configuração recebe como argumento
builddir e srcdir.
Se srcdir não for fornecido,
o Meson irá deduzir o
srcdir baseado no diretório corrente
e no local de meson.build.
O builddir é obrigatório.
Executar meson setup carrega o arquivo de
configuração de construção e configura o diretório de construção.
Além disso, também pode-se passar diversas opções de compilação
para o Meson.
Algumas opções comumente utilizadas são mencionadas nas seções
subsequentes. Por exemplo:
# configuração com um prefixo de instalação diferente meson setup build --prefix=/home/user/pg-install # configuração para gerar uma versão de depuração meson setup build --buildtype=debug # configuração para construir com suporte a OpenSSL meson setup build -Dssl=openssl
A configuração do diretório de construção é uma etapa realizada
apenas uma vez.
Para reconfigurar antes de uma nova construção, pode-se
simplesmente usar o comando meson configure
meson configure -Dcassert=true
As opções de linha de comando comumente usadas em
meson configure estão explicadas em
Opções do meson setup.
Construção
Por padrão, o Meson usa a ferramenta de
construção Ninja.
Para construir o PostgreSQL a partir do
código-fonte usando o Meson, pode-se
simplesmente usar o comando ninja no diretório
de construção.
ninja
O Ninja irá detectar automaticamente o número de
CPUs do computador e irá se paralelizar de acordo.
Pode-se alterar o número de processos paralelos usados com o
argumento de linha de comando -j.
É importante notar que, após a etapa de configuração inicial,
ninja será o único comando que se precisa
digitar para compilar.
Independentemente de como for alterada a árvore de código-fonte
(exceto movendo-a para um local completamente novo), o
Meson irá detectar as alterações
e irá se regenerar de acordo.
Isto é especialmente útil havendo vários diretórios de construção.
Geralmente, uma delas é usada para desenvolvimento
(a versão “debug”), e as outras apenas ocasionalmente
(como uma construção para “análise estática”).
Qualquer configuração pode ser criada simplesmente acessando o
diretório correspondente e executando o Ninja.
Caso se deseje construir com uma ferramenta diferente do
ninja, pode-se usar o configure
com a opção --backend para selecionar o que se deseja
usar e, em seguida, compilar usando meson compile.
Para saber mais sobre estas ferramentas e outros argumentos que se
pode fornecer ao ninja, veja
Construção a partir do fonte.
Testes de regressão
Se for desejado testar o servidor recém-criado antes de instalá-lo, podem ser executados testes de regressão neste momento. Os testes de regressão são um conjunto de testes para verificar se o PostgreSQL está sendo executado na máquina da maneira que os desenvolvedores esperavam que fosse. Para isto, deve ser executado:
meson test
(não funciona quando executado pelo usuário root; deve ser executado por um usuário sem privilégios.) Veja Capítulo 31 para obter informações detalhadas sobre como interpretar os resultados do teste. Este teste poderá ser repetido posteriormente executando o mesmo comando.
Para executar os testes pg_regress e
pg_isolation_regress em uma instância do
PostgreSQL em execução, deve-se especificar
--setup running como argumento para
meson test.
Instalação dos arquivos
Se estiver sendo atualizado um sistema existente, será necessário ler Atualização do agrupamento de bancos de dados do PostgreSQL, que contém instruções sobre como atualizar um agrupamento de bancos de dados (cluster).
Após construir o PostgreSQL, pode-se
instalá-lo simplesmente executando o comando
ninja install.
ninja install
Isto irá instalar os arquivos nos diretórios especificados em Configuração. Certifique-se de possuir as permissões apropriadas para escrever nesta área. Pode ser necessário executar esta etapa como root. Como alternativa, pode-se criar os diretórios de destino com antecedência e providenciar a concessão das permissões apropriadas. A instalação padrão fornece todos os arquivos de cabeçalho necessários para o desenvolvimento de aplicações cliente, bem como para o desenvolvimento de programas do lado servidor, como funções personalizadas ou tipos de dados escritos em C.
ninja install deve funcionar na maior parte das
vezes, mas se for desejado usar mais opções (tal como
--quiet para suprimir saídas extras),
pode-se usar meson install em seu lugar.
Pode-se aprender mais sobre meson install
e suas opções na documentação do Meson.
Desinstalação:
Para desfazer a instalação pode-se usar o comando
ninja uninstall.
Limpeza:
Após a instalação, pode-se liberar espaço em disco removendo os
arquivos construídos da árvore de código-fonte usando o comando
ninja clean.
.
As opções de linha de comando do meson setup
estão explicadas abaixo.
Esta lista não é completa
(deve-se executar meson configure --help
para obter uma lista completa).
As opções não cobertas aqui destinam-se a casos de uso avançados,
e estão documentadas em
Documentação do Meson.
Estes argumentos podem ser usados com
meson setup também.
Estas opções controlam onde ninja install
(ou meson install) irá colocar os arquivos.
A opção --prefix (veja exemplo em
Versão curta) é suficiente
na maior parte das vezes.
Havendo necessidades especiais, será possível personalizar os
subdiretórios de instalação com as outras opções descritas nesta
seção.
Entretanto, deve-se ter cuidado, porque alterar as localizações
relativas dos diferentes subdiretórios pode tornar a instalação
não realocável, significando que não será possível movê-la após
a instalação.
(Os locais man e doc
não são afetados por esta restrição.)
Para instalações relocáveis, pode ser usada a opção
-Drpath=false descrita posteriormente.
--prefix=PREFIXO #
Instala todos os arquivos no diretório
PREFIXO em vez de
/usr/local/pgsql (em sistemas baseados
em Unix) ou
letra da unidade corrente:/usr/local/pgsqlPREFIXO.
--bindir=DIRETÓRIO #
Define o diretório para os programas executáveis. O padrão é
PREFIXO/bin
--sysconfdir=DIRETÓRIO #
Define o diretório para vários arquivos de configuração.
PREFIXO/etc
--libdir=DIRETÓRIO #
Define o diretório para instalar as bibliotecas e os módulos
carregáveis dinamicamente. O padrão é
PREFIXO/lib
--includedir=DIRETÓRIO #
Define o diretório para instalar os arquivos de cabeçalho das
linguagens C e C++.
O padrão é
PREFIXO/include
--datadir=DIRETÓRIO #
Define o diretório para arquivos de dados somente de leitura
usados pelos programas instalados.
O padrão é
PREFIXO/share
--localedir=DIRETÓRIO #
Define o diretório para instalação dos dados de localidade,
em particular os arquivos do catálogo de tradução de mensagens.
O padrão é
DATADIR/locale
--mandir=DIRETÓRIO #
As páginas do manual (man pages)
que vêm com o PostgreSQL são
instaladas neste diretório, em seus respectivos subdiretórios
man.
O padrão é xDATADIR/man
Foram tomados cuidados para possibilitar a instalação do
PostgreSQL em locais de instalação
compartilhados (como /usr/local/include)
sem interferir no espaço de nomes do resto do sistema.
Primeiro, a cadeia de caracteres
“/postgresql”
é anexada automaticamente a datadir,
sysconfdir e docdir,
a menos que o nome do diretório totalmente expandido já contenha
a cadeia de caracteres “postgres”,
ou “pgsql”.
Por exemplo, se for escolhido /usr/local
como prefixo, a documentação será instalada em
/usr/local/doc/postgresql, mas se o prefixo
for /opt/postgres, então será instalada em
/opt/postgres/doc.
Os arquivos de cabeçalho C públicos das
interfaces cliente são instalados em
includedir, e são limpos quanto a espaço de nomes.
Os arquivos de cabeçalho internos, e os arquivos de cabeçalho do
servidor, são instalados em diretórios privados em
includedir.
Consulte a documentação de cada interface para obter informações
sobre como acessar seus arquivos de cabeçalho.
Finalmente, também é criado um subdiretório privado, caso seja
apropriado, em libdir, para módulos carregáveis
dinamicamente.
As opções descritas nesta seção permitem a construção de vários
recursos opcionais do PostgreSQL.
A maioria delas requer software adicional, conforme descrito em
Requisitos, e serão ativadas
automaticamente se for encontrado o software necessário.
Pode-se alterar manualmente este comportamento definindo estes
recursos como enabled para torná-los requeridos,
ou disabled para não incluí-los na construção.
Para especificar opções específicas do
PostgreSQL, o nome da opção deve ter o
prefixo -D.
-Dnls={ auto | enabled | disabled } #
Ativa o suporte ao idioma nativo
(Native Language Support,
NLS), ou seja, a capacidade do programa
mostrar as mensagens em um idioma diferente do inglês.
O padrão é auto e será ativado automaticamente
se for encontrada uma implementação da
API Gettext.
-Dplperl={ auto | enabled | disabled } #
Constrói a linguagem do lado servidor
PL/Perl.
O padrão é auto.
-Dplpython={ auto | enabled | disabled } #
Constrói a linguagem do lado servidor
PL/Python.
O padrão é auto.
-Dpltcl={ auto | enabled | disabled } #
Constrói a linguagem do lado servidor
PL/Tcl.
O padrão é auto.
-Dtcl_version=TCL_VERSION #Especifica a versão do Tcl a ser usada ao construir o PL/Tcl.
-Dicu={ auto | enabled | disabled } #
Constrói com suporte para a biblioteca
ICU,
ativando o uso dos recursos de ordenação ICU
(veja Suporte a ordenação).
O padrão é auto e requer a instalação do
pacote ICU4C.
A versão mínima requerida do ICU4C
é no momento a 4.2.
-Dllvm={ auto | enabled | disabled } #
Constrói com suporte para compilação JIT
baseada em LLVM
(veja Compilação Just-in-Time (JIT)).
Isto requer a instalação da biblioteca
LLVM.
A versão mínima requerida da LLVM
é no momento a 14.
O padrão é disabled.
O llvm-config
será usado para encontrar as opções de compilação requeridas.
O llvm-config, e depois
llvm-config-$version para todas as versões
com suporte, serão procurados no PATH.
Se isto não resultar no programa desejado, deve-se usar
LLVM_CONFIG para especificar o caminho para o
llvm-config correto.
-Dlz4={ auto | enabled | disabled } #
Constrói com suporte a compressão LZ4.
O padrão é auto.
-Dzstd={ auto | enabled | disabled } #
Constrói com suporte a compressão Zstandard.
O padrão é auto.
-Dssl={ auto | BIBLIOTECA }
#
Constrói com suporte para conexões SSL
(encriptadas).
A única BIBLIOTECA com suporte é a
openssl.
Esta opção requer a instalação do pacote OpenSSL.
Construir com esta opção fará com que seja verificado se os
arquivos de cabeçalho e bibliotecas necessários estão presentes
para garantir que a instalação do OpenSSL
seja adequada antes de prosseguir.
O padrão é auto.
-Dgssapi={ auto | enabled | disabled } #
Constrói com suporte para autenticação
GSSAPI.
É necessário instalar o
MIT Kerberos
para instalar o GSSAPI.
Em muitos sistemas operacionais, o sistema GSSAPI
(uma parte da instalação do MIT Kerberos)
não está instalado em um local procurado por padrão
(por exemplo, /usr/include ou
/usr/lib),
Nesses casos, o PostgreSQL irá
consultar o pkg-config para detectar as
opções necessárias do compilador e do vinculador.
O padrão é auto.
O meson configure irá verificar os
arquivos de cabeçalho e bibliotecas necessários para garantir
que a instalação do GSSAPI seja adequada
antes de prosseguir.
-Dldap={ auto | enabled | disabled } #
Constrói com suporte ao
LDAP
para autenticação e procura de parâmetros de conexão (veja
LDAP Lookup of Connection Parameters e
Autenticação LDAP para obter mais informações).
No Unix, esta opção
requer a instalação do pacote OpenLDAP.
No Windows, é usada a
biblioteca padrão WinLDAP.
O padrão é auto.
O meson configure irá verificar os
arquivos de cabeçalho e bibliotecas necessários para garantir
que a instalação do OpenLDAP seja adequada
antes de prosseguir.
-Dpam={ auto | enabled | disabled } #
Constrói com suporte ao
PAM
(Pluggable Authentication Modules).
O padrão é auto.
-Dbsd_auth={ auto | enabled | disabled } #
Constrói com suporte para autenticação
BSD.
(No momento, a estrutura de autenticação BSD
está disponível apenas no OpenBSD.)
O padrão é auto.
-Dsystemd={ auto | enabled | disabled } #
Constrói com suporte para notificações de serviço
systemd.
Isto melhora a integração se o servidor for iniciado sob o
systemd mas não tem impacto caso
contrário;
veja Ativação do servidor de banco de dados para obter mais informações.
O padrão é auto.
Para usar esta opção, é necessário instalar a
libsystemd e os arquivos de
cabeçalho associados.
-Dbonjour={ auto | enabled | disabled } #
Constrói com suporte para descoberta automática de serviços
Bonjour.
O padrão é auto e requer suporte ao
Bonjour no sistema
operacional.
Recomendado no macOS.
-Duuid=BIBLIOTECA #
Constrói o módulo uuid-ossp
(que fornece funções para gerar UUIDs),
usando a biblioteca UUID especificada.
A BIBLIOTECA deve ser uma entre:
none para não construir o módulo uuid.
Este é o padrão.
bsd para usar as funções de UUID encontradas
no FreeBSD e em alguns
outros sistemas derivados do BSD.
e2fs para usar a biblioteca UUID criada pelo
projeto e2fsprogs; esta biblioteca está
presente na maioria dos sistemas
Linux e no
macOS, e também pode
ser obtida para outras plataformas.
ossp para usar a
biblioteca OSSP UUID
-Dlibcurl={ auto | enabled | disabled } #
Constrói com suporte para
libcurl
para fluxos de cliente
OAuth 2.0.
É necessária a versão 7.61.0, ou posterior, da
Libcurl para utilizar esta funcionalidade.
Ao construir, será verificado se os arquivos de cabeçalho e
bibliotecas necessários estão presentes para garantir que a
instalação do Curl seja adequada
antes de prosseguir.
-Dliburing={ auto | enabled | disabled } #
Constrói com liburing, ativando o suporte a
io_uring
para E/S assíncrona.
O padrão é auto.
Para usar uma instalação da liburing que
esteja em um local não usual, pode-se definir variáveis de
ambiente relacionadas ao pkg-config
(veja a documentação).
-Dlibnuma={ auto | enabled | disabled } #
Constrói com suporte para libnuma para
suporte básico a
NUMA (Non-Uniform Memory Access).
Tem suporte apenas nas plataformas onde a biblioteca
libnuma esteja implementada.
O padrão é auto.
-Dlibxml={ auto | enabled | disabled } #
Constrói com libxml2, ativando o suporte
a SQL/XML.
O padrão é auto.
É requerida a versão 2.6.23, ou posterior, da
Libxml2
para esta funcionalidade.
Para usar uma instalação da libxml2 que
esteja em um local não usual, pode-se definir variáveis de
ambiente relacionadas ao pkg-config
(veja a documentação).
-Dlibxslt={ auto | enabled | disabled } #
Constrói com a libxslt, ativando o módulo
xml2
para realizar transformações XSL de XML
A opção -Dlibxml também deve ser especificada.
O padrão é auto.
-Dselinux={ auto | enabled | disabled } #Constrói com suporte a SELinux, ativando a extensão sepgsql.
-Dreadline={ auto | enabled | disabled } #
Permite o uso da biblioteca Readline
(e da libedit também).
Esta opção está definida como auto por padrão
e ativa a edição da linha de comando e o histórico no
psql sendo altamente recomendada.
-Dlibedit_preferred={ true | false } #
Definir esta opção como true prioriza o uso
da biblioteca libedit licenciada sob
a licença BSD em vez da biblioteca
Readline licenciada sob a licença
GPL.
Esta opção só é relevante havendo as duas bibliotecas instaladas;
o padrão é false, ou seja, usar a
Readline.
-Dzlib={ auto | enabled | disabled } #
Ativa o uso da biblioteca Zlib.
Por padrão, está definida como auto e ativa
o suporte para arquivos comprimidos no
pg_dump,
pg_restore e
pg_basebackup, sendo recomendada.
--auto-features={ auto | enabled | disabled } #
Definir esta opção permite sobrescrever os valores de todas as
funcionalidades auto (funcionalidades ativadas
automaticamente quando é encontrado o software necessário).
Pode ser útil quando se deseja desativar ou ativar todos as
funcionalidades “opcionais” de uma só vez, sem ter
que defini-las manualmente.
O valor padrão para este parâmetro é auto.
--backend=FERRAMENTA #
A ferramenta padrão usado pelo Meson é o
Ninja, devendo ser suficiente para a maioria
dos casos de uso.
Entretanto, se for desejada a integração total com o
Visual Studio, a
FERRAMENTA poderá ser definida como
vs.
-Dc_args=OPTIONS #Esta opção pode ser usada para passar opções extras para o compilador C.
-Dc_link_args=OPTIONS #Esta opção pode ser usada para passar opções extras para o vinculador C.
-Dextra_include_dirs=DIRETÓRIOS #
Onde DIRETÓRIOS É uma lista de
diretórios separados por vírgulas que serão adicionados à lista
que o compilador usa para procurar arquivos de cabeçalho.
Havendo pacotes opcionais
(como o GNU Readline)
instalados em um local não padrão, é necessário usar esta opção
e provavelmente também a opção correspondente
-Dextra_lib_dirs.
Exemplo: -Dextra_include_dirs=/opt/gnu/include,/usr/sup/include.
-Dextra_lib_dirs=DIRETÓRIOS #
Onde DIRETÓRIOS é uma lista de
diretórios separados por vírgulas para procurar bibliotecas.
Provavelmente terá que ser usada esta opção (e a opção
correspondente -Dextra_include_dirs) havendo
pacotes instalados em locais não padrão.
Exemplo: -Dextra_lib_dirs=/opt/gnu/lib,/usr/sup/lib.
-Dsystem_tzdata=DIRETÓRIO
#
O PostgreSQL inclui seu próprio
banco de dados de zona horária, necessário para operações de
data e hora.
Este banco de dados de zona horária é compatível com o banco
de dados de zona horária da
IANA
fornecido por muitos sistemas operacionais, como
FreeBSD,
Linux e
Solaris, portanto,
seria redundante instalá-lo novamente.
Quando esta opção é usada, o banco de dados de zona horária
fornecido pelo sistema em DIRETÓRIO
é usado em vez do incluído na distribuição de construção do
PostgreSQL.
DIRETÓRIO deve ser especificado
como um caminho absoluto.
/usr/share/zoneinfo é um diretório
provável em alguns sistemas operacionais.
Note que a rotina de instalação não detecta dados de zona
horária incompatíveis, ou incorretos.
Se for usada esta opção, é recomendado executar os testes de
regressão para verificar se os dados de zona horária apontados
funcionam corretamente com o PostgreSQL.
Esta opção destina-se, principalmente, a distribuidores de pacotes binários que conhecem bem o sistema operacional de destino. A principal vantagem de usar esta opção, é que o pacote PostgreSQL não precisará ser atualizado sempre que qualquer uma das muitas regras locais de horário de verão mudar. Outra vantagem é que o PostgreSQL pode ser compilado de forma mais direta se os arquivos de banco de dados de zona horária não precisarem ser compilados durante a instalação.
-Dextra_version=CADEIA_DE_CARACTERES #
Acrescenta CADEIA_DE_CARACTERES
ao número da versão do PostgreSQL.
Esta opção pode ser usada, por exemplo, para marcar binários
criados a partir de instantâneos Git não
liberados, ou contendo correções personalizadas, com uma
cadeia de caracteres de versão extra, como um identificador
git describe, ou um número de versão de
distribuição do pacote.
-Drpath={ true | false } #
Esta opção está definida como true por padrão.
Se for definida como false, não irá marcar
os executáveis do PostgreSQL
indicando que devem procurar por bibliotecas compartilhadas
no diretório de bibliotecas da instalação
(veja --libdir).
Na maioria das plataformas, esta marcação usa um caminho
absoluto para o diretório da biblioteca, de modo que não será
útil se a instalação for realocada posteriormente.
Entretanto, deve ser fornecida alguma outra maneira para os
executáveis localizarem as bibliotecas compartilhadas.
Normalmente, esta opção requer a configuração do vinculador
dinâmico do sistema operacional para procurar pelo diretório
da biblioteca; veja Bibliotecas compartilhadas
para obter mais detalhes.
-DNOME_DO_BINÁRIO=CAMINHO #
Se um programa necessário para construir o
PostgreSQL (com ou sem sinalizadores
opcionais) estiver armazenado em um caminho não padrão, pode-se
especificá-lo manualmente para o meson configure.
A lista completa de programas compatíveis pode ser encontrada
executando meson configure.
Exemplo:
meson configure -DBISON=CAMINHO_PARA_O_BISON
Veja Conjunto de ferramentas para conhecer as ferramentas necessárias para a construção da documentação.
-Ddocs={ auto | enabled | disabled } #
Ativa a criação da documentação nos formatos
HTML e man.
O padrão é auto.
-Ddocs_pdf={ auto | enabled | disabled } #
Ativa a criação da documentação no formato PDF.
O padrão é auto.
-Ddocs_html_style={ simple | website } #
Controla qual folha de estilo CSS será usada.
O padrão é simple.
Se definida como website, a documentação
HTML fará referência à folha de estilo para postgresql.org.
-Dpgport=NÚMERO #
Define NÚMERO como o número da porta
para o servidor e para os clientes.
O padrão é 5432.
O número da porta pode sempre ser alterada posteriormente,
mas se for especificado nesta opção, tanto o servidor quanto
os clientes terão o mesmo número compilado, o que pode ser
muito conveniente.
Normalmente, o único bom motivo para escolher um valor diferente
do padrão é quando se pretende executar vários servidores
PostgreSQL na mesma máquina.
-Dkrb_srvnam=NOME #
O nome padrão do serviço principal do Kerberos
usado pela GSSAPI.
O padrão é postgres.
Normalmente, não há motivo para mudar este nome, a menos que
se esteja compilando para um ambiente
Windows; neste caso,
deve ser definido como POSTGRES em maiúsculo.
-Dsegsize=TAMANHO_DO_SEGMENTO #Define o tamanho do segmento, em gigabytes. As tabelas grandes são divididas entre vários arquivos do sistema operacional, cada um com tamanho igual ao tamanho do segmento, evitando problemas com limites de tamanho de arquivo que existem em muitas plataformas. O tamanho de segmento padrão, 1 gigabyte, é seguro em todas as plataformas onde há suporte. Se o sistema operacional tem suporte para “largefile” (o que a maioria tem, hoje em dia), pode ser usado um tamanho de segmento maior. Esta opção pode ser útil para reduzir o número de descritores de arquivo consumidos ao trabalhar com tabelas muito grandes. Mas deve-se tomar cuidado para não selecionar um valor maior do que o com suporte pela plataforma e pelos sistemas de arquivos que se pretende usar. Outras ferramentas que se pode querer usar, como o tar, também podem definir limites no tamanho do arquivo utilizável. Recomenda-se, embora não seja absolutamente obrigatório, que este valor seja uma potência de 2.
-Dblocksize=TAMANHO_DO_BLOCO #Define o tamanho do bloco, em kilobytes. Esta é a unidade de armazenamento e E/S dentro das tabelas. O padrão, 8 kilobytes, é adequado para a maioria das situações; mas outros valores podem ser úteis em casos especiais. O valor deve ser uma potência de 2, entre 1 e 32 (kilobytes).
-Dwal_blocksize=TAMANHO_DO_BLOCO #Define o tamanho do bloco do WAL, em kilobytes. Esta é a unidade de armazenamento e E/S no registro do WAL. O padrão, 8 kilobytes, é adequado para a maioria das situações; mas outros valores podem ser úteis em casos especiais. O valor deve ser uma potência de 2, entre 1 e 64 (kilobytes).
A maioria das opções presentes nesta seção são de interesse apenas
para desenvolver ou depurar o PostgreSQL.
Estas opções não são recomendados para compilações de produção,
exceto para --debug, podendo ser útil para
ativar relatórios detalhados de bugs no caso de azar de se
encontrar um bug.
Nas plataformas que oferecem suporte a
DTrace,
também pode ser razoável usar -Dtrace
em produção.
Ao construir uma instalação que será usada para desenvolver código
interno do servidor, recomenda-se usar pelo menos as opções
--buildtype=debug e -Dcassert.
--buildtype=TIPO_DE_CONSTRUÇÃO #
Esta opção pode ser usada para especificar o tipo de construção
a ser usada; o padrão é debugoptimized.
Caso se deseje um controle mais preciso sobre os símbolos de
depuração e os níveis de otimização do que o oferecido por esta
opção, pode-se usar os sinalizadores --debug e
--optimization.
Geralmente são usados os seguintes tipos de construção:
plain, debug,
debugoptimized e release.
Podem ser obtidas mais informações na Documentação do Meson.
--debug #Constrói todos os programas e bibliotecas com símbolos de depuração, significando ser possível executar os programas em um depurador para analisar problemas. Esta opção aumenta consideravelmente o tamanho dos executáveis instalados e, em compiladores não GCC, geralmente também desativa a otimização do compilador, causando lentidão. Entretanto, ter os símbolos disponíveis é extremamente útil para lidar com quaisquer problemas que possam surgir. No momento, esta opção é recomendada para instalações de produção somente se for usado o GCC. Mas esta opção deve ser usada sempre que se fizer um trabalho de desenvolvimento, ou se estiver sendo executada uma versão beta.
--optimization=NÍVEL #
Especifica o nível de otimização.
O NÍVEL pode ser definido para para um entre
{0,g,1,2,3,s}.
--werror #Ao definir esta opção, o compilador é instruído a tratar avisos como erros. Pode ser útil para o desenvolvimento de código.
-Dcassert={ true | false } #Ativa verificações de asserção (assertion) no servidor, que testam muitas condições que “não podem ocorrer”. Isto é inestimável para fins de desenvolvimento de código, mas os testes podem diminuir muito a velocidade do servidor. Além disso, ter os testes ativados não melhora necessariamente a estabilidade do servidor! As verificações de asserção não são categorizadas por gravidade, portanto, o que pode ser um bug relativamente inofensivo ainda leva a reinicialização do servidor se acionar uma falha de asserção. Esta opção não é recomendada para uso em produção, mas deve ser ativada para trabalho de desenvolvimento, ou ao executar uma versão beta.
-Dtap_tests={ auto | enabled | disabled } #
Ativa testes usando as ferramentas
Perl TAP.
O padrão é auto e esta opção requer uma
instalação do Perl e do módulo
Perl
IPC::Run.
Veja Seção 31.4 para obter mais informações.
-DPG_TEST_EXTRA=CONJUNTOS_DE_TESTES #
Ativa conjuntos de testes adicionais, que não são executados por
padrão porque não são seguros para serem executados em um sistema
multiusuário, exigem software especial para serem executados,
ou consomem muitos recursos.
O argumento é uma lista de testes a serem ativados,
separados por espaços em branco.
Veja Seção 31.1.3 para obter mais
informações.
Se a variável de ambiente PG_TEST_EXTRA estiver
definida quando os testes forem executados, ela irá substituir
esta opção de configuração.
-Db_coverage={ true | false } #Ao usar o GCC, todos os programas e bibliotecas são compilados com instrumentos de teste de cobertura de código. Ao serem executados, eles geram arquivos no diretório de construção com métricas de cobertura de código. Veja Seção 31.5 para obter mais informações. Esta opção destina-se apenas ao uso com o GCC e durante trabalhos de desenvolvimento.
-Ddtrace={ auto | enabled | disabled } #Ativar esta opção compila o PostgreSQL com suporte para a ferramenta de rastreamento dinâmico DTrace. Veja Rastreamento dinâmico para obter mais informações.
Para apontar para o programa dtrace,
poderá ser necessário definir a opção DTRACE.
Isto geralmente acontece, porque o dtrace
normalmente é instalado sob o diretório /usr/sbin,
que pode não estar no PATH.
-Dinjection_points={ true | false } #Constrói o PostgreSQL com suporte para pontos de injeção no servidor. Os pontos de injeção permitem executar código definido pelo usuário a partir do servidor em caminhos de código predefinidos. Isto ajuda nos testes e na investigação de cenários de concorrência de forma controlada. Esta opção está desativada por padrão. Veja Pontos de injeção para obter mais informações. Esta opção destina-se a ser utilizada apenas por desenvolvedores para fins de teste.
-Dsegsize_blocks=SEGSIZE_BLOCKS #
Especifica o tamanho do segmento da relação em blocos.
Se a opção -Dsegsize e esta opção forem
especificadas, esta opção irá prevalecer.
Esta opção destina-se apenas a desenvolvedores, para testar
código relacionado ao segmento.
É possível definir metas de construção individuais usando
ninja meta.
Quando não é especificada nenhum meta, tudo é gerado menos a
documentação.
Os produtos de construções individuais podem ser criados usando o
caminho/nome do arquivo como meta.
html #Constrói a documentação no formato HTML com várias páginas
man #
Constrói documentação no formato de página de manual
(man page).
docs #
Constrói a documentação no formato HTML de várias páginas e no
formato de página de manual (man page).
doc/src/sgml/postgres-A4.pdf #Constrói a documentação no formato PDF, com páginas A4.
doc/src/sgml/postgres-US.pdf #
Constrói a documentação no formato PDF, com páginas
US letter.
doc/src/sgml/postgres.html #Constrói a documentação no formato HTML de página única.
alldocs #Constrói a documentação em todos os formatos com suporte.
install #
Instala o postgres, menos a documentação.
install-docs #
Instala a documentação nos formatos HTML de várias páginas e de
página de manual (man page).
install-html #Instala a documentação no formato HTML com várias páginas.
install-man #
Instala a documentação no formato de página de manual
(man page).
install-quiet #Semelhante a “install”, mas os arquivos instalados não são mostrados.
install-world #
Instale o postgres, incluindo HTML de várias
páginas e a documentação em página de manual
(man page).
uninstall #Remove os arquivos instalados.