public inbox for [email protected]  
help / color / mirror / Atom feed
Why is an error not thrown when the time exceeds the lock timeout for an ExclusiveLock on a transaction ?
2+ messages / 2 participants
[nested] [flat]

* Why is an error not thrown when the time exceeds the lock timeout for an ExclusiveLock on a transaction ?
@ 2025-04-18 17:28  Mansky, Edmund J. (GSFC-671.0)[ADNET Affiliate] <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: Mansky, Edmund J. (GSFC-671.0)[ADNET Affiliate] @ 2025-04-18 17:28 UTC (permalink / raw)
  To: pgsql-general; +Cc: Mansky, Edmund J. (GSFC-671.0)[ADNET Affiliate] <[email protected]>

Hi Everyone,

I have an SQL that updates a table in our database. The SQL in question is:

UPDATE public.sum_partn_alloc AS T1 SET effective_date = to_char(CURRENT_TIMESTAMP + interval '6 days', 'YYYYMMDDHH24MI') FROM public.sum_main AS T2
        WHERE T1.status != 8 AND (T1.effective_date = '0' OR CURRENT_TIMESTAMP + interval '3 days' >  to_timestamp(T1.effective_date, 'YYYYMMDDHH24MI'))
        AND T1.ds_index IN (1741052236) AND T1.ds_index = T2.ds_index AND T2.online_status = 'Y'

where the number in BOLD in the list can be just a single number, or a long list of numbers (20-50 or so).

Normally, this SQL is executed without problem thousands of times a day.

Then, we see at certain times when that SQL exceeds the timeout for the ShareLock on the transaction. No error is thrown from the DB and processing on the driving Python script stops.
I've seen this in the case of a single number in the list, or a long list of 20-50 numbers or so.

I see in the log at that point : process 683860 still waiting for ShareLock on transaction 492777941 after 1000.140 ms
                                              while updating tuple (1282991,25) in relation "sum_partn_alloc"

The Postgres server (12.22), running on RHEL 8.10 is configured with a default lock timeout of 1 sec.

Why is Postgres not throwing an error when the ShareLock time has exceeded 1 sec. ?

The Python script driving this SQL never gets an error from Postgres in it's exception block, and hence the script simply stops at that point and processing stops.

Are there other parameters one can set in the configuration that would result in the Python script getting an error from Postgres so that this case can be handled and processing continues ?

Any ideas or tips would be greatly appreciated.

Thanks,

--Ed






[signature_1379146699]

Ed Mansky
Software Engineer
SDAC / VSO
NASA Goddard Space Flight Center
ADNET SYSTEMS, Inc.
8800 Greenbelt Rd, Greenbelt MD 20771
[email protected]<mailto:[email protected]>






Attachments:

  [image/jpeg] image001.jpg (5.8K, 3-image001.jpg)
  download | view image

  [image/png] image002.png (275B, 4-image002.png)
  download | view image

^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Why is an error not thrown when the time exceeds the lock timeout for an ExclusiveLock on a transaction ?
@ 2025-04-18 18:22  Tom Lane <[email protected]>
  parent: Mansky, Edmund J. (GSFC-671.0)[ADNET Affiliate] <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Tom Lane @ 2025-04-18 18:22 UTC (permalink / raw)
  To: Mansky, Edmund J. (GSFC-671.0)[ADNET Affiliate] <[email protected]>; +Cc: pgsql-general

"Mansky, Edmund J. (GSFC-671.0)[ADNET Affiliate]" <[email protected]> writes:
> I see in the log at that point : process 683860 still waiting for ShareLock on transaction 492777941 after 1000.140 ms
>                                               while updating tuple (1282991,25) in relation "sum_partn_alloc"

> The Postgres server (12.22), running on RHEL 8.10 is configured with a default lock timeout of 1 sec.

> Why is Postgres not throwing an error when the ShareLock time has exceeded 1 sec. ?

I think you have misread the description of deadlock_timeout: it is
the lock wait time after which we check to see if there's a deadlock.
If there's not, we just log the above message (if configured to do so)
and keep waiting.

If you want to fail after X amount of time, lock_timeout or perhaps
statement_timeout is what to set for that.

			regards, tom lane






^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2025-04-18 18:22 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-04-18 17:28 Why is an error not thrown when the time exceeds the lock timeout for an ExclusiveLock on a transaction ? Mansky, Edmund J. (GSFC-671.0)[ADNET Affiliate] <[email protected]>
2025-04-18 18:22 ` Tom Lane <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox