Hi Tom Lane,
After removing our patch to change FATAL to LOG, we are not observing the crash
now.
Thank you for your support. We were struck with this issue for a while.
Regards,
Sandhya
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Friday, May 12, 2017 10:08 PM
On Fri, May 12, 2017 at 12:38 PM, Tom Lane wrote:
> I can't draw any other conclusion but that you've hacked something
> to make FATAL act like LOG. Which is a fatal mistake.
I see what you did there.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
"K S, Sandhya (Nokia - IN/Bangalore)" writes:
> I have filtered the logs based on PID (19825) to see if this helps to
> debug the issue further.
Is this really a stock Postgres build?
The proximate cause of the PANIC is that the startup process is seeing
other processes active even though it has
Hi Merlin,
Below is the log captured when the crash was encountered.
STATEMENT: select count(1) from pg_ls_dir(current_setting('data_directory'))
where pg_ls_dir = 'backup_label'
LOG: 0: duration: 4.083 ms
LOCATION: exec_simple_query, postgres.c:1145
DEBUG: 0: shmem_exit(0): 7 callb
On Tue, Apr 25, 2017 at 8:44 AM, K S, Sandhya (Nokia - IN/Bangalore)
wrote:
> Hello,
>
> Did you get a chance to take a look into the issue?
>
> Please consider it with high priority. We will be awaiting your inputs.
This email is heavily cross posted, which is obnoxious. Can you paste
the relev
