Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mff6K-00063r-5t for pgsql-www@arkaria.postgresql.org; Wed, 27 Oct 2021 09:20:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mff6J-0007Eo-0R for pgsql-www@arkaria.postgresql.org; Wed, 27 Oct 2021 09:20:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mff6I-0007Ef-IL for pgsql-www@lists.postgresql.org; Wed, 27 Oct 2021 09:20:02 +0000 Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mff6G-0000fO-42 for pgsql-www@lists.postgresql.org; Wed, 27 Oct 2021 09:20:02 +0000 Received: by mail-lj1-x22c.google.com with SMTP id o26so3613762ljj.2 for ; Wed, 27 Oct 2021 02:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VBqYJNV5EaESDPsQq2pXIyqIALFqJAdUpcLAyZQo0RE=; b=hw8o/y8RL/mu89AyrPxKSLMmNwA29AcZlYwRqAtWzph87HHgYMfg8XdY+T58yaZZhA CEcR0dVOwU/qXKB2tIK6tKi8WxAS2WBBLAWN0lKe0nLTOikBuGZwfN+Lp4YPsuvRfu/X OF7V9UnHwlm2qQHTNXceI/25MJGOqRgsHcdXVW+x4aN+pASW8M+MzMg2lQz2qF7Q2PBh GlcohO+YO0wgzYuPmvrbOqmAZi2s2HdHfqcP5+WufPFIYYbjEQUQ7QT+xra/FcYQUTfj Bxu4+YXCPi8N6e/PVNPRX0EBIoNgai0tfT6LwAoyrNnjOZxc5VxFFoTSuVY1Ihu9Tnuq ovCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VBqYJNV5EaESDPsQq2pXIyqIALFqJAdUpcLAyZQo0RE=; b=XtLhPuHSI3BsXq2P3D5dH7rSlRgmYBJwURa5WfiSYbPAXPFcTMNlJS1UpQ73AVHL0r Ci2WX3/MtrCz1FrFWlfZkBsvQvunKAdTcSW0A9mtyYVS+/LbgZ7JLhk3Qu2+loghPvkN lH/qd7hS6aXy4PzYRKXvJtIOugBGY/bt+YtuSwZvoj7SlOtfxg/Y7mtWZmDyTrncD4n9 tMfb6Mq0d06j/IySpMEpjWvBesHL/K51E5eD4XtwWaNsPlmtR53Y3hLyPnUTFZzIMuF+ mMnf/RHRbzya58yZqUwwo5E5TL/TQbmJ/MjX7+KUxlfDV6hP/r7nEbHTZU3pn+FAYBEM r8jg== X-Gm-Message-State: AOAM532ZANV1zseg1BVRi+HaWWMhdotjZkXyUhSuV1eHU6nZPftWo/YM TiW+KbuEidmv8IobODNgi4exQpcM7MHFmKDxq+Xu9CoyLYI= X-Google-Smtp-Source: ABdhPJyxMc1vHK+uztN7w7wWTIhsJ/vV1ELDGZz1A55v6mT85GvGvYPzSJKsC/1WsVMiHVmZ5TP6olwXA/z2mahFLuo= X-Received: by 2002:a2e:888a:: with SMTP id k10mr11948600lji.329.1635326397390; Wed, 27 Oct 2021 02:19:57 -0700 (PDT) MIME-Version: 1.0 References: <4280598e-cbe7-c5d3-fbce-fefce11da5f3@cmatte.me> <723b45bd-0c14-83eb-1911-b4f481e1b74c@cmatte.me> In-Reply-To: <723b45bd-0c14-83eb-1911-b4f481e1b74c@cmatte.me> From: Magnus Hagander Date: Wed, 27 Oct 2021 11:19:46 +0200 Message-ID: Subject: Re: [PATCH] pgarchives: Bugfix: allow message's parentid to be null To: =?UTF-8?Q?C=C3=A9lestin_Matte?= Cc: PostgreSQL WWW Content-Type: multipart/alternative; boundary="0000000000000236c105cf521972" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000000236c105cf521972 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 26, 2021 at 8:31 PM C=C3=A9lestin Matte wrote: > Attached: associated migration > > On 25/10/2021 16:52, C=C3=A9lestin Matte wrote: > > Hello, > > > > Upon execution of load_messages.py, when creating a new thread, I get a > crash: > > (Sorry about the format, I get this out of strace) > > > > Traceback (most recent call last):\n File > \"/srv/pgarchives/local/loader/load_message.py\", lin\ > > e 174, in \n ap.store(conn, listid, opt.overwrite, > opt.overwrite)\n File \"/srv/pgarchives/local/loader/li\ > > b/storage.py\", line 232, in store\n 'rawtxt': > bytearray(self.rawtxt),\npsycopg2.errors.NotNullViolation: null valu\ > > e in column \"parentid\" violates not-null constraint\nDETAIL: Failing > row contains (2, 2, cmatte > .tld>, helloworld@[my_pglister_domain], , Test archive after > redeployment 2, 2021-10-25 14:13:32+00, 1635171212.3\ > > 49997.1068459.nullmailer@[my_domain], hello world\n\n\n\n, null, f, > null, \\x46726f6d2068656c6c6f776f726c642d6f776\ > > e65722b617263686976654062..., '2':5A 'after':3A 'archive':2A 'hello':6 > 'redeployment':4A 'test...).\n\n > > > > I think the way to fix this is simply to allow message.parentid to be > null. > > Yeah, this looks to be another disreptency between the Django model and the schema.sql file. The table when created from schema.sql will allow nulls. So I can confirm that the field *should* allow nulls, and the only reason it hasn't been an actual problem is that we never ever do any writes to the system through the django model. That said, I think the correct solutoin is still, as I mentioned in one of the other threads, to completely move everything into the initial migration, instead of doing a piecemeal hack that's going to result in a lot of small migrations for no real reason. We should just accept that the existing one is broken and replace it. If you're willing to look into working on that I'd be happy to review on that one, but if it seems a bit too much I can work on that one myself as well, but it might take a bit before I have time to dig into it properly. //Magnus --0000000000000236c105cf521972 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 26, 2021 at 8:31 PM C=C3= =A9lestin Matte <celestin.ma= tte@cmatte.me> wrote:
Attached: associated migration

On 25/10/2021 16:52, C=C3=A9lestin Matte wrote:
> Hello,
>
> Upon execution of load_messages.py, when creating a new thread, I get = a crash:
> (Sorry about the format, I get this out of strace)
>
> Traceback (most recent call last):\n=C2=A0 File \"/srv/pgarchives= /local/loader/load_message.py\", lin\
> e 174, in <module>\n=C2=A0 =C2=A0 ap.store(conn, listid, opt.ove= rwrite, opt.overwrite)\n=C2=A0 File \"/srv/pgarchives/local/loader/li\=
> b/storage.py\", line 232, in store\n=C2=A0 =C2=A0 'rawtxt'= ;: bytearray(self.rawtxt),\npsycopg2.errors.NotNullViolation: null valu\ > e in column \"parentid\" violates not-null constraint\nDETAI= L:=C2=A0 Failing row contains (2, 2, cmatte <cmatte@[my_domain]\
> .tld>, helloworld@[my_pglister_domain], , Test archive after redepl= oyment 2, 2021-10-25 14:13:32+00, 1635171212.3\
> 49997.1068459.nullmailer@[my_domain], hello world\n\n\n\n, null, f, nu= ll, \\x46726f6d2068656c6c6f776f726c642d6f776\
> e65722b617263686976654062..., '2':5A 'after':3A 'a= rchive':2A 'hello':6 'redeployment':4A 'test...).\n= \n
>
> I think the way to fix this is simply to allow message.parentid to be = null.


Yeah, this looks to be anothe= r disreptency between the Django model and the schema.sql file. The table w= hen created from schema.sql will allow nulls. So I can confirm that the fie= ld *should* allow nulls, and the only reason it hasn't been an actual p= roblem is that we never ever do any writes to the system through the django= model.=C2=A0

That said, I think the correct solut= oin is still, as I mentioned in one of the other threads, to completely mov= e everything into the initial migration, instead of doing a piecemeal=C2=A0= hack that's going to result in a lot of small migrations for no real re= ason. We should=C2=A0 just accept that the existing one is broken and repla= ce it.

If you're willing to look into working = on that I'd be happy to review on that one, but if it seems a bit too m= uch I can work on that one myself as well, but it might take a bit before I= have time to dig into it properly.

//Magnus
=

--0000000000000236c105cf521972--