Marc writes:
> To whom do we report our findings regarding this issue ?
EDB is already on it:
https://www.postgresql.org/message-id/CA%2BOCxoz0bWi%2BR2WpocfkD20Lgrg69z1jQ_SZd-zmdzHW0zt%2Bbg%40mail.gmail.com
regards, tom lane
On 2/27/20 9:08 AM, Marc wrote:
Hello Tom,
To whom do we report our findings regarding this issue ?
Since it is an EDB hack I would try the contact form at the bottom of
the this page:
https://www.enterprisedb.com/downloads/postgres-postgresql-downloads
I can offer you a Belgian waffle t
Hello Tom,
To whom do we report our findings regarding this issue ?
I can offer you a Belgian waffle to go with you caffeine.
Kindest Regards,
Marc
On 25 Feb 2020, at 10:35, Nick Renders wrote:
Hi Tom,
1. we used the EDB installer.
2. turning JIT off did make the problem go away. So I
Hi Tom,
1. we used the EDB installer.
2. turning JIT off did make the problem go away. So I guess this was
causing the Postgres process to crash all along.
Thanks for the help,
Nick
On 24 Feb 2020, at 16:24, Tom Lane wrote:
"Nick Renders" writes:
We have set up a new test environment ru
"Nick Renders" writes:
> We have set up a new test environment running PostgreSQL v12.2 on macOS
> 10.14 and the issue is still there.
Some nearby threads prompt these two questions:
1. Are you using your own build, or is this from EDB's installer?
2. If the latter, does turning JIT off ("set
We have set up a new test environment running PostgreSQL v12.2 on macOS
10.14 and the issue is still there.
One thing I noticed, is that the returning columns do not affect the
behaviour:
SELECT * FROM f_gsxws_schedule WHERE UPPER(gwsc_dossier) = 'TEST'
and
SELECT gwsc_sequence FROM f
Hi Thomas,
We are setting up a new test environment with 12.1.
Once it is running, I'll try out those commands and get back with the
results.
Thanks,
Nick Renders
On 11 Feb 2020, at 2:51, Thomas Munro wrote:
On Mon, Feb 10, 2020 at 4:35 AM Marc wrote:
We will keep the 12.1 in place so th
On Mon, Feb 10, 2020 at 4:35 AM Marc wrote:
> We will keep the 12.1 in place so that we can run additional tests to assist
> to pin-point the issue.
>
> Feel free to ask but allow us to recover from these hectic days ;-)
Here's how to get a stack so we can see what it was doing, assuming
you hav
Marc writes:
> Adrian, Christoph, Tom,
>
> We identified as the problem being persistent on all tables with many
> records ( +600K ) and they all had a JSONB column ( we feel that
> might be related )
Did you remember to re-analyze all tables after importing the data?
Autovac probably will have
On Sun, Feb 9, 2020 at 11:46 AM Tom Lane wrote:
> "Nick Renders" writes:
> > When we do the following statement:
> > SELECT * FROM f_gsxws_schedule WHERE UPPER(gwsc_dossier) = 'TEST'
> > the Postgres service restarts.
>
> Hm.
>
> > Here is what is logged:
> > 2020-02-08 20:21:19.942 CET [83
Adrian, Christoph, Tom,
We identified as the problem being persistent on all tables with many
records ( +600K ) and they all had a JSONB column ( we feel that might
be related )
Luckily we were able to downgraded to version 11.6 with the same system
MacOS 10.14.6 so that the OS impact can ru
On 2/8/20 2:24 PM, Marc wrote:
Adrian,
Old production server was postgres 9.6 with Mac0S 10.9 so much older
than the “new” server. ( Now MacOS 10.14 Postgres 12.1 )
After sudden restart of the cpu we started having issues, part of the
data that is lost TOAST. . . and we also started having iss
"Nick Renders" writes:
> When we do the following statement:
> SELECT * FROM f_gsxws_schedule WHERE UPPER(gwsc_dossier) = 'TEST'
> the Postgres service restarts.
Hm.
> Here is what is logged:
> 2020-02-08 20:21:19.942 CET [83892] LOG: server process (PID 85456) was
> terminated by signal
## Nick Renders (postg...@arcict.com):
> 2020-02-08 20:21:19.942 CET [83892] LOG: server process (PID 85456)
> was terminated by signal 9: Killed: 9
Signal 9 sounds like OOM (or manual intervention). What's in dmesg?
Regards,
Christoph
--
Spare Space
Adrian,
Old production server was postgres 9.6 with Mac0S 10.9 so much older
than the “new” server. ( Now MacOS 10.14 Postgres 12.1 )
After sudden restart of the cpu we started having issues, part of the
data that is lost TOAST. . . and we also started having issues when
TRUNCATING certain ta
On 2/8/20 12:28 PM, Marc wrote:
Adrian,
Everything was a clean install ( MacOS Mojave and Postgres )
Export and import were done with the latest version of PGAdmin.
Please advise if we can provide you with anything ( logging etc . . . )
Is there a possibility to downgrade to version 11 ?
A
Adrian,
Everything was a clean install ( MacOS Mojave and Postgres )
Export and import were done with the latest version of PGAdmin.
Please advise if we can provide you with anything ( logging etc . . . )
Is there a possibility to downgrade to version 11 ?
We upgraded over the weekend becaus
On 2/8/20 12:09 PM, Nick Renders wrote:
Hi,
We have just upgraded our Postgres 9.6 database to 12.1 (pg_dumpall ->
pg_restore on a clean installation) and now we are having some issues
with one of our tables.
When we do the following statement:
SELECT * FROM f_gsxws_schedule WHERE UPPE
18 matches
Mail list logo
