Esta seção documenta questões adicionais específicas da plataforma, relacionadas à instalação e configuração do PostgreSQL. Certifique-se também de ler as instruções de instalação e, em particular, Requisitos. Além disso, deve-se consultar o Capítulo 31 quanto a interpretação dos resultados do teste de regressão.
As plataformas não abordadas aqui, não têm problemas de instalação conhecidos específicos da plataforma.
O PostgreSQL pode ser construído usando o Cygwin, um ambiente semelhante ao Linux para Windows, mas este método é inferior à construção nativa do Windows e executar um servidor no Cygwin não é mais recomendado.
Ao construir a partir do código-fonte, deve-se proceder conforme o
procedimento de instalação no estilo
Unix
(ou seja, ./configure; make; etc.),
observando as seguintes diferenças específicas do
Cygwin:
Deve-se definir o caminho de modo a encontrar o diretório
bin do
Cygwin antes do diretório
dos utilitários do Windows.
Isto ajuda a evitar problemas com a compilação.
O comando adduser não tem suporte;
deve-se usar a aplicação de gerenciamento de usuários apropriada
no Windows.
Caso contrário, deve-se ignorar esta etapa.
O comando su não tem suporte;
deve-se usar o ssh para simular o
su no
Windows.
Caso contrário, deve-se ignorar esta etapa.
OpenSSL não tem suporte.
Deve-se iniciar o cygserver para suporte à
memória compartilhada. Para fazer isto, deve ser executado o
comando /usr/sbin/cygserver &.
Este programa precisa estar ativo sempre que se inicia o
servidor PostgreSQL, ou se inicializa
um agrupamento de bancos de dados (initdb).
A configuração padrão do cygserver pode
precisar ser alterada (por exemplo, aumentando SEMMNS)
para evitar que o PostgreSQL falhe
devido à falta de recursos do sistema.
A construção pode falhar em alguns sistemas onde está em uso
uma localidade diferente de C.
Para corrigir este problema, deve-se definir a localidade como
C executando export LANG=C.utf8 antes de
construir e, em seguida, definir de volta para a configuração
anterior após instalar o PostgreSQL.
Os testes de regressão em paralelo (make check)
podem gerar falhas de teste de regressão espúrias, devido ao
estouro da fila de backlog do listen(),
causando erros de conexão recusada ou travamentos.
Pode ser limitado o número de conexões usando a variável do
make MAX_CONNECTIONS
dessa forma:
make MAX_CONNECTIONS=5 check
(Em alguns sistemas pode haver até cerca de 10 conexões simultâneas.)
É possível instalar o cygserver e o servidor
PostgreSQL como serviços do
Windows NT.
Para obter informações sobre como fazer isto, consulte o documento
README incluído no pacote binário do
PostgreSQL no
Cygwin.
Ele está instalado no diretório
/usr/share/doc/Cygwin.
Para construir o PostgreSQL a partir do código-fonte no macOS, é necessário instalar as ferramentas de desenvolvedor de linha de comando da Apple™, o que pode ser feito executando
xcode-select --install
(deve-se observar que este comando faz aparecer uma janela de diálogo para confirmação). Pode-se ou não querer instalar também o Xcode.
Nas versões recentes do macOS,
é necessário adicionar o caminho para sysroot
nas opções de inclusão usadas para encontrar alguns arquivos de
cabeçalho do sistema.
Resulta nas saídas do script configure
variando dependendo de qual versão do SDK foi
usada durante o config.
Isto não deve representar nenhum problema em cenários simples, mas
caso se esteja tentando fazer algo como criar uma extensão em uma
máquina diferente de onde o código do servidor foi construído,
talvez seja necessário forçar o uso de um caminho para
sysroot diferente.
Para fazer isto defina PG_SYSROOT, por exemplo
make PG_SYSROOT=/caminho/desejado all
Para descobrir o caminho apropriado para a máquina, deve-se executar
xcrun --show-sdk-path
Note que construir uma extensão usando uma versão de
sysroot diferente daquela usada para construir
o servidor núcleo não é realmente recomendado; na pior das hipóteses,
pode resultar em inconsistências de ABI difíceis de depurar.
Pode ser selecionado um caminho para sysroot
não-padrão ao configurar, especificando PG_SYSROOT
no configure:
./configure ... PG_SYSROOT=/caminho/desejado
Isto seria útil principalmente para compilação cruzada para alguma outra versão do macOS. Não há garantia de que os executáveis resultantes vão rodar no hospedeiro corrente.
Para suprimir completamente as opções -isysroot,
deve-se usar
./configure ... PG_SYSROOT=none
(qualquer nome de caminho inexistente funciona). Isto pode ser útil se for desejado compilar com um compilador que não seja da Apple™, mas lembre-se de que este caso não é testado ou tem suporte pelos desenvolvedores do PostgreSQL.
A funcionalidade do macOS
“System Integrity Protection” (SIP)
quebra o make check, porque impede passar a
configuração necessária de DYLD_LIBRARY_PATH
para os executáveis que estão sendo testados.
Isto pode ser contornado executando make install
antes de make check.
A maioria dos desenvolvedores do PostgreSQL
simplesmente desativa o SIP.
O PostgreSQL para Windows pode ser construído usando o MinGW, um ambiente de construção semelhante ao Unix para Windows. Recomenda-se usar o ambiente MSYS2 para isto e também instalar quaisquer pacotes pré-requisitos.
Se o PostgreSQL no
Windows travar, ele
consegue gerar minidumps que podem
ser usados para rastrear a causa do travamento, semelhante às
descargas principais no Unix.
Estas descargas (dumps) podem ser
lidas usando o Windows Debugger Tools,
ou usando o Visual Studio.
Para ativar a geração de descargas no
Windows, deve ser criado
um subdiretório chamado crashdumps dentro do
diretório de dados da instância de bancos de dados
(cluster).
As descargas serão escritas neste diretório com um nome único,
baseado no identificador do processo de travamento, e na hora
em que ocorreu o travamento.
O PostgreSQL tem um bom suporte no Solaris. Quanto mais atualizado estiver o sistema operacional, menos problemas existirão.
Pode-se construir usando o GCC, ou o conjunto
de compiladores da Sun.
Para melhor otimização do código, o compilador da Sun é fortemente
recomendado na arquitetura SPARC.
Se estiver usando o compilador da Sun, tome cuidado para não
selecionar /usr/ucb/cc;
use /opt/SUNWspro/bin/cc.
Pode ser baixado o Sun Studio em Download Options for Oracle Developer Studio. Muitas ferramentas GNU estão integradas ao Solaris 10, ou estão presentes no CD complementar do Solaris. Se precisar de pacotes para versões mais antigas do Solaris, estas ferramentas podem ser encontradas em Sunfreeware. Se preferir os arquivos-fonte, procure no GNU.
Se o script configure reclamar sobre falha em um
programa de teste, este é provavelmente um caso onde o vinculador
de tempo de execução não conseguiu encontrar alguma biblioteca,
provavelmente libz, libreadline,
ou alguma outra biblioteca não-padrão, como libssl.
Para apontar para o local correto, deve ser definida a variável de
ambiente LDFLAGS na linha de comando do
configure, por exemplo,
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
Veja a página do manual de ld para obter mais informações.
Na arquitetura SPARC, o
Sun Studio é fortemente recomendado
para a compilação.
Deve-se tentar usar o sinalizador de otimização -xO5,
para gerar binários muito mais rápidos.
Não se deve usar nenhum sinalizador que modifique o comportamento
de operações de ponto flutuante e processamento de
errno (por exemplo, -fast).
Não havendo motivos para usar binários de 64 bits no SPARC, então deve-se preferir a versão de 32 bits. As operações de 64 bits são mais lentas, e os binários de 64 bits são mais lentos, do que as variantes de 32 bits. Por outro lado, o código de 32 bits na família de processadores AMD64 não é nativo, portanto o código de 32 bits é muito mais lento nesta família de processadores.
Sim, é possível usar o DTrace. Veja Rastreamento dinâmico para obter mais informações.
Se estiver observando a vinculação do executável
postgres falhar com uma mensagem de erro como:
Undefined first referenced symbol in file AbortTransaction utils/probes.o CommitTransaction utils/probes.o ld: fatal: Symbol referencing errors. No output written to postgres collect2: ld returned 1 exit status make: *** [postgres] Error 1
então a instalação do DTrace é muito antiga para lidar com testes em funções estáticas. É necessário o Solaris 10u4, ou mais recente, para usar o DTrace.
Recomenda-se que a maioria dos usuários baixe a distribuição binária para o Windows, disponível como um pacote de instalação gráfica no site do PostgreSQL na página PostgreSQL Downloads. A construção a partir do código-fonte destina-se apenas a pessoas que desenvolvem o PostgreSQL ou extensões.
O PostgreSQL para Windows com Visual Studio pode ser construído usando o Meson, conforme descrito em Construção e Instalação com Meson. A versão nativa para o Windows requer uma versão de 32 ou 64 bits do Windows 10, ou posterior.
As construções nativas do psql não oferecem suporte a edição de linha de comando. A construção do Cygwin oferece suporte a edição de linha de comando, portanto, deve ser usada quando o psql for necessário para uso interativo no Windows.
O PostgreSQL pode ser compilado usando o pacote de compiladores Visual C++ da Microsoft™. Estes compiladores podem ser qualquer um que vem com o Visual Studio, Visual Studio Express, ou de alguma versão do Microsoft Windows SDK. Se ainda não houver um ambiente do Visual Studio configurado, as maneiras mais fáceis são usar os compiladores do Visual Studio 2022 ou aqueles presentes no Windows SDK 10, que podem ser baixados gratuitamente da Microsoft™.
É possível construir tanto em 32 bits quanto em 64 bits com o pacote de compiladores da Microsoft™. É possível criar versões de 32 bits do PostgreSQL usando desde o Visual Studio 2015 até o Visual Studio 2022, assim como usando versões autônomas do Microsoft Windows SDK versão 10 e superiores. As construções de 64 bits do PostgreSQL têm suporte com o Microsoft Windows SDK versão 10 ou superior, ou com o Visual Studio 2015 e versões superiores.
Se o ambiente de construção não incluir uma versão compatível do Microsoft Windows SDK, recomenda-se que seja atualizado para a versão mais recente (no momento a versão 10), disponível para baixar em Centro de Download.
Deve-se sempre incluir o Windows Headers and Libraries, que é parte do SDK. Se for instalado o Windows SDK incluindo o Visual C++ Compilers, não há necessidade do Visual Studio para construir. Note que, a partir da versão 8.0a, o Microsoft Windows SDK não é mais fornecido com um ambiente de construção completo baseado em linha de comando.
São necessários os seguintes produtos adicionais para construir o PostgreSQL no Windows.
É requerido o Strawberry Perl para
executar os scripts de geração da construção.
Nem o MinGW nem o
Cygwin Perl irão funcionar.
Também deve estar presente no PATH.
Os arquivos binários podem ser baixados de
Perl for MS Windows.
Os arquivos binários para Bison e Flex podem ser baixados de winflexbison.
Os seguintes produtos adicionais não são necessários para começar, mas são indispensáveis para construir o pacote completo.
Requerido para construir o PL/Tcl. Os arquivos binários podem ser baixados de Magicsplat Tcl/Tk for Windows.
O Diff é requerido para executar os testes de regressão, e pode ser baixado de GnuWin.
O Gettext é requerido para construir com suporte a NLS, e pode ser baixado de GnuWin. Note que os arquivos binários, as dependências e os arquivos de desenvolvedor são todos necessários.
Requerido para suporte à autenticação pela GSSAPI. MIT Kerberos pode ser baixado da MIT Kerberos Distribution Page.
Requerido para suporte a XML. Os arquivos binários podem ser baixados de libxml, ou o código-fonte de Libxml2. Note que a libxml2 requer o iconv, que está disponível no mesmo local para baixar.
Requerido para suporte a compressão LZ4. Os arquivos binários e o código-fonte podem ser baixados de LZ4.
Requerido para suporte a compressão Zstandard. Os arquivos binários e o código-fonte podem ser baixados de Zstandard.
Requerido para suporte a SSL. Os arquivos binários podem ser baixados de Win32/Win64 OpenSSL Installation Project ou o código-fonte de OpenSSL Library.
Requerido para suporte a UUID-OSSP
(contrib apenas).
O código-fonte pode ser baixado de
Universally Unique Identifier (UUID).
Requerido para construir o PL/Python. Os arquivos binários podem ser baixados de Python.
Requerido para suporte a compressão no pg_dump e no pg_restore. Os arquivos binários podem ser baixados de zlib.
O PostgreSQL só será construído para a arquitetura x64 em sistemas Windows de 64 bits.
A mistura de versões de 32 e 64 bits na mesma árvore de construção não tem suporte. O sistema de construção irá detectar automaticamente se está sendo executado em um ambiente de 32 ou 64 bits e irá construir o PostgreSQL de acordo. Por este motivo, é importante iniciar o aviso de comando (prompt) correto antes de construir.
Para usar uma biblioteca de terceiros do lado servidor, como Python ou OpenSSL, esta biblioteca deverá também ser de 64 bits. Não há suporte para carregar uma biblioteca de 32 bits em um servidor de 64 bits. Várias bibliotecas de terceiros que o PostgreSQL oferece suporte podem estar disponíveis apenas em versões de 32 bits, caso em que não podem ser usadas com o PostgreSQL de 64 bits.
Se o PostgreSQL no
Windows travar, ele
consegue gerar minidumps que podem
ser usados para rastrear a causa do travamento, semelhante às
descargas principais no Unix.
Estas descargas (dumps) podem ser
lidas usando o Windows Debugger Tools,
ou usando o Visual Studio.
Para ativar a geração de descargas no
Windows, deve ser criado
um subdiretório chamado crashdumps dentro do
diretório de dados da instância de bancos de dados
(cluster).
As descargas serão escritas neste diretório com um nome único,
baseado no identificador do processo de travamento, e na hora
em que ocorreu o travamento.