Fatel: unsupported frientend protocol error
Hi sir, I am getting below error for the past 3 month's plz can suggest how to resolve this issue. PostgreSQL 9.6 version and Linux redhat 7.2 efm 4.1 plz Fatel: unsupported frientend protocol 1234.5680: server supports 1.0 to 3.0 This error continuesly getting in log file Thanks & Regards Eswara Reddy
Re: Fatel: unsupported frientend protocol error
On Thu, 2022-06-30 at 16:40 +0530, eswar reddy wrote: > Hi sir, I am getting below error for the past 3 month's plz can suggest how > to resolve this issue. > > PostgreSQL 9.6 version and Linux redhat 7.2 efm 4.1 plz > > Fatel: unsupported frientend protocol 1234.5680: server supports 1.0 to 3.0 > > This error continuesly getting in log file This is simple: upgrade the server to a supported version, ideally v14. Yours, Laurenz Albe
Re: Fatel: unsupported frientend protocol error
On Thursday, June 30, 2022, Laurenz Albe wrote: > On Thu, 2022-06-30 at 16:40 +0530, eswar reddy wrote: > > Hi sir, I am getting below error for the past 3 month's plz can suggest > how to resolve this issue. > > > > PostgreSQL 9.6 version and Linux redhat 7.2 efm 4.1 plz > > > > Fatel: unsupported frientend protocol 1234.5680: server supports 1.0 to > 3.0 > > > > This error continuesly getting in log file > > This is simple: upgrade the server to a supported version, ideally v14. > Good advice regardless, but wouldn’t v14 still give that same error if some client tried to present protocol version 1234.5680 as the desired communicarion protocol? David J.
pg_amcheck warnings after upgrade to 14.4
Hello,
we have suffered from BUG #17485, so we have upgraded our databases to 14.4.
When (on 14.3 we discovered the issue all affected indexes were rebuilt
[not concurrently]), so subsequent pg_amcheck --heapallindexed was without
errors or warnings.
After the upgrade to 14.4, we run pg_amcheck --heapallindexed again to
ensure all indexes are in a good shape, and on some databases, pg_amcheck
yields some messages (supposed to be wanings since pg_amcheck exit code was
zero).
On some tables, running vacuum freeze resolved all of the warning messages,
but we have at least one table where vacuum freeze (have no chance to run
vacuum full to completely rewrite the table) did not resolve the warnings.
Table vacuum:
live=# VACUUM (DISABLE_PAGE_SKIPPING, VERBOSE)
live.live_opportunities.tab_odds_history;
INFO: aggressively vacuuming "live_opportunities.tab_odds_history"
INFO: table "tab_odds_history": index scan bypassed: 50245 pages from
table (0.20% of total) have 3361027 dead item identifiers
INFO: launched 1 parallel vacuum worker for index cleanup (planned: 1)
INFO: table "tab_odds_history": found 0 removable, 583340008 nonremovable
row versions in 25325175 out of 25325175 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 4076779300
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 81.77 s, system: 122.32 s, elapsed: 243.07 s.
INFO: aggressively vacuuming "pg_toast.pg_toast_18089"
INFO: table "pg_toast_18089": found 0 removable, 0 nonremovable row
versions in 0 out of 0 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 4076806500
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
pg_amcheck warnings:
$ /usr/pgsql-14/bin/pg_amcheck --heapallindexed -t
live.live_opportunities.tab_odds_history -P |& tee -a
20220630_amcheck.03.log
0/5 relations (0%),0/2770 pages (0%)
heap table "live.live_opportunities.tab_odds_history", block 2955073,
offset 48:
xmin 4075979939 precedes relation freeze threshold 1:4075978425
...
heap table "live.live_opportunities.tab_odds_history", block 2955076,
offset 27:
xmin 4075980540 precedes relation freeze threshold 1:4075978425
Checked the XIDs:
live=# select relfrozenxid, relminmxid from pg_class where oid =
'live_opportunities.tab_odds_history'::regclass::oid;
relfrozenxid | relminmxid
--+
4075978425 | 1144161405
(1 row)
live=# select now(), pg_xact_commit_timestamp('4075978425'::xid) AS
relfrozenxid_time, pg_xact_commit_timestamp('4075979939'::xid) as
block_2955073_xmin;
now | relfrozenxid_time |
block_2955073_xmin
---+---+---
2022-06-30 11:57:42.800162+02 | 2022-06-30 11:33:00.729004+02 | 2022-06-30
11:33:57.208792+02
(1 row)
live=# select now(), pg_xact_commit_timestamp('4075978425'::xid) AS
relfrozenxid_time, pg_xact_commit_timestamp('4075980540'::xid) as
block_2955076_xmin;
now | relfrozenxid_time |
block_2955076_xmin
--+---+---
2022-06-30 11:53:39.05382+02 | 2022-06-30 11:33:00.729004+02 | 2022-06-30
11:34:28.281048+02
(1 row)
The table relfrozenxid is less than the tuple xmin reported by pg_amcheck,
that makes me confused by the pg_amcheck messages - so probably I did not
understand the warning message properly.
What is the meaning of the warning (if they are really only warnings)
message?
The key question is - are these pg_amcheck messages listed above a reason
to take an remedy action (if yes, what is the suggested action?) or they
can be safely ignored?
Thanks Ales Zeleny
Re: Fatel: unsupported frientend protocol error
"David G. Johnston" writes: > On Thursday, June 30, 2022, Laurenz Albe wrote: >> On Thu, 2022-06-30 at 16:40 +0530, eswar reddy wrote: >>> Fatel: unsupported frientend protocol 1234.5680: server supports 1.0 to >>> 3.0 >> This is simple: upgrade the server to a supported version, ideally v14. > Good advice regardless, but wouldn’t v14 still give that same error if some > client tried to present protocol version 1234.5680 as the desired > communicarion protocol? Per src/include/libpq/pqcomm.h, that code is #define NEGOTIATE_GSS_CODE PG_PROTOCOL(1234,5680) So some client is running code new enough to try GSS protocol, but the 9.6 server doesn't know what that is. You'd need v12 or later server if you don't want to see these complaints. (But you could just ignore them.) regards, tom lane
Re: Function inside query status
On 6/29/22 23:57, Rama Krishnan wrote: Hi All, Is it possible to check the query execution status inside the function. created or replace function data_purge() returns void as$$ Declare Begin Drop table test_old; Create table test_old as select * from sales where bill_date-interval '1 year'; Delete table sales where sales_id in (select sales_id from test_old; 1) You are not actually declaring anything so the Declare is not needed. 2) You have three queries in the function do you want to check them all or some subset? 3) What exactly are checking for? 4) Have you looked at?: https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS and https://www.postgresql.org/docs/current/plpgsql-control-structures.html#PLPGSQL-EXCEPTION-DIAGNOSTICS End; $$ language plpgsql; -- Adrian Klaver adrian.kla...@aklaver.com
Re: User's responsibility when using a chain of "immutable" functions?
> david.g.johns...@gmail.com wrote:
>
> b...@yugabyte.com wrote:
>>
>> Meanwhile. I'll appeal for some pointers to what I should read...
>
> I tend not to search...or at least that isn't my first (or at least only)
> recourse. The pg/pgsql chapter has a subchapter named "Plan Caching":
>
> https://www.postgresql.org/docs/current/plpgsql-implementation.html#PLPGSQL-PLAN-CACHING
>
> You really need to read the "see related" reference there to get the level of
> detail that you want:
>
> https://www.postgresql.org/docs/current/xfunc-volatility.html
>
> "This category allows the optimizer to pre-evaluate the function when a query
> calls it with constant arguments."
>
> The implication is that this operation is not session-scoped but
> query-scoped. Other parts of the page reinforce this. Not saying it is
> perfect wording but I came by my understanding pretty much exclusively from
> this documentation.
Thank you very much for the doc pointers, David. I believe that I have all I
need, now. I understood already that "giving permission to cache" doesn't mean
that PG will actually cache anything. I wanted only to find a compelling
example of how lying when you mark a function "immutable" can bring wring
results. I think that this is sufficient:
set x.a = '13';
create function dishonestly_marked_immutable(i in int)
returns int
immutable
language plpgsql
as $body$
begin
return i*(current_setting('x.a')::int);
end;
$body$;
prepare q as
select
dishonestly_marked_immutable(2) as "With actual '2'",
dishonestly_marked_immutable(3) as "With actual '3'";
execute q;
set x.a = '19';
execute q; --<< Produces the stale "26 | 39".
discard plans;
execute q; --<< Now produces the correct "38 | 57"
