Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVxJk-00CV09-Fv for pgsql-general@arkaria.postgresql.org; Mon, 22 Jul 2024 17:59:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sVxJi-005HxB-KU for pgsql-general@arkaria.postgresql.org; Mon, 22 Jul 2024 17:59:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVxJi-005HwZ-8R for pgsql-general@lists.postgresql.org; Mon, 22 Jul 2024 17:59:22 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVxJg-000vLL-2Z for pgsql-general@lists.postgresql.org; Mon, 22 Jul 2024 17:59:21 +0000 Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5a309d1a788so3815314a12.3 for ; Mon, 22 Jul 2024 10:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721671159; x=1722275959; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UqnCyECyZL6iN1+RxtTV8yXwveB7WDZ67IRANtm5GgI=; b=AIT1GrV++QvF3MDAdbjKIqWaOe+jp4VvONw3JPkFlDnir+wBA9bgX2BZwrDdkn/5nP XOQw+MH5vp+Jx4vUevun0WbKIWSt7dHej2BoMEM6cY7AhgP8esoUcIlNbJrBzLAIcQzt Ij3EcGkf9lOpCEhZmFY3o/Ki16ntTkrAXViYHNiWy4USt4iFyl7nhBnWWSYEUbgOih0M umbsDJfACxgBxZqOsMKluWGH25SMvVlt+S54C1F2calckbxm+FaLGqwA/QO+dfYX6HO1 Kqo+Ku9CxvTdrmSonfYxawqiUfMY6MPMDeKv7rNFriSqfhdXz1Bx9S94bOscnPdHTATV //RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721671159; x=1722275959; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UqnCyECyZL6iN1+RxtTV8yXwveB7WDZ67IRANtm5GgI=; b=d0uRaULWNO/ngIbBZy722KkJwrcnNUEQgizVabjPVh/xHd8SaeXtyLIhrNeEfO4ODw NKBqiatcOnZFjdhGhvPC+82X5aVWgsJLXOtHG/8+ekLkw2iV1qatIcYpA4Nkb5PPNi3r 4FIzQuKfyD9UYuEEWEuFdvgqAswuwiwP5MZetHay4YEzLYeCrBWmB0cn4qVPVbDMBnRo UnEoOsbhdZUWsVoBGyhnJDFQmfYT0VQhH0CJLVR0CQemAqqY1Dh5gLoK5ufDA6UQ/h5d uo2o7NaYVbqwqbLa4TsIdGJfWOcz0RzPCsFZnG2rbE143yRVMbEhIKd1ABdwdpr24DsN VAQg== X-Forwarded-Encrypted: i=1; AJvYcCVPP2MGiNRvtwK5PsJm2Lywoy34PTDCT0nZrO4yXEOqP4Yubg187T2ZvDgC+Bfb+Hq9hjrCbUGYQIdteyEtYNh2YsuDMCRiupcW9WuhSev9iD25 X-Gm-Message-State: AOJu0YwTUrWUh2h49t+Bd70P7QBdQSZJ+Cz1UQ/CZJdqMgYNcBU4oRZD SrPP2Rv5mMUHfeDN8fCrm64ApC8hvcyBiW+HcYMCN61h3ru12rQuSAMm5Ud7kONkgpBUZyLBGsZ 0F5Yf0Gl2SUtycjFOCQcDru5gZQU= X-Google-Smtp-Source: AGHT+IFOIBk9uuy85qgUpHzFUwe8QBx3ZCvHFdvrOlVZ6hRBQIXRhka4wV9HdhPflVcubjCb/R/rgBt/Wc6xsQ1YX9I= X-Received: by 2002:a50:8749:0:b0:5a1:c40a:3a81 with SMTP id 4fb4d7f45d1cf-5a4f0c7724bmr3744851a12.35.1721671158595; Mon, 22 Jul 2024 10:59:18 -0700 (PDT) MIME-Version: 1.0 References: <80c9b0ea-c874-40ad-a006-fb1eb37464c2@aklaver.com> <44b44ece-dce6-4b4f-b751-8787a5a071e0@aklaver.com> <011a5254-4abb-460b-bd02-92e8dfc0e5ea@aklaver.com> <9cc12221-ba75-4ba0-803f-51be5c8f1525@aklaver.com> <4c21a115-ec58-4e79-86b8-8626bd307e02@aklaver.com> In-Reply-To: From: AC Gomez Date: Mon, 22 Jul 2024 13:59:07 -0400 Message-ID: Subject: Re: Windows installation problem at post-install step To: =?UTF-8?B?RXJ0YW4gS8O8w6fDvGtvZ2x1?= Cc: Adrian Klaver , pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000d407bc061dd9cd12" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d407bc061dd9cd12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We On Mon, Jul 22, 2024, 1:51=E2=80=AFPM Ertan K=C3=BC=C3=A7=C3=BCkoglu wrote: > Adrian Klaver , 22 Tem 2024 Pzt, 20:37 > tarihinde =C5=9Funu yazd=C4=B1: > >> What is the command you use to restore the pg_dumpall file? >> > > within psql I run \i > > template1 should not be dropped in the pg_dumpall file. >> >> Is there output that shows that happening? >> > > -- > -- Databases > -- > > -- > -- Database "template1" dump > -- > > -- > -- PostgreSQL database dump > -- > > -- Dumped from database version 16.3 > -- Dumped by pg_dump version 16.3 > > SET statement_timeout =3D 0; > SET lock_timeout =3D 0; > SET idle_in_transaction_session_timeout =3D 0; > SET client_encoding =3D 'UTF8'; > SET standard_conforming_strings =3D on; > SELECT pg_catalog.set_config('search_path', '', false); > SET check_function_bodies =3D false; > SET xmloption =3D content; > SET client_min_messages =3D warning; > SET row_security =3D off; > > UPDATE pg_catalog.pg_database SET datistemplate =3D false WHERE datname = =3D > 'template1'; > DROP DATABASE template1; > -- > -- Name: template1; Type: DATABASE; Schema: -; Owner: postgres > -- > > CREATE DATABASE template1 WITH TEMPLATE =3D template0 ENCODING =3D 'UTF8' > LOCALE_PROVIDER =3D libc LOCALE =3D 'Turkish_Turkey.1254'; > > Above lines are taken from the dump file itself and it does indeed drop > the template1. I think this is because this is a cluster dump. > Later it tries to create a new template1 and that command causes an error > because of Windows locale name. > > >> Was template1 dropped in the Windows Postgres instance? >> > > No. It still is there. > > BTW dump is taken using the below command line on Windows system. > "C:\Program Files\PostgreSQL\16\bin\pg_dumpall.exe" -U postgres -h > 127.0.0.1 -p 5432 -c -f "c:\yedek\cluster.dump.sql" > > Thanks & Regards, > Ertan > --000000000000d407bc061dd9cd12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

We


On Mon= , Jul 22, 2024, 1:51=E2=80=AFPM Ertan K=C3=BC=C3=A7=C3=BCkoglu <ertan.kucukoglu@gmail.com> wro= te:
Adrian Klaver <adrian.klaver@aklaver.com>, 22 Tem 2024 = Pzt, 20:37 tarihinde =C5=9Funu yazd=C4=B1:
What is the command y= ou use to restore the pg_dumpall file?

= within psql I run \i <dump_file_name>=C2=A0

template1 should not be dropped in the pg_dumpall file.

Is there output that shows that happening?

-= -
-- Databases
--

--
-- Database "template1" dump=
--

--
-- PostgreSQL database dump
--

-- Dumped from= database version 16.3
-- Dumped by pg_dump version 16.3

SET stat= ement_timeout =3D 0;
SET lock_timeout =3D 0;
SET idle_in_transaction_= session_timeout =3D 0;
SET client_encoding =3D 'UTF8';
SET st= andard_conforming_strings =3D on;
SELECT pg_catalog.set_config('sear= ch_path', '', false);
SET check_function_bodies =3D false;SET xmloption =3D content;
SET client_min_messages =3D warning;
SET= row_security =3D off;

UPDATE pg_catalog.pg_database SET datistempla= te =3D false WHERE datname =3D 'template1';
DROP DATABASE templa= te1;
--
-- Name: template1; Type: DATABASE; Schema: -; Owner: postgre= s
--

CREATE DATABASE template1 WITH TEMPLATE =3D template0 ENCODI= NG =3D 'UTF8' LOCALE_PROVIDER =3D libc LOCALE =3D 'Turkish_Turk= ey.1254';

Above lines are taken from the dump fi= le itself and it does indeed drop the template1. I think this is because th= is is a cluster dump.
Later it tries to create a new template1 an= d that command causes an error because of Windows locale name.

Was template1 dropped in the Windows Postgres instance?

No. It still is there.

BTW dump i= s taken using the below command line on Windows system.
"C:\= Program Files\PostgreSQL\16\bin\pg_dumpall.exe" -U postgres -h 127.0.0= .1 -p 5432 -c -f "c:\yedek\cluster.dump.sql"

Thanks & Regards,
Ertan
--000000000000d407bc061dd9cd12--