| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Create/alter policy and exclusive table lock |
| Date: | 2020-01-14 17:40:56 |
| Message-ID: | 11913.1579023656@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> writes:
> But let me ask you one more question: why do we obtaining snapshot twice
> in exec_simple_query:
> first for analyze (pg_analyze_and_rewrite) and one for execution
> (PortalStart)?
That would happen anyway if the plan is cached. If we were to throw away
all plan caching and swear a mighty oath that we'll never put it back,
maybe we could build in a design assumption that planning and execution
use identical snapshots. I doubt that would lead to a net win though.
Also note that our whole approach to cache invalidation is based on the
assumption that if session A needs to see the effects of session B,
they will be taking conflicting locks. Otherwise sinval signaling
is not guaranteed to be detected at the necessary times.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-01-14 17:53:04 | Re: backup manifests |
| Previous Message | David Fetter | 2020-01-14 17:35:53 | Use compiler intrinsics for bit ops in hash |