Re: Create/alter policy and exclusive table lock

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-hackers by date

  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