John Naylor writes:
> If no one else has anything, I think this is ready for commit.
Pushed, after adopting the suggestion to dispense with
isSharedObjectPinned.
regards, tom lane
On Wed, Jul 14, 2021 at 3:34 PM Tom Lane wrote:
> Hm, I'm not following? setup_depend runs in initdb, that is on the
> client side. It can't invoke backend-internal functions any other
> way than via SQL, AFAICS.
Ah, brainfade on my part.
I was also curious about the test case where Andres fi
John Naylor writes:
> On Thu, May 27, 2021 at 6:53 PM Tom Lane wrote:
>> Attached is a rebase over a4390abec.
> Looks good to me overall, I just had a couple questions/comments:
Thanks for looking!
> isObjectPinned and isSharedObjectPinned are now thin wrappers around
> IsPinnedObject. Is keep
On Thu, May 27, 2021 at 6:53 PM Tom Lane wrote:
> Attached is a rebase over a4390abec.
Looks good to me overall, I just had a couple questions/comments:
isObjectPinned and isSharedObjectPinned are now thin wrappers around
IsPinnedObject. Is keeping those functions a matter of future-proofing in
I wrote:
> Robert Haas writes:
>> The first hunk of the patch seems to back away from the idea that the
>> cutoff is 13000, but the second half of the patch says 13000 still
>> matters. Not sure I understand what's going on there exactly.
> Not sure exactly what you're looking at, but IIRC there
Robert Haas writes:
> So I think your proposal of allowing genbki-assigned OIDs to be reused
> in different catalogs is probably a pretty good one, but I wonder if
> we could just rejigger things so that collations just get normal OIDs
> > 16384.
Hm. I can't readily think of a non-hack way of ma
On Wed, May 26, 2021 at 11:37 AM Tom Lane wrote:
> In any case it doesn't seem like the issue is entirely pressing
> yet. Although ... maybe we should do that last bit now, so
> that we can revert FirstBootstrapObjectId to 12K before v14
> ships? I've felt a little bit of worry that that change
Robert Haas writes:
> The first hunk of the patch seems to back away from the idea that the
> cutoff is 13000, but the second half of the patch says 13000 still
> matters. Not sure I understand what's going on there exactly.
Not sure exactly what you're looking at, but IIRC there is a place
where
On Wed, May 12, 2021 at 6:21 PM Tom Lane wrote:
> Here's a v2 that does things that way (and is rebased up to HEAD).
> I did some more documentation cleanup, too.
The first hunk of the patch seems to back away from the idea that the
cutoff is 13000, but the second half of the patch says 13000 sti
I wrote:
> In view of the discussion at [1], there's more pressure on the OID supply
> above 10K than I'd realized. While I don't have any good ideas about
> eliminating the problem altogether, I did have a thought that would remove
> the extra buffer zone created by my first-draft patch in this t
Andres Freund writes:
> On 2021-04-15 19:59:24 -0400, Tom Lane wrote:
>> No, *neither* of them are pinned, and we don't want them to be.
>> It's something of a historical artifact that template1 has a low OID.
> Hm, it makes sense for template1 not to be pinned, but it doesn't seem
> as obvious w
Hi,
On 2021-04-15 19:59:24 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Hm, maybe we ought to swap template0 and template1 instead? I.e. have
> > template0 be in pg_database.dat and thus get a pinned oid, and then
> > create template1, postgres etc from that?
>
> No, *neither* of them are
Andres Freund writes:
> Hm, maybe we ought to swap template0 and template1 instead? I.e. have
> template0 be in pg_database.dat and thus get a pinned oid, and then
> create template1, postgres etc from that?
No, *neither* of them are pinned, and we don't want them to be.
It's something of a histo
Hi,
On 2021-04-14 21:43:28 -0400, Tom Lane wrote:
> In [1] Andres and I speculated about whether we really need all
> those PIN entries in pg_depend. Here is a draft patch that gets
> rid of them.
Yay.
> There are a couple of objects, namely template1 and the public
> schema, that are in the ca
[ connecting up two threads here ]
I wrote:
> Hence, what this patch does is to establish a manually-managed cutoff
> point akin to FirstBootstrapObjectId, and make initdb push the OID
> counter up to that once it's made the small number of pinned objects
> it's responsible for. With the value I
In [1] Andres and I speculated about whether we really need all
those PIN entries in pg_depend. Here is a draft patch that gets
rid of them.
It turns out to be no big problem to replace the PIN entries
with an OID range check, because there's a well-defined point
in initdb where it wants to pin (
16 matches
Mail list logo
