Thread: Windows 2016 server crashed after changes in Postgres 15.8 pgAdmin

This seems like a combination of (at least) two independent issues - the
pgadmin issue and the crash.

On 11/19/24 17:44, Sanjay Khatri wrote:
> Dear,
>    Last week I installed Postgres 15.8 on my Windows server 2016, I
> installed the pgadmin thats comes packed with postgresql installer.
> I already have postgres 12.1 with pgAdmin installed on my server.
> After installing Postgres 15.8, the respective pgAdmin was not working,
> it showed error 'Postgres server could not be contacted' 
> But the old pgAdmin(of Postgres12) was working fine, but was not
> displaying the postgres15 server on server list on pgAdmin.

I don't use pgadmin (or Windows) so I don't have any ideas why it might
be having these connection problems, and I'm not sure I quite understand
what you did. But it seems the new 15.8 server simply was not running,
that would explain all the symptoms.

> But, I wanted to work on the new pgAdmin (which was installed with
> postgres15). So I tried to find the solution on internet, and I got the
> solution. It was just to delete the pgAdmin.bak file from
> 'C\Users\Username\AppData\Roaming\pgAdmin\'
> And I did that and It worked, the bew PgAdmin started to work, it also
> displayed the Postgres15 connection se server list.

That is weird, TBH. No idea why deleting a .bak file would matter.

> But after 2 hours, my Windows Server 2016 crashed, and I am not able to
> boot my system. So on hard restart the system and it restarted well. And
> I quickly uninstalled the Postgres15 with its pgadmin from the machine.
> But the system crashed again after uninstalling the postgres 15. Now I
> am not able to boot the system. Its been 2 days the system is not able
> to boot.
> The system is on dell iDrac PowerEdge M6300.
> Is there any solution for this, I can try the solution if you suggest.
> We cannot format the Storage as our data is within the hardisk (Raid)
> type. And we dont have any data backup too.
> Please help if possible

It's very unlikely a Postgres issue would make the whole system crash,
particularly in a way that prevents it from booting again. I don't think
anyone will be able to help you without more info - you need to make it
boot again, inspect the Postgres logs, etc.


regards

-- 
Tomas Vondra

> On 20 Nov 2024, at 13:36, Tomas Vondra <tomas@vondra.me> wrote:
> On 11/19/24 17:44, Sanjay Khatri wrote:

>> And we dont have any data backup too.

This will be your first priority once the system is up and running again, maybe
even to the point of planning for what immediate action to take before the
system boots to be able to act quickly in case it falls over again.

> It's very unlikely a Postgres issue would make the whole system crash,
> particularly in a way that prevents it from booting again.

Agreed, especially since this crash reportedly happened after uninstalling
postgres.  If the uninstaller could corrupt the OS like that I have a feeling
we'd heard about it by now.

> I don't think
> anyone will be able to help you without more info - you need to make it
> boot again, inspect the Postgres logs, etc.

I'm not familiar with Dell blade enclosures but if there is a similar system to
the iLO Lights Out console that HP ships I would start there (a quick Google
search hints at ePSA).

--
Daniel Gustafsson

> On 20 Nov 2024, at 14:34, Sanjay Khatri <sanjaykhatri218@gmail.com> wrote:
>
> These are the errors from the logs of iDrac M630.
> I uninstalled the Postgres 15.8 , once I got the connection. But sadly the server disconnected again and crashed,
evenafter uninstalling. 
> No I am not able to boot it.

I'm going to go out on a limb and say that this isn't a postgres bug, and
highly unlikely to be caused by one.  This smells like broken hardware and/or
corrupted BIOS/firmware, you should contact your hardware vendor for support.

--
Daniel Gustafsson

Yes...I will....but in case someone could provide help it would be good. Rest I will contact the Hardware Support.

We tried it on another server with similar configurations.
Just installed the Postgres 15 and its PgAdmin.
Kept the server ONN for the whole day, the server was okay.
But then we tried the pgAdmin workaround by deleting the pgAdmin.bak file in  'AppData/Roaming/pgAdmin' and restarted the PgAdmin.
Soon within an hour the server crashed. Its happening when PgAdmin workaround is performed.
Do Let me know if someone else faced the same issue?

> On 21 Nov 2024, at 04:22, Sanjay Khatri <sanjaykhatri218@gmail.com> wrote:
>
> We tried it on another server with similar configurations.
> Just installed the Postgres 15 and its PgAdmin.
> Kept the server ONN for the whole day, the server was okay.
> But then we tried the pgAdmin workaround by deleting the pgAdmin.bak file in  'AppData/Roaming/pgAdmin' and restarted
thePgAdmin.  
> Soon within an hour the server crashed. Its happening when PgAdmin workaround is performed.
> Do Let me know if someone else faced the same issue?

Just to make sure we're talking about the same thing.  Did Windows crash and
required a restart when you removed a file from pgAdmin, or did the server get
bricked and refused to boot at all with systems diagnostics issues?

Also, I assume these machines are sitting behind ample firewall protection to
keep outside bad actors from reaching them?

--
Daniel Gustafsson

Yes we are talking about same thing.
But this time a different server with Similar configuration.
On deleting the pgAdmin.bak file after which I restarted pgAdmin. But after an hour or two, the machine crashed and refuses to boot.
And yes these machines have enough firewall protection.

> On Thu, 21 Nov 2024, 17:46 Daniel Gustafsson, <daniel@yesql.se> wrote:
> > On 21 Nov 2024, at 04:22, Sanjay Khatri <sanjaykhatri218@gmail.com> wrote:
> >
> > We tried it on another server with similar configurations.
> > Just installed the Postgres 15 and its PgAdmin.
> > Kept the server ONN for the whole day, the server was okay.
> > But then we tried the pgAdmin workaround by deleting the pgAdmin.bak file in  'AppData/Roaming/pgAdmin' and
restartedthe PgAdmin.  
> > Soon within an hour the server crashed. Its happening when PgAdmin workaround is performed.
> > Do Let me know if someone else faced the same issue?
>
> Just to make sure we're talking about the same thing.  Did Windows crash and
> required a restart when you removed a file from pgAdmin, or did the server get
> bricked and refused to boot at all with systems diagnostics issues?
>
> On 21 Nov 2024, at 14:50, Sanjay Khatri <sanjaykhatri218@gmail.com> wrote:
>
> Yes we are talking about same thing.
> But this time a different server with Similar configuration.
> On deleting the pgAdmin.bak file after which I restarted pgAdmin. But after an hour or two, the machine crashed and
refusesto boot. 

If removing a file from pgAdmin can brick your server (regardless of it being
standard operating procedure or not), then I think it's something which the
pgAdmin developers should be made aware of.

--
Daniel Gustafsson

On 11/21/24 15:03, Daniel Gustafsson wrote:
>> On Thu, 21 Nov 2024, 17:46 Daniel Gustafsson, <daniel@yesql.se> wrote:
>>> On 21 Nov 2024, at 04:22, Sanjay Khatri <sanjaykhatri218@gmail.com> wrote:
>>>
>>> We tried it on another server with similar configurations.
>>> Just installed the Postgres 15 and its PgAdmin.
>>> Kept the server ONN for the whole day, the server was okay.
>>> But then we tried the pgAdmin workaround by deleting the pgAdmin.bak file in  'AppData/Roaming/pgAdmin' and
restartedthe PgAdmin. 
 
>>> Soon within an hour the server crashed. Its happening when PgAdmin workaround is performed. 
>>> Do Let me know if someone else faced the same issue?
>>
>> Just to make sure we're talking about the same thing.  Did Windows crash and
>> required a restart when you removed a file from pgAdmin, or did the server get
>> bricked and refused to boot at all with systems diagnostics issues?
>>
>> On 21 Nov 2024, at 14:50, Sanjay Khatri <sanjaykhatri218@gmail.com> wrote:
>>
>> Yes we are talking about same thing.
>> But this time a different server with Similar configuration.
>> On deleting the pgAdmin.bak file after which I restarted pgAdmin. But after an hour or two, the machine crashed and
refusesto boot.
 
> 
> If removing a file from pgAdmin can brick your server (regardless of it being
> standard operating procedure or not), then I think it's something which the
> pgAdmin developers should be made aware of.
> 

Color me skeptical. Weird unexpected things happen, but I simply don't
see how removing a .bak file from a regular application, could break the
BIOS and cause machine check exceptions there. These things are at least
two or three steps apart (BIOS <-> OS <-> application).

It's far more likely this is just a traditional hardware issue. If you
search for "dell machine check error" you'll find plenty of similar
reports. I only checked a couple, but it's invariably some due to some
hardware issue.


regards

-- 
Tomas Vondra

Yeah maybe, we contacted a Hardware Engineer, he told to clean the RAM, etc. If still does not works, then some issue with the motherboard.

But my concern is it occured only after deleting the pgAdmin.bak file.

On Thu, Nov 21, 2024 at 9:53 AM Dave Page <dpage@pgadmin.org> wrote:
> Speaking as a pgAdmin dev, and someone with a fair amount of Windows experience over the years, I'd say there is
approximatelyzero chance that deleting a file from a user's roaming profile directory would brick a server, especially
abackup of the pgAdmin configuration database (which is a SQLite file). 

I know a lot less about Windows than you do, but I'm sure you're
correct, especially because the crash happened "an hour or two" after
deleting pgAdmin.bak.

This whole discussion seems quite silly to me.

--
Robert Haas
EDB: http://www.enterprisedb.com

I know its hard to believe this. But you can try doing this from your side and respond here back again.

Yes...I have myself installed pgAmdin more than 50 times so far. But this, for the first time ever I have faced this issue. Just try deleting the pgAdmin.bak file for the pg15.8 on a Windows server 2016.
Try doing that, lets see.