Hi Alvaro,
On Thu, May 4, 2023 at 19:44 Alvaro Herrera wrote:
> On 2023-May-02, Alvaro Herrera wrote:
>
> > We have an open item about this, and I see no reason not to do it. I
> > checked, and putting things back is just a matter of reverting
> > 589bb816499e and ec386948948, cleaning up some
On 2023-May-02, Alvaro Herrera wrote:
> We have an open item about this, and I see no reason not to do it. I
> checked, and putting things back is just a matter of reverting
> 589bb816499e and ec386948948, cleaning up some trivial pgindent-induced
> conflicts, and bumping catversion once more. W
Hi Amit,
On 2023-Mar-30, Alvaro Herrera wrote:
> On 2023-Mar-29, Amit Langote wrote:
> > Though, I wonder if we need to keep ec386948948 that introduced the
> > notion of part_prune_index around if the project that needed it [1]
> > has moved on to an entirely different approach altogether, one
On 2023-Mar-29, Amit Langote wrote:
> On Wed, Mar 29, 2023 at 3:39 AM Tom Lane wrote:
> > Alvaro Herrera writes:
> > > So I'm back home and found a couple more weird errors in the log:
> >
> > > ERROR: mismatching PartitionPruneInfo found at part_prune_index 0
> > > DETALLE: plan node relids (
On Wed, Mar 29, 2023 at 3:39 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > So I'm back home and found a couple more weird errors in the log:
>
> > ERROR: mismatching PartitionPruneInfo found at part_prune_index 0
> > DETALLE: plan node relids (b 1), pruneinfo relids (b 36)
>
> This one reprod
Alvaro Herrera writes:
> So I'm back home and found a couple more weird errors in the log:
> ERROR: mismatching PartitionPruneInfo found at part_prune_index 0
> DETALLE: plan node relids (b 1), pruneinfo relids (b 36)
This one reproduces for me.
> select
> pg_catalog.pg_stat_get_buf_f
So I'm back home and found a couple more weird errors in the log:
MERGE INTO public.idxpart2 as target_0
USING (select 1
from
public.xmltest2 as ref_0
inner join public.prt1_l_p1 as sample_0
inner join fkpart4.droppk as ref
I wrote:
> The planner is reducing the scan of target_parted to
> a dummy scan, as is reasonable, but it forgets to
> provide ctid as an output from that scan; then the
> parent join node is unhappy because it does have
> a ctid output. So it looks like the problem is some
> shortcut we take while
I wrote:
> I reduced this down to
> MERGE INTO public.target_parted as target_0
> USING public.itest1 as ref_0
> ON target_0.b = ref_0.a
> WHEN NOT MATCHED
>THEN INSERT VALUES (42, 13);
> The critical moving part seems to just be that the MERGE target
> is a partitioned table
Alvaro Herrera writes:
> I have to run now so can't dissect it, but while running sqlsmith on the
> SQL/JSON patch after Justin's report, I got $SUBJECT in this query:
I reduced this down to
MERGE INTO public.target_parted as target_0
USING public.itest1 as ref_0
ON target_0.b = ref_0.a
Alvaro Herrera writes:
> I have to run now so can't dissect it, but while running sqlsmith on the
> SQL/JSON patch after Justin's report, I got $SUBJECT in this query:
Reproduces in HEAD and v15 too (once you replace pg_catalog.system_user
with some function that exists in v15). So it's not the
11 matches
Mail list logo
