Re: ERROR: no known snapshots
On 12.05.2021 05:42, Tom Lane wrote: If you're in a position to apply the patch and see if it resolves your real non-simplified case, that would be very helpful. Also, this fix in principle will create a small performance penalty for FOR-loops in non-atomic contexts such as DO loops. It'd be interesting to know if the penalty is noticeable in your usage. Provided I understood your comment in the code, the slight performance impact should be due to the disabled prefetching. That should not be an issue, but I have not yet tested this. What I have tested, I applied the patch to master and tested the actual code against the new build on a small testserver. This works for me. However, I poked around a little bit, and this does not seem to solve all potential use cases, when I modify the simplified test by deferring the lookup to be done inside the loop as an extra lookup instead of doing it directly in the loop (whether that makes sense is another question) , then this still produces the error: \echo test1 DO $$ DECLARE r record; t text; BEGIN FOR r in (SELECT i FROM test1) LOOP select txt into t from test1 where i=r.i; COMMIT; END LOOP; END; $$; \echo test2 DO $$ DECLARE r record; t text; BEGIN FOR r in (SELECT i FROM test2) LOOP select txt into t from test2 where i=r.i; COMMIT; END LOOP; END; $$; test1 DO test2 psql:snapshot_error.sql:38: ERROR: no known snapshots CONTEXT: PL/pgSQL function inline_code_block line 6 at FOR over SELECT rows
Re: ERROR: no known snapshots
reg_pg_stef...@perfexpert.ch writes: > However, I poked around a little bit, and this does not seem to solve > all potential use cases, when I modify the simplified test by deferring > the lookup to be done inside the loop as an extra lookup instead of > doing it directly in the loop (whether that makes sense is another > question) , then this still produces the error: Ugh. Thanks for the test case! regards, tom lane
Re: [RPM/CentOS7] Need to disable repo_gpgcheck on pgdg-common when using RPM version 42.0-17.1
Hi, I also see a similar error while performing "yum install postgresql10-devel" yum-dump Repository Error: failure: repodata/repomd.xml from pgdg-common: [Errno 256] No more mirrors to try. https://download.postgresql.org/pub/repos/yum/common/redhat/rhel-7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for pgdg-common I have not made any changes to /etc/yum.repos.d/pgdg-redhat-all.repo Regards, Dhanisha Phadate -- Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
Postgresql fdw tracing
Hello Gentlemen, I am trying to setup a shard array of pg clusters behind fdw which is fronted by haproxy/envoyproxy to load balance. Something like this, but including pgbouncer. https://image.slidesharecdn.com/fdw-basedsharding-170321103514/95/fdwbased-sharding-update-and-future-12-638.jpg?cb=1490092596 Everything works perfectly well, but monitoring is becoming difficult for remote queries. If there are 100s of queries all querying multiple shards behind, it is very difficult to trace server from where the query originated from the backend shards. If you have understood till here, Has anyone worked with passing a unique request id (like in http requests via header ) that lives across the queries via fdw etc so that we can identify and trace the query. Even if it is via a sidecar. If we remove the fdw context, This works on local queries as pg_stat_activity shows parent pid if parallel workers spawned. If any one has used pgbouncer, even pgbouncer maps the front-end to backend queries to trace the client ip to the backend request. I hope i am clear, but I can elaborate more if required. I am trying to simulate a poor man's citus sharding :)
