Andres Freund writes:
> On 2018-07-04 17:02:01 -0400, Alvaro Herrera wrote:
>> On 2018-Jul-04, Andres Freund wrote:
>>> I don't think we can easily require that everyone pg_upgrading to v13+
>>> upgrades to v12 first?
>> We've never done that, I don't know if we can get away with it.
>> Upgrades
On 2018-Jul-04, Andres Freund wrote:
> On 2018-07-04 17:02:01 -0400, Alvaro Herrera wrote:
> > On 2018-Jul-04, Andres Freund wrote:
> >
> > > > I think the soonest this can work is to add the column in pg12 so that
> > > > it can be used to upgrade to pg13.
> > >
> > > I don't think we can easil
On 2018-07-04 17:02:01 -0400, Alvaro Herrera wrote:
> On 2018-Jul-04, Andres Freund wrote:
>
> > > I think the soonest this can work is to add the column in pg12 so that
> > > it can be used to upgrade to pg13.
> >
> > I don't think we can easily require that everyone pg_upgrading to v13+
> > upg
On 2018-Jul-04, Andres Freund wrote:
> > I think the soonest this can work is to add the column in pg12 so that
> > it can be used to upgrade to pg13.
>
> I don't think we can easily require that everyone pg_upgrading to v13+
> upgrades to v12 first?
We've never done that, I don't know if we can
Hi,
On 2018-07-04 16:43:19 -0400, Alvaro Herrera wrote:
> On 2018-Jul-04, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > Requiring a scan of all indexes during pg_upgrade might increase the
> > > upgrade time prohibitively for some sites, so I don't think that's a
> > > good solution.
> >
>
On 2018-Jul-04, Tom Lane wrote:
> Alvaro Herrera writes:
> > Requiring a scan of all indexes during pg_upgrade might increase the
> > upgrade time prohibitively for some sites, so I don't think that's a
> > good solution.
>
> Perhaps VACUUM could be taught to clean up invalid entries? That
> wo
Alvaro Herrera writes:
> Requiring a scan of all indexes during pg_upgrade might increase the
> upgrade time prohibitively for some sites, so I don't think that's a
> good solution.
Perhaps VACUUM could be taught to clean up invalid entries? That
wouldn't help Andrey's unstated goal of being abl
On 2018-Jul-04, Andrey Borodin wrote:
> Thanks, Tom!
>
> So, I can create the script for pg_upgrade that will walk through each old
> enough[0] GiST index, scan for invalid tuples and repair them. This procedure
> seems quite trivial, but there will be more code that we have now. Does it
> sou
> 4 июля 2018 г., в 19:22, Tom Lane написал(а):
>
> Andrey Borodin writes:
>> There is bunch of code in current GiST implementation checking for
>> GistTupleIsInvalid(). PostgreSQL since 9.1 do not create invalid tuples.
>> Should we support this tuples forever?
>
> The question is not whe
Andrey Borodin writes:
> There is bunch of code in current GiST implementation checking for
> GistTupleIsInvalid(). PostgreSQL since 9.1 do not create invalid tuples.
> Should we support this tuples forever?
The question is not whether we still create such tuples. The reason
the code is still
Hi, hackers!
There is bunch of code in current GiST implementation checking for
GistTupleIsInvalid(). PostgreSQL since 9.1 do not create invalid tuples. Should
we support this tuples forever?
Invalid tuples were created in case of crash during GiST page split. They were
used as a recovery meas
11 matches
Mail list logo
