From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Hubert Zhang <hzhang(at)pivotal(dot)io>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Is there way to detect uncommitted 'new table' in pg_class? |
Date: | 2018-11-01 00:38:35 |
Message-ID: | 20181101003835.GC1727@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 31, 2018 at 01:30:52PM -0400, Robert Haas wrote:
> In theory, at least, you could write C code to scan the catalog tables
> with SnapshotDirty to find the catalog entries, but I don't think that
> helps a whole lot. You couldn't necessarily rely on those catalog
> entries to be in a consistent state, and even if they were, they might
> depend on committed types or functions or similar whose definitions
> your backend can't see. Moreover, the creating backend will have an
> AccessExclusiveLock on the table -- if you write C code to bypass that
> and read the data anyway, then you will probably destabilize the
> entire system for complicated reasons that I don't feel like
> explaining right now.
One take here is that we cannot give any guarantee that a single DDL
will create only one consistent version of the tuple added in system
catalogs. In those cases a new version is made visible by using
CommandCounterIncrement() so as the follow-up processing can see it.
> You should try very hard to find some way of solving this problem that
> doesn't require reading data from a table that hasn't been committed
> yet, because you are almost certainly not going to be able to make
> that work reliably even if you are willing to write code in C.
+1.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2018-11-01 00:41:55 | Re: COPY FROM WHEN condition |
Previous Message | Amit Langote | 2018-11-01 00:35:30 | Re: Speeding up INSERTs and UPDATEs to partitioned tables |