Re: BUG #15114: logical decoding Segmentation fault

From: Петър Славов <pet(dot)slavov(at)gmail(dot)com>
To: michael(at)paquier(dot)xyz
Cc: petr(dot)jelinek(at)2ndquadrant(dot)com, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Re: BUG #15114: logical decoding Segmentation fault
Date: 2018-10-29 08:44:10
Message-ID: CAC5T6ECQ13nkya=xea-0QJjF1mQo45Hw+mMftBCJS7rbSYS49Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Michael,

My latest tests was with immutable function with a now() function inside,
which is a little different. Here is the schema that replicates the problem:

on Producer:
CREATE FUNCTION public.months_ago(integer) RETURNS timestamp without time
zone

LANGUAGE sql IMMUTABLE
AS $_$
SELECT (NOW() - '1 month'::interval * $1)::timestamp;
$_$;

CREATE TABLE public.replicated_table (
id serial PRIMARY KEY NOT NULL,
a text,
b bigint,
created_at timestamp without time zone DEFAULT now()
);

CREATE INDEX ON public.replicated_table (a) WHERE (created_at >
public.months_ago(4));

on Subscriber:
CREATE TABLE public.replicated_table (
id integer NOT NULL,
a text,
b bigint,
created_at timestamp without time zone DEFAULT now()
);

Peter

На пн, 29.10.2018 г. в 2:54 ч. Michael Paquier <michael(at)paquier(dot)xyz> написа:

> On Sun, Oct 28, 2018 at 11:59:49PM +0100, Petr Jelinek wrote:
> > I wrote my own patch to solve this which is quite similar to Alvaro's
> > except that it does not do the manual work to build indexes list as we
> > already have RelationGetReplicaIndex which does all the necessary work
> > and also uses the same rd_idattr for cache that
> > RelationGetIndexAttrBitmap does, it's better for performance and looks
> > safe to me.
> >
> > I attached both patch for PG11+ (ie master) and the backport patch for
> > PG10, they only differ in the line identified above as problematic.
>
> Hmm. I am studying this patch, and this visibly cannot be easily
> reproduced? I would have imagined that something like this would be
> enough, with a predicate index on the publisher side which is in charge
> of loading the :
> -- connect to publisher
> \c postgres postgres /tmp 5432
> create table aa (a int not null, b int);
> create function copy_int(a int) returns int as $$ select $1 $$
> language sql immutable;
> create index aai on aa (b) where copy_int(b) > 0;
> create unique index aai2 on aa (a);
> alter table aa replica identity using index aai2;
> create publication big_tables for table aa;
> insert into aa values (generate_series(1,100), 1);
>
> -- connect to subscriber
> \c postgres postgres /tmp 5433
> create table aa (a int not null, b int);
> create function copy_int(a int) returns int as $$ select $1 $$
> language sql immutable;
> create index aai on aa (b) where copy_int(b) > 0;
> create unique index aai2 on aa (a);
> alter table aa replica identity using index aai2;
> create subscription sub_name CONNECTION 'host=/tmp dbname=postgres
> user=postgres' PUBLICATION big_tables;
>
> Is there something I am missing?
>
> If possible, could it be possible to add a test case in
> 001_rep_changes.pl with a more complete schema?
> --
> Michael
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2018-10-29 11:41:19 Re: BUG #15460: Error while creating index or constraint
Previous Message Sandeep Thakkar 2018-10-29 08:22:29 Re: BUG #15453: Installer registers with major version only