Amit Langote writes:
> On Thu, Sep 17, 2020 at 3:40 AM Tom Lane wrote:
>> I also did a bit more work on the comments. (Speaking of which,
>> is there a better place to put the commentary you removed from
>> InitResultRelInfo? It was surely wildly out of place there,
>> but I'm wondering if mayb
On Thu, Sep 17, 2020 at 3:40 AM Tom Lane wrote:
> Amit Langote writes:
> > Updated patch attached.
>
> Pushed with a little bit of fooling about.
Thank you.
> After looking at the
> git history, I saw that the Assert we were wondering about used to
> be just "Assert(constr)", and there were no
Thanx Tom and Amit for the effort.
Looking forward to try it out.
D.
-Original Message-
From: Tom Lane
Sent: 16. rujna 2020. 20:41
To: Amit Langote
Cc: Alvaro Herrera ; Domagoj Smoljanovic
; pgsql-hack...@postgresql.org
Subject: Re: pg_restore causing deadlocks on partitioned tables
Amit Langote writes:
> Updated patch attached.
Pushed with a little bit of fooling about. After looking at the
git history, I saw that the Assert we were wondering about used to
be just "Assert(constr)", and there were not run-time checks on
whether constr is null. That was changed when f0e4475
On Wed, Sep 16, 2020 at 2:41 AM Tom Lane wrote:
> Amit Langote writes:
> > On Tue, Sep 15, 2020 at 7:28 AM Tom Lane wrote:
> >> AFAICS, it is utterly silly for InitResultRelInfo to be forcing
> >> a partition qual to be computed when we might not need it.
> >> We could flush ResultRelInfo.ri_Par
Amit Langote writes:
> On Tue, Sep 15, 2020 at 7:28 AM Tom Lane wrote:
>> AFAICS, it is utterly silly for InitResultRelInfo to be forcing
>> a partition qual to be computed when we might not need it.
>> We could flush ResultRelInfo.ri_PartitionCheck altogether and
>> have anything that was readin
Amit Langote writes:
> On Tue, Sep 15, 2020 at 10:47 PM Tom Lane wrote:
>> Ah, right. That seems like a bug but we have not attempted to fix it.
> IIRC, when this behavior was brought up as a bug in past discussions,
> it was decided that it will be fixed when NOT NULL constraints are
> represe
On Tue, Sep 15, 2020 at 10:47 PM Tom Lane wrote:
> Amit Langote writes:
> > On Tue, Sep 15, 2020 at 9:09 AM Tom Lane wrote:
> >> I wrote a quick patch for this part. It seems pretty safe and probably
> >> could be back-patched without fear.
>
> > The patch's theory that if the parent column has
Amit Langote writes:
> On Tue, Sep 15, 2020 at 9:09 AM Tom Lane wrote:
>> I wrote a quick patch for this part. It seems pretty safe and probably
>> could be back-patched without fear.
> The patch's theory that if the parent column has NOT NULL set then it
> must be set in child tables too does
On Tue, Sep 15, 2020 at 7:28 AM Tom Lane wrote:
> I wrote:
> > However, the deadlock report suggests, and manual experimentation
> > confirms, that
>
> > (1) TRUNCATE on a partition tries to get AccessShareLock on the parent;
>
> The reason for this is that
>
> (a) ExecuteTruncateGuts calls InitRe
On Tue, Sep 15, 2020 at 9:09 AM Tom Lane wrote:
> I wrote:
> >> (2) ALTER TABLE ONLY ... ADD CONSTRAINT on a partition root tries to get
> >> AccessExclusiveLock on all child partitions, despite the ONLY.
>
> > The cause of this seems to be that ATPrepSetNotNull is too dumb to
> > avoid recursing
Alvaro Herrera writes:
> On 2020-Sep-14, Tom Lane wrote:
>> AFAICS, it is utterly silly for InitResultRelInfo to be forcing
>> a partition qual to be computed when we might not need it.
>> We could flush ResultRelInfo.ri_PartitionCheck altogether and
>> have anything that was reading it instead do
On 2020-Sep-14, Tom Lane wrote:
> > (1) TRUNCATE on a partition tries to get AccessShareLock on the parent;
>
> The reason for this is that
>
> (a) ExecuteTruncateGuts calls InitResultRelInfo, because it might
> need that to fire TRUNCATE triggers for the child relation.
Hmm, this seems legitim
I wrote:
>> (2) ALTER TABLE ONLY ... ADD CONSTRAINT on a partition root tries to get
>> AccessExclusiveLock on all child partitions, despite the ONLY.
> The cause of this seems to be that ATPrepSetNotNull is too dumb to
> avoid recursing to all the child tables when the parent is already
> attnotn
I wrote:
> However, the deadlock report suggests, and manual experimentation
> confirms, that
> (1) TRUNCATE on a partition tries to get AccessShareLock on the parent;
The reason for this is that
(a) ExecuteTruncateGuts calls InitResultRelInfo, because it might
need that to fire TRUNCATE trigger
I wrote:
> If memory serves, which it may not given my undercaffeinated state,
> we would not expect there to be a direct dependency link between the
> constraint and the table data "object". What there should be is
> dependencies forcing the data to be restored before the post-data
> boundary pse
Alvaro Herrera writes:
> On 2020-Sep-14, Tom Lane wrote:
>> Hm, this seems related to 2ba5b2db7, but not the same thing.
>> Alvaro, any thoughts?
> So apparently when we go to restore the table data for the partition,
> the TRUNCATE deadlocks with the PK addition ... that's pretty odd;
> shouldn'
Forgot to mention the versions:
pg_restore (PostgreSQL) 12.4
source/ destination databases also 12.4
D.
-Original Message-
From: Alvaro Herrera
Sent: 14. rujna 2020. 16:40
To: Tom Lane
Cc: Domagoj Smoljanovic ;
pgsql-hack...@postgresql.org
Subject: Re: pg_restore causing deadlocks on
On 2020-Sep-14, Tom Lane wrote:
> Domagoj Smoljanovic writes:
> > I have pg_restore running in parallel (3 or more) and processing large
> > amount of data that is in partitioned tables. However it seems that
> > sometime deadlock appears when one process is trying to process primary key
> > o
Domagoj Smoljanovic writes:
> I have pg_restore running in parallel (3 or more) and processing large amount
> of data that is in partitioned tables. However it seems that sometime
> deadlock appears when one process is trying to process primary key on parent
> table while data still hasn’t been
20 matches
Mail list logo