On 2019-02-18 12:45:10 +0900, Michael Paquier wrote:
> On Sat, Feb 16, 2019 at 04:50:51PM +0100, John Naylor wrote:
> > I just noticed a small typo in transam.h. Patch attached.
>
> Thanks, fixed.
Thx.
On Sat, Feb 16, 2019 at 04:50:51PM +0100, John Naylor wrote:
> I just noticed a small typo in transam.h. Patch attached.
Thanks, fixed.
--
Michael
signature.asc
Description: PGP signature
On 12/15/18, Andres Freund wrote:
>> > [ separation of FirstBootstrapObjectId and FirstGenbkiObjectId ]
I just noticed a small typo in transam.h. Patch attached.
-John Naylor
diff --git a/src/include/access/transam.h b/src/include/access/transam.h
index 4a7eab00d8..444be4aeb5 100644
--- a/src/in
Hi,
On 2018-12-14 22:54:14 -0300, Alvaro Herrera wrote:
> On 2018-Dec-13, Tom Lane wrote:
> > Looking at the existing entries, it seems like we'd have to have
> > one special case: schema public has OID 2200 but is intentionally
> > not pinned. I wouldn't have a hard time with teaching isObjectPi
On 2018-Dec-13, Tom Lane wrote:
> We could take it a bit further and not make the 'p' entries for such
> OIDs in the first place, greatly reducing the size of pg_depend in
> typical installations. Perhaps that'd confuse clients that look at
> that catalog, though.
The number of 'p' entries in pg
Hi,
On 2018-12-13 20:21:12 -0500, Tom Lane wrote:
> Andres Freund writes:
> > [ separation of FirstBootstrapObjectId and FirstGenbkiObjectId ]
>
> It seems like we should also add a check to genbki.pl that the ending
> value of GenbkiNextOid is <= FirstBootstrapObjectId, so that we'll
> certainl
> On 12/13/18, Tom Lane wrote:
> Looking at the existing entries, it seems like we'd have to have
> one special case: schema public has OID 2200 but is intentionally
> not pinned.
setup_depend() mentions other exceptions, but only this one currently has any
effect as far as I can see:
"pg_da
Andres Freund writes:
> [ separation of FirstBootstrapObjectId and FirstGenbkiObjectId ]
It seems like we should also add a check to genbki.pl that the ending
value of GenbkiNextOid is <= FirstBootstrapObjectId, so that we'll
certainly notice when it's necessary to adjust those boundaries.
(Ther
On 2018-12-11 15:08:02 -0800, Andres Freund wrote:
> Hi,
>
> On 2018-12-09 18:43:14 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
> > >> Well, that's just a different very-easily-broken assumption. There are
> > >> a lot of things that make
Hi,
On 2018-12-11 19:33:23 -0500, John Naylor wrote:
> On 12/11/18, Andres Freund wrote:
> > I've attached a patch implementing that. I'm not particularly in love
> > with FirstGenbkiObjectId as the symbol, but I couldn't think of
> > something more descriptive.
>
> How about FirstAutoAssignedO
On 12/11/18, Andres Freund wrote:
> I've attached a patch implementing that. I'm not particularly in love
> with FirstGenbkiObjectId as the symbol, but I couldn't think of
> something more descriptive.
How about FirstAutoAssignedObjectId?
-John Naylor
Hi,
On 2018-12-09 18:43:14 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
> >> Well, that's just a different very-easily-broken assumption. There are
> >> a lot of things that make auto-assigned OIDs unstable, and I do not think
> >> that we want
On 12/9/18, Tom Lane wrote:
> Another thing I seriously dislike is that this allows people to omit OIDs
> from .dat entries in catalogs where we traditionally hand-assign OIDs.
> That's not a good idea because it would mean those entries don't have
> stable OIDs, whereas the whole point of hand as
Andres Freund writes:
> On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
>> Well, that's just a different very-easily-broken assumption. There are
>> a lot of things that make auto-assigned OIDs unstable, and I do not think
>> that we want to guarantee that they'll hold still across a release series
Hi,
On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-12-09 15:42:57 -0500, Stephen Frost wrote:
> >> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > I'm a bit dubious that this is a good idea. It's handy, at least for
> > forensic situations, that the system catalogs
Andres Freund writes:
> On 2018-12-09 15:42:57 -0500, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm a bit dubious that this is a good idea. It's handy, at least for
> forensic situations, that the system catalogs have stable OIDs.
> Hm, but won't they have that for major v
Hi,
On 2018-12-09 15:42:57 -0500, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > John Naylor writes:
> > > Commit 96cdeae07 added toast tables to most catalogs. One disadvantage
> > > is that the toast declarations require hard-coded oids, even though
> > > only shared catalogs
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> John Naylor writes:
> > Commit 96cdeae07 added toast tables to most catalogs. One disadvantage
> > is that the toast declarations require hard-coded oids, even though
> > only shared catalogs actually need stable oids. Now that we can assign
> >
John Naylor writes:
> Commit 96cdeae07 added toast tables to most catalogs. One disadvantage
> is that the toast declarations require hard-coded oids, even though
> only shared catalogs actually need stable oids. Now that we can assign
> oids on the fly, it makes sense to do so for toast tables as
Commit 96cdeae07 added toast tables to most catalogs. One disadvantage
is that the toast declarations require hard-coded oids, even though
only shared catalogs actually need stable oids. Now that we can assign
oids on the fly, it makes sense to do so for toast tables as well, as
in the attached.
-
20 matches
Mail list logo
