Alvaro Herrera writes:
> Thanks both -- pushed. I also changed regress/sql/triggers to leave
> tables around that have a non-zero tgparentid. This ensures that the
> pg_upgrade test sees such objects, as well as findoidjoins.
> I refrained from doing the findoidjoins dance itself, though; I got
Thanks both -- pushed. I also changed regress/sql/triggers to leave
tables around that have a non-zero tgparentid. This ensures that the
pg_upgrade test sees such objects, as well as findoidjoins.
I refrained from doing the findoidjoins dance itself, though; I got a
large number of false positiv
On Tue, Feb 25, 2020 at 11:01 PM Alvaro Herrera
wrote:
> On 2020-Feb-25, Amit Langote wrote:
> > On Tue, Feb 25, 2020 at 3:58 AM Alvaro Herrera
> > wrote:
> > > Thanks for pointing this out -- I agree it needed rewording. I slightly
> > > adjusted your text like this:
> > >
> > >
On 2020-Feb-25, Amit Langote wrote:
> On Tue, Feb 25, 2020 at 3:58 AM Alvaro Herrera
> wrote:
> > Thanks for pointing this out -- I agree it needed rewording. I slightly
> > adjusted your text like this:
> >
> > * Internal triggers require careful examination. Ideally,
> > w
Hi Alvaro,
On Tue, Feb 25, 2020 at 3:58 AM Alvaro Herrera wrote:
> On 2020-Feb-19, Amit Langote wrote:
>
> > Or:
> >
> > * However, if our parent is a partition itself, there might be
> > * internal triggers that must not be skipped. For example,
> > triggers
> > * on
On 2020-Feb-19, Amit Langote wrote:
> Or:
>
> * However, if our parent is a partition itself, there might be
> * internal triggers that must not be skipped. For example, triggers
> * on the parent that were in turn cloned from its own parent are
> * marked int
On Tue, Feb 18, 2020 at 1:11 PM Amit Langote wrote:
> On Tue, Feb 18, 2020 at 6:56 AM Alvaro Herrera
> wrote:
> @@ -16541,7 +16493,7 @@ CloneRowTriggersToPartition(Relation parent,
> Relation partition)
> *
> * However, if our parent is a partitioned relation, there might be
>
> This is exis
On Tue, Feb 18, 2020 at 6:56 AM Alvaro Herrera wrote:
> As mentioned in https://postgr.es/m/20191231194759.GA24692@alvherre.pgsql
> I propose to add a new column to pg_trigger, which allows us to remove a
> pg_depend scan when cloning triggers when adding/attaching partitions.
> (It's not that I t
Alvaro Herrera writes:
> As mentioned in https://postgr.es/m/20191231194759.GA24692@alvherre.pgsql
> I propose to add a new column to pg_trigger, which allows us to remove a
> pg_depend scan when cloning triggers when adding/attaching partitions.
> (It's not that I think the scan is a performance
As mentioned in https://postgr.es/m/20191231194759.GA24692@alvherre.pgsql
I propose to add a new column to pg_trigger, which allows us to remove a
pg_depend scan when cloning triggers when adding/attaching partitions.
(It's not that I think the scan is a performance problem, but rather
than notiona
10 matches
Mail list logo