This commit assigns OIDs from the reserved range:
+DECLARE_TOAST(pg_depend, , 8889);
Do you want to try the renumber_oids.pl script to fix this?
On 2020-11-02 13:27, Thomas Munro wrote:
Add pg_depend.refobjversion.
Provide a place for the version of referenced database objects to be
reco
On 2020/11/05 6:02, Fujii Masao wrote:
On 2020/11/05 5:36, Heikki Linnakangas wrote:
On 04/11/2020 15:17, Heikki Linnakangas wrote:
On 04/11/2020 14:03, Fujii Masao wrote:
Or ISTM that WakeupRecovery() should set the latch only when the latch
has not been reset to NULL yet.
Got to be car
Peter Eisentraut writes:
> This commit assigns OIDs from the reserved range:
> +DECLARE_TOAST(pg_depend, , 8889);
> Do you want to try the renumber_oids.pl script to fix this?
AFAIK the agreed-on process is to do that once per release cycle.
Is there some reason why it needs to be done now?
Don't throw an error for LOCK TABLE on a self-referential view.
LOCK TABLE has complained about "infinite recursion" when applied
to a self-referential view, ever since we made it recurse into views
in v11. However, that breaks pg_dump's new assumption that it's
okay to lock every relation. Ther
Don't throw an error for LOCK TABLE on a self-referential view.
LOCK TABLE has complained about "infinite recursion" when applied
to a self-referential view, ever since we made it recurse into views
in v11. However, that breaks pg_dump's new assumption that it's
okay to lock every relation. Ther
Don't throw an error for LOCK TABLE on a self-referential view.
LOCK TABLE has complained about "infinite recursion" when applied
to a self-referential view, ever since we made it recurse into views
in v11. However, that breaks pg_dump's new assumption that it's
okay to lock every relation. Ther
Don't throw an error for LOCK TABLE on a self-referential view.
LOCK TABLE has complained about "infinite recursion" when applied
to a self-referential view, ever since we made it recurse into views
in v11. However, that breaks pg_dump's new assumption that it's
okay to lock every relation. Ther
On 2020-11-05 15:50, Tom Lane wrote:
Peter Eisentraut writes:
This commit assigns OIDs from the reserved range:
+DECLARE_TOAST(pg_depend, , 8889);
Do you want to try the renumber_oids.pl script to fix this?
AFAIK the agreed-on process is to do that once per release cycle.
Is there some
On Thu, Nov 5, 2020 at 3:50 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > This commit assigns OIDs from the reserved range:
> > +DECLARE_TOAST(pg_depend, , 8889);
>
> > Do you want to try the renumber_oids.pl script to fix this?
>
> AFAIK the agreed-on process is to do that once per rel
Magnus Hagander writes:
> On Thu, Nov 5, 2020 at 3:50 PM Tom Lane wrote:
>> AFAIK the agreed-on process is to do that once per release cycle.
>> Is there some reason why it needs to be done now?
> Did we ever actually document this process somewhere? I went looking
> for it some time ago and fai
On Thu, Nov 5, 2020 at 8:17 PM Tom Lane wrote:
>
> Magnus Hagander writes:
> > On Thu, Nov 5, 2020 at 3:50 PM Tom Lane wrote:
> >> AFAIK the agreed-on process is to do that once per release cycle.
> >> Is there some reason why it needs to be done now?
>
> > Did we ever actually document this pro
Fix wal_consistency_checking nbtree bug.
wal_consistency_checking indicated an inconsistency in certain cases
involving nbtree page deletion. The underlying issue is that there was
a minor difference between the page image produced after a REDO routine
ran and the corresponding page image followi
Use strlcpy instead of memcpy for copying the slot name in pgstat.c.
There is no outright bug here but it is better to be consistent with the
usage at other places in the same file. In the passing, fix a wrong
assertion in pgstat_recv_replslot.
Author: Kyotaro Horiguchi
Reviewed-by: Sawada Masahi
13 matches
Mail list logo
