Thread: Re: postgresql-17.0-1 Application - silent installation Issue

Re: postgresql-17.0-1 Application - silent installation Issue

From
Adrian Klaver
Date:
On 11/10/24 07:11, JOLAPARA Urvi (SAFRAN) wrote:
> C2 - Confidential
> 
> 
> Hello Team,
> 
> I am from Application Packaging team. we have created the package of 
> PostgreSQL 17.0-1 Application.

You are going to need to provide more detail on the package creation 
process.

> 
> We have used the command line parameter for installation is this : 
> *“postgresql-17.0-1-windows-x64.exe--mode unattended --unattendedmodeui 
> none --optionfile C:\Temp\Install”*
> 
> This is working in English language machine but it is failing in French 
> language machine and throwing below error:

You should provide error messages as text not as image, so folks can run 
them through a translator if need be.

erreur d'ecriture du fichier -> file write error

according to Google.

> 
> 
> we tried giving permission to this folder, then we have used 

Which directory(folder) would that be?

> *“--installer-launage fr”* parameter *“--locale fr”* parameters but 

Should that not be --installer-language?

Also shouldn't this:

--locale fr

be?:

--locale fr-FR

> still not working.
> 
> Please assist to resolve the issue asap.
> 
> Thanks & Regards,
> 
> Urvi Jolapara
> 
> urvi.jolapara@safrangroup.com <mailto:urvi.jolapara@safrangroup.com>
> 
> Image
> 
> *www.safran-group.com* <http://www.safran-group.com/fr/>
> 
> #
> " Ce courriel et les documents qui lui sont joints peuvent contenir des 
> informations confidentielles, être soumis aux règlementations relatives 
> au contrôle des exportations ou ayant un caractère privé. S'ils ne vous 
> sont pas destinés, nous vous signalons qu'il est strictement interdit de 
> les divulguer, de les reproduire ou d'en utiliser de quelque manière que 
> ce soit le contenu. Toute exportation ou réexportation non autorisée est 
> interdite Si ce message vous a été transmis par erreur, merci d'en 
> informer l'expéditeur et de supprimer immédiatement de votre système 
> informatique ce courriel ainsi que tous les documents qui y sont attachés."
> ******
> " This e-mail and any attached documents may contain confidential or 
> proprietary information and may be subject to export control laws and 
> regulations. If you are not the intended recipient, you are notified 
> that any dissemination, copying of this e-mail and any attachments 
> thereto or use of their contents by any means whatsoever is strictly 
> prohibited. Unauthorized export or re-export is prohibited. If you have 
> received this e-mail in error, please advise the sender immediately and 
> delete this e-mail and all attached documents from your computer system."
> #

-- 
Adrian Klaver
adrian.klaver@aklaver.com




RE: postgresql-17.0-1 Application - silent installation Issue

From
"JOLAPARA Urvi (SAFRAN)"
Date:
C2 - Confidential

Hello Klaver,

We are using PSADT for creating a script and installing through SCCM.
And when we are installing Through Software center it is throwing error as below:

"There has been an error
error while writing file C:\windows\Temp\postgresql_installer_8b85d458af\temp_check_comspec.bat"

Thanks & Regards,
Urvi Jolapara
urvi.jolapara@safrangroup.com

www.safran-group.com

-----Original Message-----
From: Adrian Klaver <adrian.klaver@aklaver.com> 
Sent: Monday, November 11, 2024 9:49 PM
To: JOLAPARA Urvi (SAFRAN) <urvi.jolapara@safrangroup.com>; pgsql-general@postgresql.org
Cc: KRISHNAN LINGATHAR Karupaswamy (SAFRAN) <karupaswamy.krishnan-lingathar@safrangroup.com>
Subject: Re: postgresql-17.0-1 Application - silent installation Issue

CAUTION:  This message originated from an outside organization. In case of suspicion, click on "Report to SAFRAN
Security"from the Outlook ribbon. 
 

On 11/10/24 07:11, JOLAPARA Urvi (SAFRAN) wrote:
> C2 - Confidential
> 
> 
> Hello Team,
> 
> I am from Application Packaging team. we have created the package of 
> PostgreSQL 17.0-1 Application.

You are going to need to provide more detail on the package creation process.

> 
> We have used the command line parameter for installation is this : 
> *“postgresql-17.0-1-windows-x64.exe--mode unattended 
> --unattendedmodeui none --optionfile C:\Temp\Install”*
> 
> This is working in English language machine but it is failing in 
> French language machine and throwing below error:

You should provide error messages as text not as image, so folks can run them through a translator if need be.

erreur d'ecriture du fichier -> file write error

according to Google.

> 
> 
> we tried giving permission to this folder, then we have used

Which directory(folder) would that be?

> *“--installer-launage fr”* parameter *“--locale fr”* parameters but

Should that not be --installer-language?

Also shouldn't this:

--locale fr

be?:

--locale fr-FR

> still not working.
> 
> Please assist to resolve the issue asap.
> 
> Thanks & Regards,
> 
> Urvi Jolapara
> 
> urvi.jolapara@safrangroup.com <mailto:urvi.jolapara@safrangroup.com>
> 
> Image
> 
> *www.safran-group.com* 
> <https://urldefense.com/v3/__http://www.safran-group.com/fr/__;!!P3ITo
> RM6tg!lcu8B2WYC3q9sLuzLhCkS5OgLIQrDrJR_oXes8Pd-fyTKP6hFQEEp-cnYrUJTMFp
> brUMR5UjNRKPgmKfoJ8RWMAgLSunLtYk$ >
> 
> #
> " Ce courriel et les documents qui lui sont joints peuvent contenir 
> des informations confidentielles, être soumis aux règlementations 
> relatives au contrôle des exportations ou ayant un caractère privé. 
> S'ils ne vous sont pas destinés, nous vous signalons qu'il est 
> strictement interdit de les divulguer, de les reproduire ou d'en 
> utiliser de quelque manière que ce soit le contenu. Toute exportation 
> ou réexportation non autorisée est interdite Si ce message vous a été 
> transmis par erreur, merci d'en informer l'expéditeur et de supprimer 
> immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."
> ******
> " This e-mail and any attached documents may contain confidential or 
> proprietary information and may be subject to export control laws and 
> regulations. If you are not the intended recipient, you are notified 
> that any dissemination, copying of this e-mail and any attachments 
> thereto or use of their contents by any means whatsoever is strictly 
> prohibited. Unauthorized export or re-export is prohibited. If you 
> have received this e-mail in error, please advise the sender 
> immediately and delete this e-mail and all attached documents from your computer system."
> #

--
Adrian Klaver
adrian.klaver@aklaver.com

#
" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux
règlementationsrelatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés,
nousvous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque
manièreque ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été
transmispar erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce
courrielainsi que tous les documents qui y sont attachés." 
******
" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to
exportcontrol laws and regulations. If you are not the intended recipient, you are notified that any dissemination,
copyingof this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly
prohibited.Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the
senderimmediately and delete this e-mail and all attached documents from your computer system." 
#

Re: postgresql-17.0-1 Application - silent installation Issue

From
Adrian Klaver
Date:
On 11/11/24 22:09, JOLAPARA Urvi (SAFRAN) wrote:
> C2 - Confidential

This is a publicly readable list, the above has no meaning in that context.

> 
> Hello Klaver,
> 
> We are using PSADT for creating a script and installing through SCCM.

1) I don't work with Windows so I have no idea what the above
means.

2) You did not answer the rest of the questions I asked in my previous post.

a) "we tried giving permission to this folder, then we have used"

Which directory(folder) would that be?

b) ' *“--installer-launage fr”* parameter *“--locale fr”* parameters but 
...'

Should that not be --installer-language?

Also shouldn't this:

--locale fr

be?:

--locale fr-FR


> And when we are installing Through Software center it is throwing error as below:
> 
> "There has been an error
> error while writing file C:\windows\Temp\postgresql_installer_8b85d458af\temp_check_comspec.bat"


I would suggest looking in the Windows system log to see if it provides 
more information for the above error.

> 
> Thanks & Regards,
> Urvi Jolapara
> urvi.jolapara@safrangroup.com
> 
> www.safran-group.com

-- 
Adrian Klaver
adrian.klaver@aklaver.com




RE: postgresql-17.0-1 Application - silent installation Issue

From
"JOLAPARA Urvi (SAFRAN)"
Date:
C2 - Confidential

Hello Klaver,

I have added below the log where setup is failing on FR language machine.

Log started 11/14/2024 at 09:04:33
Preferred installation mode : unattended
Trying to init installer in mode unattended
Mode unattended successfully initialized
Setting variable whoami from C:\WINDOWS\System32\whoami 
Script exit code: 0

Script output:
 autorite nt\système

Script stderr:
 

Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Base Directory.
Settingvariable iBaseDirectory to empty value
 
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Branding. Setting
variableiBranding to empty value
 
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Version. Setting
variablebrandingVer to empty value
 
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Shortcuts. Setting
variableiShortcut to empty value
 
[09:04:35] Using branding: PostgreSQL 17
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 SB_Version. Setting
variablesb_version to empty value
 
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 pgAdmin_Version.
Settingvariable pgadmin_version to empty value
 
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 CLT_Version. Setting
variableclt_version to empty value
 
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Data Directory.
Settingvariable server_data_dir to empty value
 
Erreur d'écriture du fichier C:/Windows/Temp/postgresql_installer_ee9259ae9d/temp_check_comspec.bat
Exiting with code 1

The Parameters which you suggested in last mail also not working with PostgresSQL exe.

Please transfer the request who works with windows. We need the solution asap.

Thanks & Regards,
Urvi Jolapara
urvi.jolapara@safrangroup.com

www.safran-group.com

-----Original Message-----
From: Adrian Klaver <adrian.klaver@aklaver.com> 
Sent: Tuesday, November 12, 2024 10:06 PM
To: JOLAPARA Urvi (SAFRAN) <urvi.jolapara@safrangroup.com>; pgsql-general@postgresql.org
Cc: KRISHNAN LINGATHAR Karupaswamy (SAFRAN) <karupaswamy.krishnan-lingathar@safrangroup.com>
Subject: Re: postgresql-17.0-1 Application - silent installation Issue

CAUTION:  This message originated from an outside organization. In case of suspicion, click on "Report to SAFRAN
Security"from the Outlook ribbon. 
 

On 11/11/24 22:09, JOLAPARA Urvi (SAFRAN) wrote:
> C2 - Confidential

This is a publicly readable list, the above has no meaning in that context.

> 
> Hello Klaver,
> 
> We are using PSADT for creating a script and installing through SCCM.

1) I don't work with Windows so I have no idea what the above means.

2) You did not answer the rest of the questions I asked in my previous post.

a) "we tried giving permission to this folder, then we have used"

Which directory(folder) would that be?

b) ' *“--installer-launage fr”* parameter *“--locale fr”* parameters but ...'

Should that not be --installer-language?

Also shouldn't this:

--locale fr

be?:

--locale fr-FR


> And when we are installing Through Software center it is throwing error as below:
> 
> "There has been an error
> error while writing file C:\windows\Temp\postgresql_installer_8b85d458af\temp_check_comspec.bat"


I would suggest looking in the Windows system log to see if it provides more information for the above error.

> 
> Thanks & Regards,
> Urvi Jolapara
> urvi.jolapara@safrangroup.com
> 
> https://urldefense.com/v3/__http://www.safran-group.com__;!!P3IToRM6tg
> !i7_r9jHMtJfM4PYV1cyvZR9mQYp6lntjOt9T-GA9pRPIUtgmhYYAOML3XIg9yKfkczYXx
> mYTan6MAGcfZ9TX8oUAU_sEIeqE$

--
Adrian Klaver
adrian.klaver@aklaver.com

#
" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux
règlementationsrelatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés,
nousvous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque
manièreque ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été
transmispar erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce
courrielainsi que tous les documents qui y sont attachés." 
******
" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to
exportcontrol laws and regulations. If you are not the intended recipient, you are notified that any dissemination,
copyingof this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly
prohibited.Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the
senderimmediately and delete this e-mail and all attached documents from your computer system." 
#

Re: postgresql-17.0-1 Application - silent installation Issue

From
Rob Sargent
Date:
>
> Please transfer the request who works with windows. We need the solution asap.
>
> Thanks & Regards,
> Urvi Jolapara
> urvi.jolapara@safrangroup.com
>

If a windows admin/user shows up they may be better able to help.  There is no one to "transfer" to.
The list of missing keys suggests to me that the installation didn't do go well. Whose installer did you use?


> www.safran-group.com
>
> -----Original Message-----
> From: Adrian Klaver <adrian.klaver@aklaver.com>
> Sent: Tuesday, November 12, 2024 10:06 PM
> To: JOLAPARA Urvi (SAFRAN) <urvi.jolapara@safrangroup.com>; pgsql-general@postgresql.org
> Cc: KRISHNAN LINGATHAR Karupaswamy (SAFRAN) <karupaswamy.krishnan-lingathar@safrangroup.com>
> Subject: Re: postgresql-17.0-1 Application - silent installation Issue
>
> CAUTION:  This message originated from an outside organization. In case of suspicion, click on "Report to SAFRAN
Security"from the Outlook ribbon. 
>
>> On 11/11/24 22:09, JOLAPARA Urvi (SAFRAN) wrote:
>> C2 - Confidential
>
> This is a publicly readable list, the above has no meaning in that context.
>
>>
>> Hello Klaver,
>>
>> We are using PSADT for creating a script and installing through SCCM.
>
> 1) I don't work with Windows so I have no idea what the above means.
>
> 2) You did not answer the rest of the questions I asked in my previous post.
>
> a) "we tried giving permission to this folder, then we have used"
>
> Which directory(folder) would that be?
>
> b) ' *“--installer-launage fr”* parameter *“--locale fr”* parameters but ...'
>
> Should that not be --installer-language?
>
> Also shouldn't this:
>
> --locale fr
>
> be?:
>
> --locale fr-FR
>
>
>> And when we are installing Through Software center it is throwing error as below:
>>
>> "There has been an error
>> error while writing file C:\windows\Temp\postgresql_installer_8b85d458af\temp_check_comspec.bat"
>
>
> I would suggest looking in the Windows system log to see if it provides more information for the above error.
>
>>
>> Thanks & Regards,
>> Urvi Jolapara
>> urvi.jolapara@safrangroup.com
>>
>> https://urldefense.com/v3/__http://www.safran-group.com__;!!P3IToRM6tg
>> !i7_r9jHMtJfM4PYV1cyvZR9mQYp6lntjOt9T-GA9pRPIUtgmhYYAOML3XIg9yKfkczYXx
>> mYTan6MAGcfZ9TX8oUAU_sEIeqE$
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com
>
> #
> " Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux
règlementationsrelatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés,
nousvous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque
manièreque ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été
transmispar erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce
courrielainsi que tous les documents qui y sont attachés." 
> ******
> " This e-mail and any attached documents may contain confidential or proprietary information and may be subject to
exportcontrol laws and regulations. If you are not the intended recipient, you are notified that any dissemination,
copyingof this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly
prohibited.Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the
senderimmediately and delete this e-mail and all attached documents from your computer system." 
> #



Re: postgresql-17.0-1 Application - silent installation Issue

From
Adrian Klaver
Date:
On 11/14/24 01:05, JOLAPARA Urvi (SAFRAN) wrote:
> C2 - Confidential
> 
> Hello Klaver,
> 
> I have added below the log where setup is failing on FR language machine.
> 
> Log started 11/14/2024 at 09:04:33
> Preferred installation mode : unattended
> Trying to init installer in mode unattended
> Mode unattended successfully initialized
> Setting variable whoami from C:\WINDOWS\System32\whoami
> Script exit code: 0
> 
> Script output:
>   autorite nt\système
> 
> Script stderr:
>   
> 
> Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Base Directory.
Settingvariable iBaseDirectory to empty value
 
> Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Branding. Setting
variableiBranding to empty value
 
> Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Version. Setting
variablebrandingVer to empty value
 
> Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Shortcuts. Setting
variableiShortcut to empty value
 
> [09:04:35] Using branding: PostgreSQL 17
> Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 SB_Version.
Settingvariable sb_version to empty value
 
> Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 pgAdmin_Version.
Settingvariable pgadmin_version to empty value
 
> Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 CLT_Version.
Settingvariable clt_version to empty value
 
> Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-17 Data Directory.
Settingvariable server_data_dir to empty value
 
> Erreur d'écriture du fichier C:/Windows/Temp/postgresql_installer_ee9259ae9d/temp_check_comspec.bat
> Exiting with code 1
> 
> The Parameters which you suggested in last mail also not working with PostgresSQL exe.
> 
> Please transfer the request who works with windows. We need the solution asap.

Then you probably need to contact a paid tech support company who deals 
with Windows and Postgres. This is the Postgres mailing list and Windows 
support is not really something you will find here.

> 
> Thanks & Regards,
> Urvi Jolapara
> urvi.jolapara@safrangroup.com
> 
> www.safran-group.com
> 
> -----Original Message-----

-- 
Adrian Klaver
adrian.klaver@aklaver.com




 Team

Need exact SQL query to find List of Detach Partitioned Tables (Yet to be Dropped)

The following is the query which i used, i am using and i found an bug which is listing an newly created table (last week)

SELECT relnamespace::regnamespace::text AS schema_name, relname AS table_name
FROM   pg_class c
WHERE  NOT relispartition  -- !
AND    relkind = 'r' and lower(relnamespace::regnamespace::text) not in ('pg_catalog','partman','information_schema')  and
lower(relnamespace::regnamespace::text) in ('XYZ')
order by  relnamespace::regnamespace::text, relname ;
On Fri, Nov 15, 2024 at 12:46 PM Bharani SV-forum <esteembsv-forum@yahoo.com> wrote:
Need exact SQL query to find List of Detach Partitioned Tables (Yet to be Dropped)


The premise that a detached table is distinguishable from any other table that is not a partition is an interesting one that I wouldn't necessarily expect to be determinable.  You could probably write a query listing tables that are candidates for attaching to an existing partitioned table and then filter out those that are actually attached.

David J.

On 11/15/24 11:46, Bharani SV-forum wrote:
>   Team
> 
> Need exact SQL query to find List of Detach Partitioned Tables (Yet to 
> be Dropped)
> 
> The following is the query which i used, i am using and i found an bug 
> which is listing an newly created table (last week)

As David G. Johnston said how would you know it was formally a partition?:

https://www.postgresql.org/docs/current/sql-altertable.html

"
DETACH PARTITION partition_name [ CONCURRENTLY | FINALIZE ]

     This form detaches the specified partition of the target table. The 
detached partition continues to exist as a standalone table, but no 
longer has any ties to the table from which it was detached.

[...]
"

The only I could see this working is if you had a standard naming scheme 
for partitions and then you could do a regex search in pg_class for that 
pattern where relkind = 'r'.

> 
> SELECT relnamespace::regnamespace::text AS schema_name, relname AS 
> table_name
> FROM   pg_class c
> WHERE  NOT relispartition  -- !
> AND    relkind = 'r' and lower(relnamespace::regnamespace::text) not in 
> ('pg_catalog','partman','information_schema')  and
> lower(relnamespace::regnamespace::text) in ('XYZ')
> order by  relnamespace::regnamespace::text, relname ;

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X

From
Bharani SV-forum
Date:
Team
Pl Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X

Env = EC2 based Community PostgreSQL Ver 13.16.2

we will be performing upgrade of our EC2 server too along with new OS.

Need help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X
 
ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2
- ensure to capture all the pre.req meant for ver 15.10 are being met.
- shutdown db.
- take offline full backup (PG_DATA folder alone)  using OS command

Proposed-new EC2 server (with new Operating System version along Postgres Ver 15.10 Binaries)
- install postgres 15.10 binaries
- ensure to DISABLE auto startup and shutdown of postgres 15.10
-  Restore offline full backup (PG_DATA folder alone) using OS command
-  start performing pg_upgrade step to upgrade postgres from ver 13.16.2 to 15.10

please guide me, if i have missed any steps in the abovesaid process

To start new DB features, planning to rollout out the following feature's alone
a) TLE extension for password compliance
b) parallelize vacuum jobs to utilize -j option

On 12/2/24 14:18, Bharani SV-forum wrote:
> Team
> Pl Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 
> 15.X
> 
> Env = EC2 based Community PostgreSQL Ver 13.16.2
> 
> we will be performing upgrade of our EC2 server too along with new OS.
> 
> Need help in vetting my steps for Postgres DB upgrade from Ver 13.X to 
> ver 15.X
> *ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
> - ensure to capture all the pre.req meant for ver 15.10 are being met.
> - shutdown db.
> - take offline full backup (PG_DATA folder alone)  using OS command
> 
> *Proposed-new EC2 server (with new Operating System version along 
> Postgres Ver 15.10 Binaries)*
> - install postgres 15.10 binaries
> - ensure to DISABLE auto startup and shutdown of postgres 15.10
> -  Restore offline full backup (PG_DATA folder alone) using OS command
> -  start performing pg_upgrade step to upgrade postgres from ver 13.16.2 

This is not going to work, you need to have Postgres 13 installed also.

It all laid out here:

https://www.postgresql.org/docs/15/pgupgrade.html

In Usage section.

> to 15.10
> 
> please guide me, if i have missed any steps in the abovesaid process
> 
> To start new DB features, planning to rollout out the following 
> feature's alone
> a) TLE extension for password compliance
> b) parallelize vacuum jobs to utilize -j option
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




On Mon, Dec 2, 2024 at 5:18 PM Bharani SV-forum <esteembsv-forum@yahoo.com> wrote:
Team
Pl Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X

Env = EC2 based Community PostgreSQL Ver 13.16.2

we will be performing upgrade of our EC2 server too along with new OS.

Need help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X
 
ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2
- ensure to capture all the pre.req meant for ver 15.10 are being met.
- shutdown db.
- take offline full backup (PG_DATA folder alone)  using OS command

Proposed-new EC2 server (with new Operating System version along Postgres Ver 15.10 Binaries)
- install postgres 15.10 binaries
- ensure to DISABLE auto startup and shutdown of postgres 15.10
-  Restore offline full backup (PG_DATA folder alone) using OS command
-  start performing pg_upgrade step to upgrade postgres from ver 13.16.2 to 15.10

please guide me, if i have missed any steps in the abovesaid process

To start new DB features, planning to rollout out the following feature's alone
a) TLE extension for password compliance
b) parallelize vacuum jobs to utilize -j option

To migrate from one server to another while upgrading, one must use pg_dump/pg_restore OR Logical Replication.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
On 12/2/24 14:31, Ron Johnson wrote:
> On Mon, Dec 2, 2024 at 5:18 PM Bharani SV-forum 
> <esteembsv-forum@yahoo.com <mailto:esteembsv-forum@yahoo.com>> wrote:
> 
>     Team
>     Pl Help in vetting my steps for Postgres DB upgrade from Ver 13.X to
>     ver 15.X
> 
>     Env = EC2 based Community PostgreSQL Ver 13.16.2
> 
>     we will be performing upgrade of our EC2 server too along with new OS.
> 
>     Need help in vetting my steps for Postgres DB upgrade from Ver 13.X
>     to ver 15.X
>     *ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
>     - ensure to capture all the pre.req meant for ver 15.10 are being met.
>     - shutdown db.
>     - take offline full backup (PG_DATA folder alone)  using OS command
> 
>     *Proposed-new EC2 server (with new Operating System version along
>     Postgres Ver 15.10 Binaries)*
>     - install postgres 15.10 binaries
>     - ensure to DISABLE auto startup and shutdown of postgres 15.10
>     -  Restore offline full backup (PG_DATA folder alone) using OS command
>     -  start performing pg_upgrade step to upgrade postgres from ver
>     13.16.2 to 15.10
> 
>     please guide me, if i have missed any steps in the abovesaid process
> 
>     To start new DB features, planning to rollout out the following
>     feature's alone
>     a) TLE extension for password compliance
>     b) parallelize vacuum jobs to utilize -j option
> 
> 
> To migrate from one server to another while upgrading, one must use 
> pg_dump/pg_restore OR Logical Replication.

Really?

Then this:

https://www.postgresql.org/docs/current/pgupgrade.html

must be random nose.

> 
> -- 
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!

-- 
Adrian Klaver
adrian.klaver@aklaver.com




On 12/2/24 14:46, Adrian Klaver wrote:
> On 12/2/24 14:31, Ron Johnson wrote:
>> On Mon, Dec 2, 2024 at 5:18 PM Bharani SV-forum 
>> <esteembsv-forum@yahoo.com <mailto:esteembsv-forum@yahoo.com>> wrote:
>>
>>     Team
>>     Pl Help in vetting my steps for Postgres DB upgrade from Ver 13.X to
>>     ver 15.X
>>
>>     Env = EC2 based Community PostgreSQL Ver 13.16.2
>>
>>     we will be performing upgrade of our EC2 server too along with new 
>> OS.
>>
>>     Need help in vetting my steps for Postgres DB upgrade from Ver 13.X
>>     to ver 15.X
>>     *ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
>>     - ensure to capture all the pre.req meant for ver 15.10 are being 
>> met.
>>     - shutdown db.
>>     - take offline full backup (PG_DATA folder alone)  using OS command
>>
>>     *Proposed-new EC2 server (with new Operating System version along
>>     Postgres Ver 15.10 Binaries)*
>>     - install postgres 15.10 binaries
>>     - ensure to DISABLE auto startup and shutdown of postgres 15.10
>>     -  Restore offline full backup (PG_DATA folder alone) using OS 
>> command
>>     -  start performing pg_upgrade step to upgrade postgres from ver
>>     13.16.2 to 15.10
>>
>>     please guide me, if i have missed any steps in the abovesaid process
>>
>>     To start new DB features, planning to rollout out the following
>>     feature's alone
>>     a) TLE extension for password compliance
>>     b) parallelize vacuum jobs to utilize -j option
>>
>>
>> To migrate from one server to another while upgrading, one must use 
>> pg_dump/pg_restore OR Logical Replication.
> 
> Really?
> 
> Then this:
> 
> https://www.postgresql.org/docs/current/pgupgrade.html
> 
> must be random nose.

Oh yeah, that was smooth.

Second attempt:

... must be random noise.

> 
>>
>> -- 
>> Death to <Redacted>, and butter sauce.
>> Don't boil me, I'm still alive.
>> <Redacted> lobster!
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Re: Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X

From
Bharani SV-forum
Date:
Ron/Adrian
Thanks for your input.
Your suggestion is

option#1
 ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
-  ensure to capture all the pre.req meant for ver 15.10 are being  met.
     - enable logical replication tagged to proposed new EC2 server (with newer Higher OS Version ).


Proposed-new EC2 server (with new Operating System version along
    Postgres Ver 13.16.2 and 15.10 Binaries)*
     - install postgres 13.16.2 binaries
    - have postgres setup on par with existing setup and having proper logical replication 
    - install postgres 15.10 binaries
     - ensure to DISABLE auto startup and shutdown of postgres 13.16.2
      - ensure to DISABLE auto startup and shutdown of postgres 15.10
    - start postgres db ver 13.16.2 and ensure all are good. no errors in postgres log file
    -  start performing pg_upgrade step to upgrade postgres from ver 13.16.2 to 15.10

pl Vet the newer steps (revised version).


Regards
Bharani

On Monday, December 2, 2024 at 05:48:19 PM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/2/24 14:46, Adrian Klaver wrote:
> On 12/2/24 14:31, Ron Johnson wrote:
>> On Mon, Dec 2, 2024 at 5:18 PM Bharani SV-forum
>> <esteembsv-forum@yahoo.com <mailto:esteembsv-forum@yahoo.com>> wrote:
>>
>>     Team
>>     Pl Help in vetting my steps for Postgres DB upgrade from Ver 13.X to
>>     ver 15.X
>>
>>     Env = EC2 based Community PostgreSQL Ver 13.16.2
>>
>>     we will be performing upgrade of our EC2 server too along with new
>> OS.
>>
>>     Need help in vetting my steps for Postgres DB upgrade from Ver 13.X
>>     to ver 15.X
>>     *ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
>>     - ensure to capture all the pre.req meant for ver 15.10 are being
>> met.
>>     - shutdown db.
>>     - take offline full backup (PG_DATA folder alone)  using OS command
>>
>>     *Proposed-new EC2 server (with new Operating System version along
>>     Postgres Ver 15.10 Binaries)*
>>     - install postgres 15.10 binaries
>>     - ensure to DISABLE auto startup and shutdown of postgres 15.10
>>     -  Restore offline full backup (PG_DATA folder alone) using OS
>> command
>>     -  start performing pg_upgrade step to upgrade postgres from ver
>>     13.16.2 to 15.10
>>
>>     please guide me, if i have missed any steps in the abovesaid process
>>
>>     To start new DB features, planning to rollout out the following
>>     feature's alone
>>     a) TLE extension for password compliance
>>     b) parallelize vacuum jobs to utilize -j option
>>
>>
>> To migrate from one server to another while upgrading, one must use
>> pg_dump/pg_restore OR Logical Replication.
>
> Really?
>
> Then this:
>
> https://www.postgresql.org/docs/current/pgupgrade.html
>
> must be random nose.

Oh yeah, that was smooth.

Second attempt:

... must be random noise.


>
>>
>> --
>> Death to <Redacted>, and butter sauce.
>> Don't boil me, I'm still alive.
>> <Redacted> lobster!
>

--
Adrian Klaver
adrian.klaver@aklaver.com



On 12/2/24 15:41, Bharani SV-forum wrote:
> Ron/Adrian
> Thanks for your input.
> Your suggestion is
> 
> *option#1*
>   ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
> -  ensure to capture all the pre.req meant for ver 15.10 are being  met.
>       - enable logical replication tagged to proposed new EC2 server 

No, logical replication != pg_upgrade process.

> (with newer Higher OS Version ).
> 
> 
> Proposed-new EC2 server (with new Operating System version along
>      Postgres Ver 13.16.2 and 15.10 Binaries)*
>       - install postgres 13.16.2 binaries
>      - have postgres setup on par with existing setup and having proper 
> logical replication

Again, no.

>      - install postgres 15.10 binaries
>       - ensure to DISABLE auto startup and shutdown of postgres 13.16.2
>        - ensure to DISABLE auto startup and shutdown of postgres 15.10
>      - start postgres db ver 13.16.2 and ensure all are good. no errors 
> in postgres log file
>      -  start performing pg_upgrade step to upgrade postgres from ver 
> 13.16.2 to 15.10
> 
> pl Vet the newer steps (revised version).

I don't know how much clearer it can be, follow the step by step 
instructions shown here:

https://www.postgresql.org/docs/current/pgupgrade.html

"These are the steps to perform an upgrade with pg_upgrade:

[...]


"
> 
> 
> Regards
> Bharani
> 
> On Monday, December 2, 2024 at 05:48:19 PM EST, Adrian Klaver 
> <adrian.klaver@aklaver.com> wrote:
> 
> 
> On 12/2/24 14:46, Adrian Klaver wrote:
>  > On 12/2/24 14:31, Ron Johnson wrote:
>  >> On Mon, Dec 2, 2024 at 5:18 PM Bharani SV-forum
>  >> <esteembsv-forum@yahoo.com <mailto:esteembsv-forum@yahoo.com> 
> <mailto:esteembsv-forum@yahoo.com>> wrote:
>  >>
>  >>     Team
>  >>     Pl Help in vetting my steps for Postgres DB upgrade from Ver 13.X to
>  >>     ver 15.X
>  >>
>  >>     Env = EC2 based Community PostgreSQL Ver 13.16.2
>  >>
>  >>     we will be performing upgrade of our EC2 server too along with new
>  >> OS.
>  >>
>  >>     Need help in vetting my steps for Postgres DB upgrade from Ver 13.X
>  >>     to ver 15.X
>  >>     *ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
>  >>     - ensure to capture all the pre.req meant for ver 15.10 are being
>  >> met.
>  >>     - shutdown db.
>  >>     - take offline full backup (PG_DATA folder alone)  using OS command
>  >>
>  >>     *Proposed-new EC2 server (with new Operating System version along
>  >>     Postgres Ver 15.10 Binaries)*
>  >>     - install postgres 15.10 binaries
>  >>     - ensure to DISABLE auto startup and shutdown of postgres 15.10
>  >>     -  Restore offline full backup (PG_DATA folder alone) using OS
>  >> command
>  >>     -  start performing pg_upgrade step to upgrade postgres from ver
>  >>     13.16.2 to 15.10
>  >>
>  >>     please guide me, if i have missed any steps in the abovesaid process
>  >>
>  >>     To start new DB features, planning to rollout out the following
>  >>     feature's alone
>  >>     a) TLE extension for password compliance
>  >>     b) parallelize vacuum jobs to utilize -j option
>  >>
>  >>
>  >> To migrate from one server to another while upgrading, one must use
>  >> pg_dump/pg_restore OR Logical Replication.
>  >
>  > Really?
>  >
>  > Then this:
>  >
>  > https://www.postgresql.org/docs/current/pgupgrade.html 
> <https://www.postgresql.org/docs/current/pgupgrade.html>
>  >
>  > must be random nose.
> 
> Oh yeah, that was smooth.
> 
> Second attempt:
> 
> ... must be random noise.
> 
> 
>  >
>  >>
>  >> --
>  >> Death to <Redacted>, and butter sauce.
>  >> Don't boil me, I'm still alive.
>  >> <Redacted> lobster!
>  >
> 
> -- 
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> 
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Re: Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X

From
Bharani SV-forum
Date:
Adrian

Proposed new Server is intended to have higher OS Version (centos ver 9.0) and higher Postgres Version 15.10

Does logical replication will have issues , if the existing asis server is having Postgres ver 13.16.2 with Cent Os 7.0 
with the new server having higher OS version Centos Ver 9.0 and then propose to have the Postgres to be upgraded 
from ver 13.16.2 to 15.10

Hope u have understood my question

On Monday, December 2, 2024 at 06:47:10 PM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/2/24 15:41, Bharani SV-forum wrote:
> Ron/Adrian
> Thanks for your input.
> Your suggestion is
>
> *option#1*
>   ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
> -  ensure to capture all the pre.req meant for ver 15.10 are being  met.
>       - enable logical replication tagged to proposed new EC2 server

No, logical replication != pg_upgrade process.

> (with newer Higher OS Version ).
>
>
> Proposed-new EC2 server (with new Operating System version along
>      Postgres Ver 13.16.2 and 15.10 Binaries)*
>       - install postgres 13.16.2 binaries
>      - have postgres setup on par with existing setup and having proper
> logical replication

Again, no.

>      - install postgres 15.10 binaries
>       - ensure to DISABLE auto startup and shutdown of postgres 13.16.2
>        - ensure to DISABLE auto startup and shutdown of postgres 15.10
>      - start postgres db ver 13.16.2 and ensure all are good. no errors
> in postgres log file
>      -  start performing pg_upgrade step to upgrade postgres from ver
> 13.16.2 to 15.10
>
> pl Vet the newer steps (revised version).

I don't know how much clearer it can be, follow the step by step
instructions shown here:

https://www.postgresql.org/docs/current/pgupgrade.html

"These are the steps to perform an upgrade with pg_upgrade:

[...]


"
>
>
> Regards
> Bharani
>
> On Monday, December 2, 2024 at 05:48:19 PM EST, Adrian Klaver
> <adrian.klaver@aklaver.com> wrote:
>
>
> On 12/2/24 14:46, Adrian Klaver wrote:
>  > On 12/2/24 14:31, Ron Johnson wrote:
>  >> On Mon, Dec 2, 2024 at 5:18 PM Bharani SV-forum
>  >> <esteembsv-forum@yahoo.com <mailto:esteembsv-forum@yahoo.com>
> <mailto:esteembsv-forum@yahoo.com>> wrote:
>  >>
>  >>     Team
>  >>     Pl Help in vetting my steps for Postgres DB upgrade from Ver 13.X to
>  >>     ver 15.X
>  >>
>  >>     Env = EC2 based Community PostgreSQL Ver 13.16.2
>  >>
>  >>     we will be performing upgrade of our EC2 server too along with new
>  >> OS.
>  >>
>  >>     Need help in vetting my steps for Postgres DB upgrade from Ver 13.X
>  >>     to ver 15.X
>  >>     *ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
>  >>     - ensure to capture all the pre.req meant for ver 15.10 are being
>  >> met.
>  >>     - shutdown db.
>  >>     - take offline full backup (PG_DATA folder alone)  using OS command
>  >>
>  >>     *Proposed-new EC2 server (with new Operating System version along
>  >>     Postgres Ver 15.10 Binaries)*
>  >>     - install postgres 15.10 binaries
>  >>     - ensure to DISABLE auto startup and shutdown of postgres 15.10
>  >>     -  Restore offline full backup (PG_DATA folder alone) using OS
>  >> command
>  >>     -  start performing pg_upgrade step to upgrade postgres from ver
>  >>     13.16.2 to 15.10
>  >>
>  >>     please guide me, if i have missed any steps in the abovesaid process
>  >>
>  >>     To start new DB features, planning to rollout out the following
>  >>     feature's alone
>  >>     a) TLE extension for password compliance
>  >>     b) parallelize vacuum jobs to utilize -j option
>  >>
>  >>
>  >> To migrate from one server to another while upgrading, one must use
>  >> pg_dump/pg_restore OR Logical Replication.
>  >
>  > Really?
>  >
>  > Then this:
>  >
>  > https://www.postgresql.org/docs/current/pgupgrade.html
> <https://www.postgresql.org/docs/current/pgupgrade.html>
>  >
>  > must be random nose.
>
> Oh yeah, that was smooth.
>
> Second attempt:
>
> ... must be random noise.
>
>
>  >
>  >>
>  >> --
>  >> Death to <Redacted>, and butter sauce.
>  >> Don't boil me, I'm still alive.
>  >> <Redacted> lobster!
>  >
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>

>
>
>

--
Adrian Klaver
adrian.klaver@aklaver.com



On 12/2/24 15:52, Bharani SV-forum wrote:
> Adrian
> 
> Proposed new Server is intended to have higher OS Version (centos ver 
> 9.0) and higher Postgres Version 15.10

Alright I did not catch this " ... with new OS" from your original post. 
I saw "Take offline full backup (PG_DATA folder alone)  using OS 
command" and "Restore offline full backup (PG_DATA folder alone) using 
OS command" and assumed like to like on the OS, my mistake.

> 
> Does logical replication will have issues , if the existing asis server 
> is having Postgres ver 13.16.2 with Cent Os 7.0
> with the new server having higher OS version Centos Ver 9.0 and then 
> propose to have the Postgres to be upgraded
> from ver 13.16.2 to 15.10

Logical replication would not have issue with this as that is one of 
it's use cases. The question now becomes whether that is the quickest/ 
most efficient way to do this.

That depends on:

1) What is the size of database(s) you are dealing with?

2) What sort of downtime can you afford?

3) EC2 --> EC2, are they the same region?


> 
> Hope u have understood my question
> 
> On Monday, December 2, 2024 at 06:47:10 PM EST, Adrian Klaver 
> <adrian.klaver@aklaver.com> wrote:
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Re: Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X

From
Bharani SV-forum
Date:
Adrian
Noted about, Logical replication would not have issue with this as that is one of
it's use cases.


qsn1: What is the size of database(s) you are dealing with?
ans1: roughly 25 GB  (maximum size)

qsn2 : What sort of downtime can you afford?
ans2: can be maximum 30 mins or so

qsn3: EC2 --> EC2, are they the same region?
ans3: Right Question. I assume the same region

Can you pl provide your insight now
 

On Monday, December 2, 2024 at 07:20:52 PM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/2/24 15:52, Bharani SV-forum wrote:
> Adrian
>
> Proposed new Server is intended to have higher OS Version (centos ver
> 9.0) and higher Postgres Version 15.10

Alright I did not catch this " ... with new OS" from your original post.
I saw "Take offline full backup (PG_DATA folder alone)  using OS
command" and "Restore offline full backup (PG_DATA folder alone) using
OS command" and assumed like to like on the OS, my mistake.

>
> Does logical replication will have issues , if the existing asis server
> is having Postgres ver 13.16.2 with Cent Os 7.0
> with the new server having higher OS version Centos Ver 9.0 and then
> propose to have the Postgres to be upgraded
> from ver 13.16.2 to 15.10

Logical replication would not have issue with this as that is one of
it's use cases. The question now becomes whether that is the quickest/
most efficient way to do this.

That depends on:

1) What is the size of database(s) you are dealing with?

2) What sort of downtime can you afford?

3) EC2 --> EC2, are they the same region?



>
> Hope u have understood my question
>
> On Monday, December 2, 2024 at 06:47:10 PM EST, Adrian Klaver
> <adrian.klaver@aklaver.com> wrote:
>

--
Adrian Klaver
adrian.klaver@aklaver.com

Adrian,

OP is moving to a new VM when migrating to PG 15.  When was the "cross-server" feature added to pg_upgrade?

On Mon, Dec 2, 2024 at 5:48 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 12/2/24 14:46, Adrian Klaver wrote:
> On 12/2/24 14:31, Ron Johnson wrote:
>> On Mon, Dec 2, 2024 at 5:18 PM Bharani SV-forum
>> <esteembsv-forum@yahoo.com <mailto:esteembsv-forum@yahoo.com>> wrote:
>>
>>     Team
>>     Pl Help in vetting my steps for Postgres DB upgrade from Ver 13.X to
>>     ver 15.X
>>
>>     Env = EC2 based Community PostgreSQL Ver 13.16.2
>>
>>     we will be performing upgrade of our EC2 server too along with new
>> OS.
>>
>>     Need help in vetting my steps for Postgres DB upgrade from Ver 13.X
>>     to ver 15.X
>>     *ASIS-existing server = EC2 with Community PostgreSQL Ver 13.16.2*
>>     - ensure to capture all the pre.req meant for ver 15.10 are being
>> met.
>>     - shutdown db.
>>     - take offline full backup (PG_DATA folder alone)  using OS command
>>
>>     *Proposed-new EC2 server (with new Operating System version along
>>     Postgres Ver 15.10 Binaries)*
>>     - install postgres 15.10 binaries
>>     - ensure to DISABLE auto startup and shutdown of postgres 15.10
>>     -  Restore offline full backup (PG_DATA folder alone) using OS
>> command
>>     -  start performing pg_upgrade step to upgrade postgres from ver
>>     13.16.2 to 15.10
>>
>>     please guide me, if i have missed any steps in the abovesaid process
>>
>>     To start new DB features, planning to rollout out the following
>>     feature's alone
>>     a) TLE extension for password compliance
>>     b) parallelize vacuum jobs to utilize -j option
>>
>>
>> To migrate from one server to another while upgrading, one must use
>> pg_dump/pg_restore OR Logical Replication.
>
> Really?
>
> Then this:
>
> https://www.postgresql.org/docs/current/pgupgrade.html
>
> must be random nose.

Oh yeah, that was smooth.

Second attempt:

... must be random noise.

>
>>
>> --
>> Death to <Redacted>, and butter sauce.
>> Don't boil me, I'm still alive.
>> <Redacted> lobster!
>

--
Adrian Klaver
adrian.klaver@aklaver.com



--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
On 12/2/24 17:23, Ron Johnson wrote:
> Adrian,
> 
> OP is moving to a new VM when migrating to PG 15.  When was the 
> "cross-server" feature added to pg_upgrade?
> 

Moving to a new VM was not the issue, my mistake was thinking the OS 
version was staying the same.

Then:

On old VM:

"take offline full backup (PG_DATA folder alone)  using OS command"

On new VM:
"Restore offline full backup (PG_DATA folder alone) using OS command"

Followed by installing new Postgres version could be dealt with using 
pg_upgrade. Once I was corrected on what was actually going on then 
doing a dump/restore or logical replication became better choices.


-- 
Adrian Klaver
adrian.klaver@aklaver.com




Re: Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X

From
Bharani SV-forum
Date:
Team /Ron/Adrian

Wann to reconfirm
we have an setup with 

new server will be with 

will be following the following suggestion

On old VMexisting server with OS "Amazon Linux release 2 (Karoo) " present in aws "us-east-1 region" and along with postgresql ver 13.16.2  - community edn ]

 - "take offline full backup (PG_DATA folder alone)  using OS command"

On new VM [OS "Amazon Linux 2023 " in aws region=us-east-1 and intended db as "postgresql 15.10 - community edn" ] 

 - "Restore offline full backup (PG_DATA folder alone) using OS command"
- create postgres unix userid
- install postgresql ver 15.10 binaries
- setup respective env variable to point correctly for PG_DATA
- will follow "pg_upgrade"


my question is 
a) is the above said steps is correct with the given existing and proposed setup
b) is their any known issues using "cross over using pg_upgrade " option between the server's having below said operating system 
- source = existing server with OS = Amazon Linux release 2 (Karoo) " present in aws "us-east-1 region" and along with postgresql ver 13.16.2  - community edn 
vs
target - different server OS "Amazon Linux 2023 " in aws region=us-east-1 and intended db as "postgresql 15.10 - community edn"


On Tuesday, December 3, 2024 at 12:28:58 AM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/2/24 17:23, Ron Johnson wrote:
> Adrian,
>
> OP is moving to a new VM when migrating to PG 15.  When was the
> "cross-server" feature added to pg_upgrade?
>

Moving to a new VM was not the issue, my mistake was thinking the OS
version was staying the same.

Then:

On old VM:

"take offline full backup (PG_DATA folder alone)  using OS command"

On new VM:
"Restore offline full backup (PG_DATA folder alone) using OS command"

Followed by installing new Postgres version could be dealt with using
pg_upgrade. Once I was corrected on what was actually going on then
doing a dump/restore or logical replication became better choices.
On Wed, Dec 4, 2024 at 7:42 AM Bharani SV-forum <esteembsv-forum@yahoo.com> wrote:
Team /Ron/Adrian

Wann to reconfirm
we have an setup with 

new server will be with 

will be following the following suggestion

On old VMexisting server with OS "Amazon Linux release 2 (Karoo) " present in aws "us-east-1 region" and along with postgresql ver 13.16.2  - community edn ]

 - "take offline full backup (PG_DATA folder alone)  using OS command"

On new VM [OS "Amazon Linux 2023 " in aws region=us-east-1 and intended db as "postgresql 15.10 - community edn" ] 

 - "Restore offline full backup (PG_DATA folder alone) using OS command"
- create postgres unix userid
- install postgresql ver 15.10 binaries
- setup respective env variable to point correctly for PG_DATA
- will follow "pg_upgrade"


my question is 
a) is the above said steps is correct with the given existing and proposed setup

No.  You're vastly overcomplicating things.
 
b) is their any known issues using "cross over using pg_upgrade " option between the server's having below said operating system 

There is no "cross over using pg_upgrade" because it does not exist.

When migrating from OldServer to NewServer, your options are:
A) pg_dump/pg_restore
B) Logical Replication
 
- source = existing server with OS = Amazon Linux release 2 (Karoo) " present in aws "us-east-1 region" and along with postgresql ver 13.16.2  - community edn 
vs
target - different server OS "Amazon Linux 2023 " in aws region=us-east-1 and intended db as "postgresql 15.10 - community edn"

 
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

Re: Help in vetting my steps for Postgres DB upgrade from Ver 13.X to ver 15.X

From
Greg Sabino Mullane
Date:
On Wed, Dec 4, 2024 at 7:42 AM Bharani SV-forum <esteembsv-forum@yahoo.com> wrote:
a) is the above said steps is correct with the given existing and proposed setup

No. Here are some steps:

* Install Postgres on the new VM
However you get it, use the newest version you can. As of this writing, it is Postgres 17.2. Version 15 is okay, but going to 17 now means a better Postgres today, and no worrying about replacing v15 in three years.

* Create a new Postgres cluster
On the new VM, use the initdb command to create a new data directory.
Use the --data-checksums option

* Start it up
Adjust your postgresql.conf as needed
Adjust your pg_hba.conf as needed
Install any extensions used on the old VM
Start the cluster using the pg_ctl command (or systemctl)

* Test connection to the old vm from the new vm
On the new vm, see if you can connect to the old one:
psql -h oldvm -p 5432 --list
You may need to adjust firewalls and pg_hba.conf on the old vm.

* Copy the data
Run this on the new VM, adjusting ports as needed:
time pg_dumpall -h oldvm -p 5432 | psql -p 5432

Bonus points for doing this via screen/tmux to prevent interruptions

* Generate new statistics and vacuum
On the new vm, run:
psql -c 'vacuum freeze'
psql -c 'analyze'

* Test your application

* Setup all the other stuff (systemd integration, logrotate, cronjobs, etc.) as needed

As Peter mentioned earlier, this can be done without disrupting anything, and is easy to test and debug. The exact steps may vary a little, as I'm not familiar with how Amazon Linux packages Postgres, but the basics are the same.

Take it slow. Go through each of these steps one by one. If you get stuck or run into an issue, stop and solve it, reaching out to this list as necessary.

Cheers,
Greg

On 12/4/24 04:42, Bharani SV-forum wrote:
> Team /Ron/Adrian
> 
> Wann to reconfirm
> we have an setup with
> 
> new server will be with
> 
> will be following the following suggestion
> 
> *On old VM* [ existing server with OS "Amazon Linux release 2 (Karoo) " 
> present in aws "us-east-1 region" and along with postgresql ver 13.16.2  
> - community edn ]
> 
>   - "take offline full backup (PG_DATA folder alone)  using OS command"
> 
> *On new VM [OS "Amazon Linux 2023 " in aws region=us-east-1 and intended 
> db as "postgresql 15.10 - community edn" ] *
> 
>   - "Restore offline full backup (PG_DATA folder alone) using OS command"
> - create postgres unix userid
> - install postgresql ver 15.10 binaries
> - setup respective env variable to point correctly for PG_DATA
> - will follow "pg_upgrade"

That will not work as you would need an install of Postgres 13 on the 
new machine as well. And then there is the issue that the OS version 
changed as well. That would cause issues. Follow the process Greg Sabino 
Mullane posted.

> 
> 
> my question is
> a) is the above said steps is correct with the given existing and 
> proposed setup
> b) is their any known issues using "cross over using pg_upgrade " option 
> between the server's having below said operating system
> *- source = existing server with OS = *Amazon Linux release 2 (Karoo) " 
> present in aws "us-east-1 region" and along with postgresql ver 13.16.2  
> - community edn
> vs
> target - different server *OS "Amazon Linux 2023 " in aws 
> region=us-east-1 and intended db as "postgresql 15.10 - community edn"*
> *
> *
> *
> *
> On Tuesday, December 3, 2024 at 12:28:58 AM EST, Adrian Klaver 
> <adrian.klaver@aklaver.com> wrote:
> 
> 
> On 12/2/24 17:23, Ron Johnson wrote:
>  > Adrian,
>  >
>  > OP is moving to a new VM when migrating to PG 15.  When was the
>  > "cross-server" feature added to pg_upgrade?
>  >
> 
> Moving to a new VM was not the issue, my mistake was thinking the OS
> version was staying the same.
> 
> Then:
> 
> On old VM:
> 
> "take offline full backup (PG_DATA folder alone)  using OS command"
> 
> On new VM:
> "Restore offline full backup (PG_DATA folder alone) using OS command"
> 
> Followed by installing new Postgres version could be dealt with using
> pg_upgrade. Once I was corrected on what was actually going on then
> doing a dump/restore or logical replication became better choices.
> 
> 
> 
> -- 
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> 
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Team
As suggested from old server, post shutdown of DB, I did OS level dump of PG_DATA folder and had restored in the new server.

Any idea on how to install the older binary postgres 13.18 ( OS=Amazon Linux 2023.6.20241121) under a dedicated folder suffixed as the following e.g.) /usr/pgsql1318

System Admin had already installed newer version pgsql 15.08 binaries in the  new server (OS= Amazon Linux 2023.6.20241121) in the folder "/usr/bin/"

We were quoted , OS = Amazon Linux 2023.6.20241121 doesnot support postgres ver 15.10 (Community edition) under its AWS-EC2.

Regards




On Wednesday, December 4, 2024 at 12:04:47 PM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/4/24 04:42, Bharani SV-forum wrote:
> Team /Ron/Adrian
>
> Wann to reconfirm
> we have an setup with
>
> new server will be with
>
> will be following the following suggestion
>
> *On old VM* [ existing server with OS "Amazon Linux release 2 (Karoo) "
> present in aws "us-east-1 region" and along with postgresql ver 13.16.2 
> - community edn ]
>
>   - "take offline full backup (PG_DATA folder alone)  using OS command"
>
> *On new VM [OS "Amazon Linux 2023 " in aws region=us-east-1 and intended
> db as "postgresql 15.10 - community edn" ] *
>
>   - "Restore offline full backup (PG_DATA folder alone) using OS command"
> - create postgres unix userid
> - install postgresql ver 15.10 binaries
> - setup respective env variable to point correctly for PG_DATA
> - will follow "pg_upgrade"

That will not work as you would need an install of Postgres 13 on the
new machine as well. And then there is the issue that the OS version
changed as well. That would cause issues. Follow the process Greg Sabino
Mullane posted.

>
>
> my question is
> a) is the above said steps is correct with the given existing and
> proposed setup
> b) is their any known issues using "cross over using pg_upgrade " option
> between the server's having below said operating system
> *- source = existing server with OS = *Amazon Linux release 2 (Karoo) "
> present in aws "us-east-1 region" and along with postgresql ver 13.16.2 
> - community edn
> vs
> target - different server *OS "Amazon Linux 2023 " in aws
> region=us-east-1 and intended db as "postgresql 15.10 - community edn"*
> *
> *
> *
> *
> On Tuesday, December 3, 2024 at 12:28:58 AM EST, Adrian Klaver
> <adrian.klaver@aklaver.com> wrote:
>
>
> On 12/2/24 17:23, Ron Johnson wrote:
>  > Adrian,
>  >
>  > OP is moving to a new VM when migrating to PG 15.  When was the
>  > "cross-server" feature added to pg_upgrade?
>  >
>
> Moving to a new VM was not the issue, my mistake was thinking the OS
> version was staying the same.
>
> Then:
>
> On old VM:
>
> "take offline full backup (PG_DATA folder alone)  using OS command"
>
> On new VM:
> "Restore offline full backup (PG_DATA folder alone) using OS command"
>
> Followed by installing new Postgres version could be dealt with using
> pg_upgrade. Once I was corrected on what was actually going on then
> doing a dump/restore or logical replication became better choices.
>
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>

>
>
>

--
Adrian Klaver
adrian.klaver@aklaver.com



On 12/11/24 11:12, Bharani SV-forum wrote:
> Team
> As suggested from old server, post shutdown of DB, I did OS level dump 
> of PG_DATA folder and had restored in the new server.

If you follow the process shown here:

https://www.postgresql.org/message-id/CAKAnmmKZdhnhdNRd3OgDyEco9OPkT%3DqA_TeWMFMRvUM9pXauKg%40mail.gmail.com

You would not have to do the below.

> 
> Any idea on how to install the older binary postgres 13.18 ( OS=Amazon 
> Linux 2023.6.20241121) under a dedicated folder suffixed as the 
> following e.g.) /usr/pgsql1318
> 
> System Admin had already installed newer version pgsql 15.08 binaries in 
> the  new server (OS= Amazon Linux 2023.6.20241121) in the folder "/usr/bin/"
> 
> We were quoted , OS = Amazon Linux 2023.6.20241121 doesnot support 
> postgres ver 15.10 (Community edition) under its AWS-EC2.

That does not reflect well on Amazon Linux, that it is missing two 
critical bug releases.

> 
> Regards
> 
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Team
I am getting the following error.

pg_dump: error: error reading large object 2113418:

pg_dump: error: could not open large object 3391830: 

I tried to give this command DB name = abcefg

ALTER DATABASE abcefgd SET lo_compat_privileges=on;

and reran and once again , i am getting the same error

while doing using psql/pg_dump from old version server running 13.18 [ OS = Amazon Linux release 2 (Karoo) ].

Will be pg_dump and pg_restore to restore in the new VM with new OS [OS= amazon linux 2023] and new DB bin pgsql ver 15.09.

We were told by AWS team, in the new VM tagged OS [OS= amazon linux 2023] , pgsql Ver 13.16 is not supported

I cross checked
SELECT oid, count(*)  FROM pg_largeobject_metadata group by oid order by oid ;
Rows =  4260170 rows

Can you suggest


On Wednesday, December 11, 2024 at 03:57:31 PM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/11/24 11:12, Bharani SV-forum wrote:
> Team
> As suggested from old server, post shutdown of DB, I did OS level dump
> of PG_DATA folder and had restored in the new server.

If you follow the process shown here:

https://www.postgresql.org/message-id/CAKAnmmKZdhnhdNRd3OgDyEco9OPkT%3DqA_TeWMFMRvUM9pXauKg%40mail.gmail.com

You would not have to do the below.

>
> Any idea on how to install the older binary postgres 13.18 ( OS=Amazon
> Linux 2023.6.20241121) under a dedicated folder suffixed as the
> following e.g.) /usr/pgsql1318
>
> System Admin had already installed newer version pgsql 15.08 binaries in
> the  new server (OS= Amazon Linux 2023.6.20241121) in the folder "/usr/bin/"
>
> We were quoted , OS = Amazon Linux 2023.6.20241121 doesnot support
> postgres ver 15.10 (Community edition) under its AWS-EC2.

That does not reflect well on Amazon Linux, that it is missing two
critical bug releases.


>
> Regards
>
>
>

--
Adrian Klaver
adrian.klaver@aklaver.com



On 12/16/24 13:19, Bharani SV-forum wrote:
> Team
> I am getting the following error.
> 
> pg_dump: error: error reading large object 2113418:
> 
> pg_dump: error: could not open large object 3391830:

What user are you running pg_dump as?

What version of pg_dump?

> 
> I tried to give this command DB name = abcefg
> 
> ALTER DATABASE abcefgd SET lo_compat_privileges=on;
> 
> and reran and once again , i am getting the same error
> 
> while doing using psql/pg_dump from old version server running 13.18 [ 
> OS = Amazon Linux release 2 (Karoo) ].

It is either psql or pg_dump. psql is the CLI client for the Postgres 
server. If you are using psql as an alias for Postgres(sql), don't,  it 
only adds confusion.

> 
> Will be pg_dump and pg_restore to restore in the new VM with new OS [OS= 
> amazon linux 2023] and new DB bin pgsql ver 15.09.
> 
> We were told by AWS team, in the new VM tagged OS [OS= amazon linux 
> 2023] , pgsql Ver 13.16 is not supported

Not sure why? It still a community supported version and will be through 
November 2025.

> 
> *I cross checked*
> SELECT oid, count(*)  FROM pg_largeobject_metadata group by oid order by 
> oid ;
> Rows =  4260170 rows
> 
> Can you suggest
> 
> 
> On Wednesday, December 11, 2024 at 03:57:31 PM EST, Adrian Klaver 
> <adrian.klaver@aklaver.com> wrote:
> 
> 
> On 12/11/24 11:12, Bharani SV-forum wrote:
>  > Team
>  > As suggested from old server, post shutdown of DB, I did OS level dump
>  > of PG_DATA folder and had restored in the new server.
> 
> If you follow the process shown here:
> 
> https://www.postgresql.org/message-id/CAKAnmmKZdhnhdNRd3OgDyEco9OPkT%3DqA_TeWMFMRvUM9pXauKg%40mail.gmail.com
<https://www.postgresql.org/message-id/CAKAnmmKZdhnhdNRd3OgDyEco9OPkT%3DqA_TeWMFMRvUM9pXauKg%40mail.gmail.com>
> 
> You would not have to do the below.
> 
>  >
>  > Any idea on how to install the older binary postgres 13.18 ( OS=Amazon
>  > Linux 2023.6.20241121) under a dedicated folder suffixed as the
>  > following e.g.) /usr/pgsql1318
>  >
>  > System Admin had already installed newer version pgsql 15.08 binaries in
>  > the  new server (OS= Amazon Linux 2023.6.20241121) in the folder 
> "/usr/bin/"
>  >
>  > We were quoted , OS = Amazon Linux 2023.6.20241121 doesnot support
>  > postgres ver 15.10 (Community edition) under its AWS-EC2.
> 
> That does not reflect well on Amazon Linux, that it is missing two
> critical bug releases.
> 
> 
>  >
>  > Regards
>  >
>  >
>  >
> 
> -- 
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
> 
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




a) 
user = 
postgres

b)
pg_dump version = 
/usr/bin/pg_dump -V

pg_dump (PostgreSQL) 13.16

c)

DB version

select version () ;
                                                 version
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.16 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit

use this script for backup

pg_dump -Fp -p 5432 -U "$USERNAME" "$DATABASE" 

using username = postgres

for one of the DB (ver 13.16), it worked fine by doing oldvm = pg_dump from ver 13.16 and
later restoring in new VM with new OS and new db binary 15.09, post creating dummy db (appln related) and restoring the pg_dump from oldvm .

On Monday, December 16, 2024 at 05:19:31 PM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/16/24 13:19, Bharani SV-forum wrote:
> Team
> I am getting the following error.
>
> pg_dump: error: error reading large object 2113418:
>
> pg_dump: error: could not open large object 3391830:

What user are you running pg_dump as?

What version of pg_dump?

>
> I tried to give this command DB name = abcefg
>
> ALTER DATABASE abcefgd SET lo_compat_privileges=on;
>
> and reran and once again , i am getting the same error
>
> while doing using psql/pg_dump from old version server running 13.18 [
> OS = Amazon Linux release 2 (Karoo) ].

It is either psql or pg_dump. psql is the CLI client for the Postgres
server. If you are using psql as an alias for Postgres(sql), don't,  it
only adds confusion.

>
> Will be pg_dump and pg_restore to restore in the new VM with new OS [OS=
> amazon linux 2023] and new DB bin pgsql ver 15.09.
>
> We were told by AWS team, in the new VM tagged OS [OS= amazon linux
> 2023] , pgsql Ver 13.16 is not supported

Not sure why? It still a community supported version and will be through
November 2025.

>
> *I cross checked*
> SELECT oid, count(*)  FROM pg_largeobject_metadata group by oid order by
> oid ;
> Rows =  4260170 rows
>
> Can you suggest
>
>
> On Wednesday, December 11, 2024 at 03:57:31 PM EST, Adrian Klaver
> <adrian.klaver@aklaver.com> wrote:
>
>
> On 12/11/24 11:12, Bharani SV-forum wrote:
>  > Team
>  > As suggested from old server, post shutdown of DB, I did OS level dump
>  > of PG_DATA folder and had restored in the new server.
>
> If you follow the process shown here:
>
> https://www.postgresql.org/message-id/CAKAnmmKZdhnhdNRd3OgDyEco9OPkT%3DqA_TeWMFMRvUM9pXauKg%40mail.gmail.com <https://www.postgresql.org/message-id/CAKAnmmKZdhnhdNRd3OgDyEco9OPkT%3DqA_TeWMFMRvUM9pXauKg%40mail.gmail.com>
>
> You would not have to do the below.
>
>  >
>  > Any idea on how to install the older binary postgres 13.18 ( OS=Amazon
>  > Linux 2023.6.20241121) under a dedicated folder suffixed as the
>  > following e.g.) /usr/pgsql1318
>  >
>  > System Admin had already installed newer version pgsql 15.08 binaries in
>  > the  new server (OS= Amazon Linux 2023.6.20241121) in the folder
> "/usr/bin/"
>  >
>  > We were quoted , OS = Amazon Linux 2023.6.20241121 doesnot support
>  > postgres ver 15.10 (Community edition) under its AWS-EC2.
>
> That does not reflect well on Amazon Linux, that it is missing two
> critical bug releases.
>
>
>  >
>  > Regards
>  >
>  >
>  >
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>

>
>
>

--
Adrian Klaver
adrian.klaver@aklaver.com



On 12/16/24 14:30, Bharani SV-forum wrote:
> *a) *
> *user = *
> postgres
> 
> b)
> *pg_dump version = *
> /usr/bin/pg_dump -V
> 
> pg_dump (PostgreSQL) 13.16
> 
> c)
> 
> *DB version*
> 
> select version () ;
>                                                   version
> ----------------------------------------------------------------------------------------------------------
>   PostgreSQL 13.16 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 
> 20150623 (Red Hat 4.8.5-44), 64-bit
> 
> *use this script for backup*
> 
> pg_dump -Fp -p 5432 -U "$USERNAME" "$DATABASE"
> 
> using username = postgres
> 
> for one of the DB (ver 13.16), it worked fine by doing oldvm = pg_dump 
> from ver 13.16 and
> later restoring in new VM with new OS and new db binary 15.09, post 
> creating dummy db (appln related) and restoring the pg_dump from oldvm .
> 

That's nice, but the issue is the case that did not work.

What process where you running that caused the error?


-- 
Adrian Klaver
adrian.klaver@aklaver.com




Team
Being dev server, I noticed, we haven't performed analyze/vacuum process.

Noticed and re-triggerred vacuum full and analyze for all the application related db's

Re ran backup.

No issue's appeared during backup.

Not yet performed restoration in pgsql ver 15.09 in new vm with different OS.

Thank you for guiding me


On Monday, December 16, 2024 at 05:49:28 PM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/16/24 14:30, Bharani SV-forum wrote:
> *a) *
> *user = *
> postgres
>
> b)
> *pg_dump version = *
> /usr/bin/pg_dump -V
>
> pg_dump (PostgreSQL) 13.16
>
> c)
>
> *DB version*
>
> select version () ;
>                                                   version
> ----------------------------------------------------------------------------------------------------------
>   PostgreSQL 13.16 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
> 20150623 (Red Hat 4.8.5-44), 64-bit
>
> *use this script for backup*
>
> pg_dump -Fp -p 5432 -U "$USERNAME" "$DATABASE"
>
> using username = postgres
>
> for one of the DB (ver 13.16), it worked fine by doing oldvm = pg_dump
> from ver 13.16 and
> later restoring in new VM with new OS and new db binary 15.09, post
> creating dummy db (appln related) and restoring the pg_dump from oldvm .
>

That's nice, but the issue is the case that did not work.

What process where you running that caused the error?

Re: cannot drop a tablespace which never exists in pg_tablespace

From
Adrian Klaver
Date:
On 12/19/24 15:36, Bharani SV-forum wrote:
> 
> cannot drop a tablespace which never exists in pg_tablespace
> 
> I remember i had create previously an tablespace named " mq_data" , but 
> cannot find in pg_tablespace listing.
> 
> if i try to create the same tablespace name, it is giving error as " 
> already in use as a tablespace"
> how to force drop the pointer entry and the tablespace from postgres

From:

https://www.postgresql.org/docs/current/manage-ag-tablespaces.html

"The directory $PGDATA/pg_tblspc contains symbolic links that point to 
each of the non-built-in tablespaces defined in the cluster."

Is there a symlink at the above location?

Does the directory in the image have files?


> 
> Inline image
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Re: cannot drop a tablespace which never exists in pg_tablespace

From
Adrian Klaver
Date:
On 12/20/24 08:09, Bharani SV-forum wrote:
> Adrian
> Inline image
> 
> initially i had created tblspace outside pg_data env variable

Did you run CREATE TABLESPACE as shown below?:

https://www.postgresql.org/docs/current/sql-createtablespace.html

Did you ever use the tablespace?

> e.g PG_DATA env variable is defined to /XXX/YYYY/ABC/15/data
> 
> the tablespace was created under  /XXX/YYYY/ABC/15/tblspace/<<tbl_spcname>>/
> assume tablespace name is abc_data
> 
> *cd /XXX/YYYY/ABC/15/tblspace/abc_data/*
> ls -atl
> drwxr-x---. 2 postgres postgres  6 Dec 19 22:08 PG_15_202209061
> 
> ls -altR
> drwxr-x---. 2 postgres postgres  6 Dec 19 22:08 PG_15_202209061
> 
> i reconfirmed
> SELECT * FROM pg_tablespace ;
>   oid  |  spcname   | spcowner | spcacl | spcoptions
> ------+------------+----------+--------+------------
>   1663 | pg_default |       10 |        |
>   1664 | pg_global  |       10 |        |
> 
> not having any entry about tablespace abc_data
> 
> Can you guide
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Re: cannot drop a tablespace which never exists in pg_tablespace

From
Bharani SV-forum
Date:
I found the culprit 
env variable was defined as PG_DATA inlieu of PGDATA

cleared and dropped it
and restarted db
and created once again tablespace in the desired location and it worked

Thank You
Regards

On Friday, December 20, 2024 at 11:50:20 AM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/20/24 08:09, Bharani SV-forum wrote:
> Adrian
> Inline image
>
> initially i had created tblspace outside pg_data env variable

Did you run CREATE TABLESPACE as shown below?:

https://www.postgresql.org/docs/current/sql-createtablespace.html

Did you ever use the tablespace?


> e.g PG_DATA env variable is defined to /XXX/YYYY/ABC/15/data
>
> the tablespace was created under  /XXX/YYYY/ABC/15/tblspace/<<tbl_spcname>>/
> assume tablespace name is abc_data
>
> *cd /XXX/YYYY/ABC/15/tblspace/abc_data/*
> ls -atl
> drwxr-x---. 2 postgres postgres  6 Dec 19 22:08 PG_15_202209061
>
> ls -altR
> drwxr-x---. 2 postgres postgres  6 Dec 19 22:08 PG_15_202209061
>
> i reconfirmed
> SELECT * FROM pg_tablespace ;
>   oid  |  spcname   | spcowner | spcacl | spcoptions
> ------+------------+----------+--------+------------
>   1663 | pg_default |       10 |        |
>   1664 | pg_global  |       10 |        |
>
> not having any entry about tablespace abc_data
>
> Can you guide
>

--
Adrian Klaver
adrian.klaver@aklaver.com



 Team
I have the need to have postgresql db running in multiuser mode and do my needed tasks for few mins.

How to restrict all the application layer , not to get connected with the postgres db ,
during my specific time window
 
I am aware of their application layer - username

Changing password is the last option

Any tips

On 12/20/24 11:25, Y_Bharani_mbsv wrote:
>   Team
> I have the need to have postgresql db running in multiuser mode and do 
> my needed tasks for few mins.

What are the tasks and why do you think they can't be run concurrently 
with other users?

> 
> How to restrict all the application layer , not to get connected with 
> the postgres db ,
> during my specific time window
> I am aware of their application layer - username
> 
> Changing password is the last option
> 
> Any tips
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




On Fri, Dec 20, 2024 at 2:25 PM Y_Bharani_mbsv <mailbsv@yahoo.com> wrote:
 Team
I have the need to have postgresql db running in multiuser mode and do my needed tasks for few mins.

How to restrict all the application layer , not to get connected with the postgres db ,
during my specific time window

1. Create a pg_hba_maintmode.conf with only the relevant hosts in it.
2. Copy pg_hba.conf to pg_hba_multi.conf.
3. Copy pg_hba_maintmode.conf to pg_hba.conf.
4. pg_ctl reload.
5. Use pg_stat_activity and pg_cancel_backend() to kill the application connections.
6. Do your work.
7. Copy pg_hba_multi.conf to pg_hba.conf.
8. pg_ctl reload

Or... just shut down the user application.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
TQ

On Friday, December 20, 2024 at 03:26:30 PM EST, Ron Johnson <ronljohnsonjr@gmail.com> wrote:


On Fri, Dec 20, 2024 at 2:25 PM Y_Bharani_mbsv <mailbsv@yahoo.com> wrote:
 Team
I have the need to have postgresql db running in multiuser mode and do my needed tasks for few mins.

How to restrict all the application layer , not to get connected with the postgres db ,
during my specific time window

1. Create a pg_hba_maintmode.conf with only the relevant hosts in it.
2. Copy pg_hba.conf to pg_hba_multi.conf.
3. Copy pg_hba_maintmode.conf to pg_hba.conf.
4. pg_ctl reload.
5. Use pg_stat_activity and pg_cancel_backend() to kill the application connections.
6. Do your work.
7. Copy pg_hba_multi.conf to pg_hba.conf.
8. pg_ctl reload

Or... just shut down the user application.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
I am having heavy polling into the database and need to perform certain tasks without any application interference.


On Friday, December 20, 2024 at 03:13:21 PM EST, Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 12/20/24 11:25, Y_Bharani_mbsv wrote:
>   Team
> I have the need to have postgresql db running in multiuser mode and do
> my needed tasks for few mins.

What are the tasks and why do you think they can't be run concurrently
with other users?


>
> How to restrict all the application layer , not to get connected with
> the postgres db ,
> during my specific time window
> I am aware of their application layer - username
>
> Changing password is the last option
>
> Any tips

>

--
Adrian Klaver
adrian.klaver@aklaver.com