Seems to be working fine now that I've upgraded to 12.1. I'll keep an eye
out for 12.2. However, we are not using a before row update trigger. We are
using an after insert trigger on the containers table though.
Thanks,
Doug
On Tue, Feb 4, 2020 at 2:34 PM Tom Lane wrote:
> Doug Roberts writes
Doug Roberts writes:
> Hopefully the following stack trace is more helpful.
> Exception thrown at 0x000140446403 in postgres.exe: 0xC005: Access
> violation reading location 0xFFF8. occurred
>> postgres.exe!pfree(void * pointer) Line 1033 C
> postgres.exe!tts_buffer_heap_cl
Hello,
Hopefully the following stack trace is more helpful.
Exception thrown at 0x000140446403 in postgres.exe: 0xC005: Access
violation reading location 0xFFF8. occurred
> postgres.exe!pfree(void * pointer) Line 1033 C
postgres.exe!tts_buffer_heap_clear(TupleTableSlot * sl
On 2/4/20 6:20 AM, Doug Roberts wrote:
So how did containers_reset_recirc() come to clash with
containers_add_update()?
They are clashing because another portion of our system is running and
updating containers. The reset recirc function was run at the same time
to see how our system and the
Sure. Ok then.
On Tue, Feb 4, 2020 at 11:18 AM Adrian Klaver
wrote:
> On 2/4/20 8:06 AM, Doug Roberts wrote:
> > Hello,
> >
> > Here is a stacktrace of what happened before and after the crash.
>
> Actually the below is the Postgres log. Per Tom's previous post the
> procedure to get a stack tra
On 2/4/20 8:06 AM, Doug Roberts wrote:
Hello,
Here is a stacktrace of what happened before and after the crash.
Actually the below is the Postgres log. Per Tom's previous post the
procedure to get a stack trace can be found here:
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_
Hello,
Here is a stacktrace of what happened before and after the crash.
Thanks,
Doug
2020-02-04 10:26:16.841 EST [20788] [0] LOG: 0: server process (PID
12168) was terminated by exception 0xC005
2020-02-04 10:26:16.841 EST [20788] [0] DETAIL: Failed process was
running: select CONTAI
> So how did containers_reset_recirc() come to clash with
> containers_add_update()?
They are clashing because another portion of our system is running and
updating containers. The reset recirc function was run at the same time to
see how our system and the database would handle it.
The recirc st
Adrian Klaver writes:
> Please reply to list also.
> On 2/3/20 2:18 PM, Doug Roberts wrote:
>> Here is what the reset recirc function is doing.
>> ...
>> UPDATE containers
>> ...
> So how did containers_reset_recirc() come to clash with
> containers_add_update()?
If this is PG 12.0 or 12.1
On 2/3/20 2:18 PM, Doug Roberts wrote:
Please reply to list also.
Ccing list.
Adrian,
Here is what the reset recirc function is doing.
CREATE OR REPLACE FUNCTION containers_reset_recirc
(
in_uid INTEGER
)
RETURNS INTEGER
AS $BODY$
DECLARE regex VARCHAR(50);
BEGIN
SELECT concat(',
Doug Roberts writes:
> I'm having an issue where a process in Postgres is crashing and cause the
> server to go into recovery mode.
Can you reduce this to a self-contained test case for others to try?
If not, you'll have to do the initial investigation yourself.
A stack trace from the crash woul
On 2/3/20 1:43 PM, Doug Roberts wrote:
Hello,
I'm having an issue where a process in Postgres is crashing and cause
the server to go into recovery mode.
I'm getting the following errors in the log.
2020-02-03 14:12:57.473 EST [11992] [0]WARNING: 57P02: terminating
connection because of cra
Hello,
I'm having an issue where a process in Postgres is crashing and cause the
server to go into recovery mode.
I'm getting the following errors in the log.
2020-02-03 14:12:57.473 EST [11992] [0]WARNING: 57P02: terminating
connection because of crash of another server process
2020-02-03 14:1
13 matches
Mail list logo
