Hi Matsumura-san,
Thank you for your explaining.
> An important point of the route is that it calls PQprepare() and PQprepare()
> needs type-Oid list. (Idea-1) If we fix for Prepare statement with AS clause
> and
> with parameter list to walk through the route, preprocessor must parse the
> pa
Hi Meskes-san,
> Ah right, my bad. The workaround should have been:
Thank you. It works.
> As for the PREPARE statement itself, could you try the attached small
> patch please.
It works well for my statement
"EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id = $1;".
Howe
Hi Meskes-san,
Thank you for your replying.
> Please try this instead:
>
> EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id
> = $1;
> EXEC SQL EXECUTE test_prep using 2;
>
> This should work.
I tried as follows.
EXEC SQL PREPARE test_pr
Hi,
In the PostgreSQL Documentation, both ECPG PREPARE and SQL statement PREPARE
can be used in ECPG [1].
However, SQL statement PREPARE does not work.
I wrote the source code as follows.
EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id = $
Hi,
Thank you for replying.
> Like a couple of others on this thread I doubt that lowering the elevel
> here would be a good thing, as keeping it noisy has been what allows to
> know that something has gone wrong, no? The current behavior is
> useful.
Currently, I agree with you.
I cancel my
Hi Noah, Magnus and Tsunakawa-san,
Thank you for replying.
> Can you adopt pgbouncer, to reduce
> the frequency of starting new backend processes? That should improve your
> performance, too.
Actually, before I found that F-secure causes this message,
I recommend my customer to use connection
Hi,
I found the reason of the message.
My customer uses "F-secure" antivirus software.
There are several pages that indicate F-secure causes this message such as [1].
I told my customer to stop F-secure and report to the vendor.
Anyway, I think this message is not helpful to administrators and
Hi,
Thank you for replying.
> You might be right, but maybe we should first try to understand why
> this is happening so frequently. Maybe it's not that normal.
I found past threads [1] and [2].
In thread [1], the error is mentioned as an ASLR problem.
In thread [2], the patch is provided wh
Hi,
My customer uses PostgreSQL on Windows and hits the problem that following log
is written to the server logs too frequently (250 thousand times per day).
"LOG: could not reserve shared memory region (addr=%p) for child %p:"
This log is written when pgwin32_ReserveSharedMemoryRegion() in wi
