On Wed, 9 Feb 2022 at 23:50, Michael Harris wrote:
>
> On Mon, 7 Feb 2022 at 09:57, Tom Lane wrote:
> > Do you want to try this and see if it actually adds any robustness with
> > your buggy code?
>
> Sorry for the delayed response, & thanks for the patch.
>
> I wasn't able to test with our actu
Michael Harris writes:
> On Mon, 7 Feb 2022 at 09:57, Tom Lane wrote:
>> Do you want to try this and see if it actually adds any robustness with your
>> buggy code?
> Sorry for the delayed response, & thanks for the patch.
> I wasn't able to test with our actual application because it could
>
On Mon, 7 Feb 2022 at 09:57, Tom Lane wrote:
> Do you want to try this and see if it actually adds any robustness with your
> buggy code?
Sorry for the delayed response, & thanks for the patch.
I wasn't able to test with our actual application because it could
take days for it to actually trigg
Michael Harris writes:
>> If Michael's analysis were accurate, I'd agree that there is a robustness
>> issue, but I don't think there is. See timeout.c:220:
> Actually that only sets a new timer after the nearest timeout has expired.
Mmm, yeah, you're right: as long as we keep on canceling time
> If Michael's analysis were accurate, I'd agree that there is a robustness
> issue, but I don't think there is. See timeout.c:220:
Actually that only sets a new timer after the nearest timeout has expired.
The pattern I was seeing went like this:
1. Command occurs during which a signal was not
Simon Riggs writes:
> On Thu, 3 Feb 2022 at 06:25, Michael Harris wrote:
>> Some of these functions trigger fetching of remote resources, for
>> which a timeout is set using `alarm`. The function unfortunately does
>> not re-establish any pre-existing interval timers after it is done,
>> which le
On Thu, 3 Feb 2022 at 06:25, Michael Harris wrote:
>
> Hi again
>
> Some good news. After some more debugging & reflection, I realized
> that the likely cause is one of our own libraries that gets loaded as
> part of some custom functions we are using.
>
> Some of these functions trigger fetching
pgsql-hackers list.
Cheers
Mike
On Tue, 1 Feb 2022 at 17:50, Michael Harris wrote:
>
> Hi
>
> The undetected deadlock occurred again today and I was able to collect
> some more info.
>
> The presentation was very similar to the case I reported previously:
> - One backend tr
Hi
The undetected deadlock occurred again today and I was able to collect
some more info.
The presentation was very similar to the case I reported previously:
- One backend trying to do a DROP TABLE on a partition of a
partitioned table, waiting for an AccessExclusiveLock on that table
- Another
> but I would expect drop concurrently to resolve your issue with the two
> processes conflicting
I guess you mean ALTER TABLE DETACH PARTITION ... CONCURRENTLY?
DROP TABLE does not seem to have a concurrent option.
Still that does seem like a good option to try, thanks for drawing it
to my atten
There may be a bug so perhaps still pursue reproducing the issue, but I
would expect drop concurrently to resolve your issue with the two processes
conflicting. Also, perhaps trying"insert, on conflict do update" could be
more efficient than the copy but obviously there are too many unknowns and
va
> I must be missing something. You mentioned dropping a partition, so is there
> an actual need for the delete? Could you detach concurrently and then drop
> the table or delete rows if needed?
The DELETE is part of a transaction performing data loading. Our
application allows data to be overwri
I must be missing something. You mentioned dropping a partition, so is
there an actual need for the delete? Could you detach concurrently and then
drop the table or delete rows if needed?
https://www.postgresql.org/docs/14/sql-altertable.html#SQL-ALTERTABLE-DETACH-PARTITION
ns. Even before we shifted to 14.1 and native
partitioning, we did get deadlocks between these two processes every
so often which we could not really prevent, so we adopted a retry
approach when it does occur. However we never had an undetected
deadlock in the database.
Since going to 14.1 & nativ
On 2022-Jan-25, Michael Harris wrote:
> We've recently updated our application to PG 14.1, and in the test instance we
> have started to see some alarming undetected deadlocks.
This is indeed suspicious / worrisome / curious.
What version were you using previously?
I reformatted the result sets
> On Jan 24, 2022, at 10:02 PM, Michael Harris wrote:
>
> My apologies,
>
> After posting this and looking at how it appears I realised that line
> wrapping makes the tables totally illegible.
>
> Here they are again with all unnecessary columns removed and others shortened.
>
> locktype |
My apologies,
After posting this and looking at how it appears I realised that line
wrapping makes the tables totally illegible.
Here they are again with all unnecessary columns removed and others shortened.
locktype | database | relation | pid |mode |
granted |
Hello Experts
I'm hoping you will be able to help me with a tricky issue.
We've recently updated our application to PG 14.1, and in the test instance we
have started to see some alarming undetected deadlocks.
An example of what we have seen is:
locktype | database | relation | page | tuple |
18 matches
Mail list logo
