public inbox for [email protected]
help / color / mirror / Atom feedRe: confused about material view locks please explain
2+ messages / 2 participants
[nested] [flat]
* Re: confused about material view locks please explain
@ 2024-07-06 05:39 Krishnakant Mane <[email protected]>
2024-07-06 11:49 ` Re: confused about material view locks please explain Peter J. Holzer <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Krishnakant Mane @ 2024-07-06 05:39 UTC (permalink / raw)
To: [email protected]
On 7/5/24 21:10, Peter J. Holzer wrote:
> If I understand https://github.com/sraoss/pg_ivm correctly, the
> materialized view will be updated within the same transaction. So it's
> just the same as any other change in the database:
>
> Neither client will wait for the other. The first client will see either
> the old or the new state depending on whether the second client manages
> to commit soon enough.
Thank you Peter.
So does that mean both the processes work concurrently?
I had understood that while an update is happening to an IVM (material
view ) the view is locked till the update is complete.
If so then how would both the clients have simultaneous access?
Regards.
>
>
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: confused about material view locks please explain
2024-07-06 05:39 Re: confused about material view locks please explain Krishnakant Mane <[email protected]>
@ 2024-07-06 11:49 ` Peter J. Holzer <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Peter J. Holzer @ 2024-07-06 11:49 UTC (permalink / raw)
To: [email protected]
On 2024-07-06 11:09:23 +0530, Krishnakant Mane wrote:
>
> On 7/5/24 21:10, Peter J. Holzer wrote:
> > If I understand https://github.com/sraoss/pg_ivm correctly, the
> > materialized view will be updated within the same transaction. So it's
> > just the same as any other change in the database:
> >
> > Neither client will wait for the other. The first client will see either
> > the old or the new state depending on whether the second client manages
> > to commit soon enough.
>
> Thank you Peter.
>
> So does that mean both the processes work concurrently?
I think so, yes. (But I've only read the README. I don't use pg_ivm
myself).
> I had understood that while an update is happening to an IVM
> (material view) the view is locked till the update is complete.
According to the README[1], an ExclusiveLock is used. The manual[2]
says:
| EXCLUSIVE (ExclusiveLock)
|
| Conflicts with the ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE
| EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS
| EXCLUSIVE lock modes. This mode allows only concurrent ACCESS
| SHARE locks, i.e., only reads from the table can proceed in
| parallel with a transaction holding this lock mode.
So I think a parallel SELECT would still be possible.
hp
[1] https://github.com/sraoss/pg_ivm?tab=readme-ov-file#concurrent-transactions
[2] https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-TABLES
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-07-06 11:49 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-07-06 05:39 Re: confused about material view locks please explain Krishnakant Mane <[email protected]>
2024-07-06 11:49 ` Peter J. Holzer <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox