Hasura fails because max_function_args in postgres is no enough

[ammirator-administrator]

Version Information

Server Version:
2.36.1

Environment

OSS

What is the current behaviour?

Hasura fails to retrieve data from a Table (From Citus), and that happens because it seems that max_function_args in PG is not enough for that, the table indeed has let's say 50columns, but I do not understand why hasura creates a Method with more than max_function_args and try to retrieve data after that
That may be due to json modules used in hasura or something like that
And to fix that you just hae to recompile PF to give a bigger max_function_args and that is not possible in most cases since no one wants to recompile PG) this value cantbe added to PG cofig it is a readonly value and postgres doesnt allow that

SO it seems that tables with more that 50columns are not supported in hasura at the mooment

This is the errror

statusCode: 54023
cannot pass more than 100 arguments to a function

[ammirator-administrator]

Any help?? Citus is not usable with hasura because of this error
Can we do something about this?
It seems that just compiling Postgres may help, but that is not a option and no one is compiling his own version of postgres

[ammirator-administrator]

Is there a way to configure hasura to use not json_(..,..,..,,) witha lot of arguments but use maybe json_array not json_object which causes this problem

[ammirator-administrator]

More context about the issue I also fount heer https://postgrespro.com/list/thread-id/2486891
Basically the same issue

[ammirator-administrator]

If i use in my databases.yaml
this

kind: postgres
instead of

kind: citus
Then everything works, but I just simply do not know if that is ok and what I lose by doing so

[happyhunter7]

+1 This is supper needed and is a limitation from Hasura

Big companies do not use just postgres since it doesn't make sense in big apps but with some extension like Citus
And if the Hasura Citus adapter implementation has these limitations it is sad for big companies which may try to us eHasura

[SamirTalwar]

Can you explain how you trigger this issue? Is it a problem when loading metadata, making a query, using the Console, or something else?

There aren't that many differences between the vanilla PostgreSQL and Citus backends, so I am surprised that switching the "kind" would help, but that does narrow it down a lot.

I would also recommend checking out Hasura DDN, which fixes many of the issues in Hasura GraphQL Engine v2. Most notably in this case, the custom Citus support is strictly limited to introspection, and during queries, both PostgreSQL and Citus are treated identically.

[happyhunter7]

This is a problem when running a simple get query for example to get a row from such a table
If the table has more than 50+ columns the query fails
And yes the citus get query is different that the one used in postgres, in postgres it uses row_to_json and in citus it uses json_build_object methods
An this json_build_object cant take more than 100args this is the postgres limitation, and even if the table has only 50 columns this limitations is still reached since hasura adds there 50+ columns starting with some prefix "root...."
The implementations are different

cc @SamirTalwar

[SamirTalwar]

I saw @ammirator-administrator's comments in #10229 pointing to a code location. That code is specific to subscriptions, not queries, and is not specific to Citus; it is the same code for all backends based on PostgreSQL.

Is it possible that in testing, you made a subscription to Citus, but a query to vanilla PostgreSQL? That would explain the discrepancy.

[ammirator-administrator]

Hey @SamirTalwar
I just gave a example
But the queries in citus also uses json_to_object and the problems are guess in both queries and subscription
Since I do not know any haskel code I just sent a example of where it is used and where also it may be a problem

The problem I have is in Queries, just by runing a graphql query for example get app_config_by_pk (Which is a table with more than 50columns it returns teh error)
This doesn't happen on other tables at all since these have less than 50 columns