I am experiencing major performance issues when calling a stored procedure via PostgREST compared when calling it via psql. Both methods complete successfully, but the PostgREST takes ~1 min compared to 2 seconds with psql. There are many statement levels and a few row-level triggers fired as a result of this procedure.
This procedure updates the database, another update procedure has the same issues,
Calling from psql:
set role myrole;
start transaction;
WITH pgrst_source AS (WITH pgrst_args AS (SELECT NULL) SELECT "api"."docket_creation"('{"dockets":[{"docket":{},"transactions":[{"transaction":{"batch_id":null,"best_before_date":null,"docket_id":1417,"minimum_price":1.5,"note":"","price":3,"product_code":"TL12","product_cost":1,"product_description":"","product_group_id":null,"product_id":217,"product_name":"12 Tray Large","quantity":1,"vat_rate_id":4,"vat_rate_percentage":0,"return_reason_id":null,"transaction_type_id":2},"transaction_discounts":[{"discount_percentage":5,"discount_type_id":10,"discount_value_per_unit":null,"minimum_quantity":null,"note":""}],"transaction_returns":[],"transaction_commissions":[{"commission_id":null,"commission_percentage":0,"commission_type_id":2,"customer_id":1,"delivery_agent_id":0,"effective_from":null,"effective_to":null,"is_cumulative":true,"owner":2,"product_id":217}]}],"docket_buy_x_get_y_discounts":[]}]}'::json) AS pgrst_scalar)
SELECT
null::bigint AS total_result_set,
pg_catalog.count(_postgrest_t) AS page_total,
(json_agg(_postgrest_t.pgrst_scalar)->0)::character varying AS body,
coalesce(nullif(current_setting('response.headers', true), ''), '[]') AS response_headers
FROM (SELECT "pgrst_source".* FROM "pgrst_source" ) _postgrest_t;
Or simply:
SELECT "api"."docket_creation"('{"dockets":[{"docket":{},"transactions":[{"transaction":{"batch_id":null,"best_before_date":null,"docket_id":1417,"minimum_price":1.5,"note":"","price":3,"product_code":"TL12","product_cost":1,"product_description":"","product_group_id":null,"product_id":217,"product_name":"12 Tray Large","quantity":1,"vat_rate_id":4,"vat_rate_percentage":0,"return_reason_id":null,"transaction_type_id":2},"transaction_discounts":[{"discount_percentage":5,"discount_type_id":10,"discount_value_per_unit":null,"minimum_quantity":null,"note":""}],"transaction_returns":[],"transaction_commissions":[{"commission_id":null,"commission_percentage":0,"commission_type_id":2,"customer_id":1,"delivery_agent_id":0,"effective_from":null,"effective_to":null,"is_cumulative":true,"owner":2,"product_id":217}]}],"docket_buy_x_get_y_discounts":[]}]}')
This takes about 2 secs.
When calling from a webapp or via curl with the call
curl 'https://<server>/hhdb_api/rpc/docket_creation' \
-X 'POST' \
-H 'Connection: keep-alive' \
-H 'sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"' \
-H 'Prefer: params=single-object' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'Authorization: Bearer $bearer_token' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/plain, */*' \
-H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36' \
-H 'DNT: 1' \
-H 'Origin: https://hh-tincan-dev.srv.handheld.ie' \
-H 'Sec-Fetch-Site: same-site' \
-H 'Sec-Fetch-Mode: cors' \
-H 'Sec-Fetch-Dest: empty' \
-H 'Referer: https://hh-tincan-dev.srv.handheld.ie/' \
-H 'Accept-Language: en-GB,en-US;q=0.9,en;q=0.8' \
--data-raw '{"dockets":[{"docket":{},"transactions":[{"transaction":{"batch_id":null,"best_before_date":null,"docket_id":1428,"minimum_price":1.5,"note":"","price":3,"product_code":"TL12","product_cost":1,"product_description":"","product_group_id":null,"product_id":217,"product_name":"12 Tray Large","quantity":1,"vat_rate_id":4,"vat_rate_percentage":0,"return_reason_id":null,"transaction_type_id":2},"transaction_discounts":[{"discount_percentage":5,"discount_type_id":10,"discount_value_per_unit":null,"minimum_quantity":null,"note":""}],"transaction_returns":[],"transaction_commissions":[{"commission_id":null,"commission_percentage":0,"commission_type_id":2,"customer_id":1,"delivery_agent_id":0,"effective_from":null,"effective_to":null,"is_cumulative":true,"owner":2,"product_id":217}]}],"docket_buy_x_get_y_discounts":[]}]}' \
--compressed
This will take over a minute.
I would expect both of these invocations to take a similar time.
I have enabled extensive logging to try to track this down the difference between the two methods seems to be the delays when entering a nested trigger
~
I have raised this as an issue on the PostgREST's GitHub with some configuration details:
https://github.com/PostgREST/postgrest/issues/1836
This issue is now solved please refer to the PostgREST github issue for details
I am unable to successfully acquire an id token/access token from my AWS cognito user pool when I supply an auth code. I have written a shell script (see below), and receive invalid_grant back from the server.
I have encoded the base64 Authorization Basic header for client_id:client_secret generated with python as:
import base64
encode='my_client_id_string:my_client_secret_string'
base64.b64encode(encode)
#!/usr/bin/env sh
curl --location --request POST 'https://<domain>.auth.us-east-2.amazoncognito.com/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic <base64 encode string client_id:client_secret>' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'client_id=<client_id from app settings' \
--data-urlencode 'code=<code received from redirect url to my localhost app endpoint>' \
--data-urlencode 'redirect_uri=http://localhost:8000/my_redirect'
Any ideas?
Solved it!
The problem was caused by an invalid client id. I had supplied a typo for the client id value!
I am using CALDAV:calendar-multiget REPORT for expanded retrieval of recurring event.
The request looks like:
curl -X REPORT \
https://caldav.icloud.com:443/1234567890/calendars/work/ \
-H 'authorization: Basic XXXXXX' \
-H 'content-type: application/xml; charset=utf-8' \
-d '<c:calendar-multiget xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav">
<d:prop>
<c:calendar-data>
<c:expand start="20171201T000000Z" end="20180101T000000Z"/>
</c:calendar-data>
</d:prop>
<d:href>/1234567890/calendars/work/ABC-DEF-GHI-JKL.ics</d:href>
</c:calendar-multiget>'
Sometimes the Apple server gives expanded events in the response but sometimes it gives only the master event without expansion.
Am I doing anything wrong here?
Has anyone else faced this behaviour?
I got
error: {"error":"Unexpected token ‘"}
with the curl command below.
What gives?
curl -X POST \
-H "X-Parse-Application-Id:SomeID" \
-H "Content-Type: application/json" \
-d ‘{“number”:"3016524500"}’ \
http://somedomain.com/parse/functions/testFunction
Please suggest.
I think the issue is that you're using different characters than the actual ' and " characters. Try replacing ” with " and ‘ with '.
I have a curl command that was given to me that I have to convert using requests.
curl --request POST "https://www.example.com" --data "user_id=200" --data "user_data=je93jfe92dj220,39fjid20djd93f302,93jfieheio02hfne,902jfoienfieshiu202" --header "Authorization: Bearer [TOKEN]"
using requests, the call should be
hdr = {'Content-Type': 'Content-type: application/json',
'Authorization': 'Bearer TOKEN' }
payload = {"user_id":200,"records":"je93jfe92dj220,39fjid20djd93f302,93jfieheio02hfne,902jfoienfieshiu202"
requests.post('https://www.example.com', headers=hdr, data=json.dumps(payload))
This isn't working as I'm getting an error returned that the 'user_id' param must be an integer. Not sure how to ensure that, as aren't all parameters formatted as strings when sent? The curl command does work, however.
Im not really sure the reason, but to make this work, just change data=json.dumps(payload) to json=json.dumps(payload). This worked just fine for me.