On 2/26/20 11:37 AM, Albrecht Dreß wrote:
Sorry for the late reply, I've been on a short vacation…
Am 21.02.20 21:44 schrieb(en) Adrian Klaver:
1) From your original post what does the below mean?:
-- add several db functions
One trigger function, plus two “normal” ones, all (yet) unused.
Sorry for the late reply, I've been on a short vacation…
Am 21.02.20 21:44 schrieb(en) Adrian Klaver:
1) From your original post what does the below mean?:
-- add several db functions
One trigger function, plus two “normal” ones, all (yet) unused.
-- replace a DB function:
This was the
-
On 2/21/20 9:55 AM, Albrecht Dreß wrote:
Am 20.02.20 21:41 schrieb(en) Adrian Klaver:
It would be nice to know what:
[snip]
represented in:
Dropping and re-creating the function is actually the last operation in
the script. The function is /very/ simple (just a wrapper to hide all
interna
Am 20.02.20 21:41 schrieb(en) Adrian Klaver:
It would be nice to know what:
[snip]
represented in:
Dropping and re-creating the function is actually the last operation in the script. The
function is /very/ simple (just a wrapper to hide all internals from "agent"
clients):
---8<--
On 2/20/20 11:28 AM, Albrecht Dreß wrote:
Am 20.02.20 19:32 schrieb(en) Tom Lane:
This is, actually, not very surprising. You dropped the old function
while clients were using it. The new function is a completely
unrelated object, even if it happens to have the same name.
Yes, I agree that
Albrecht =?iso-8859-1?b?RHJl3w==?= writes:
> OK, but after fully stopping the daemon via systemctl (which of course
> disconnects all clients) and re-starting it, the cache is empty, isn't it?
> So the client after re-connecting /should/ find the proper function? In my
> case the full restart
Am 20.02.20 19:32 schrieb(en) Tom Lane:
This is, actually, not very surprising. You dropped the old function while
clients were using it. The new function is a completely unrelated object, even
if it happens to have the same name.
Yes, I agree that this was not a too clever approach…
It d
Given the explicit begin before drop/create, this is a bit of an unexpected
gotcha to have any impact on other transactions. Are there other known
limitations of DDL in a transaction?
I wrote:
> It does seem a bit annoying that something in plpgsql is apparently
> doing a fresh catalog lookup to find information that likely was
> already cached at the start of function execution. But I think that's
> a performance deficiency, not a bug per se.
I reproduced this issue locally (
Albrecht =?iso-8859-1?b?RHJl3w==?= writes:
> I tried to update the running server by executing the following SQL update
> script using psql:
> ---8<---
> BEGIN;
> -- add a column to an existing table
> -- add a new table
> -- add several db functions
>
Hey Tom,
Had a small query here.
If we have streaming replication enabled, and if we have corruption like this
due to power loss etc,
is it safe to assume we failover to standby and we should be good (atleast in
most cases)
I wanted to understand if the system catalog is corrupted, for some re
>This suggests you've actually lost some entries from pg_proc. Have
>you had any system crashes or suchlike?
yes two crashes for power outages, this guys doesn't have dumps recent, only
to 2 days ago, I try recover the much data as possible.
>No, pg_upgrade can't magically restore data that's n
DrakoRod writes:
> I reindex the pg_proc table and reindex finished correctly but I try read
> the tables or make the dump and same error, reindexed the database and show
> me this error:
> ERROR: cache lookup failed for function 125999
This suggests you've actually lost some entries from pg_p
Hi Tom
I reindex the pg_proc table and reindex finished correctly but I try read
the tables or make the dump and same error, reindexed the database and show
me this error:
ERROR: cache lookup failed for function 125999
Any suggestions, If I run pg_upgrade to 10, will these errors be corrected?
DrakoRod writes:
> I've a big problem with a database, is a PostgreSQL 9.6 version on Ubuntu.
> When a tried read some tables (approximately 7 of 1073) show this error:
> *ERROR: cache lookup failed for function 125940*
> So, I was reading this like data corruption specially the postgresql's
>
15 matches
Mail list logo
