Re: Race between pg_dump and ALTER SEQUENCE can cause read failure

From: vignesh C <vignesh21(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Race between pg_dump and ALTER SEQUENCE can cause read failure
Date: 2026-07-29 04:57:04
Message-ID: CALDaNm1hMftcdBXuVRmSvg2cOh8FymqeuwVQwJVy-dojjZicAw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 29 Jul 2026 at 09:40, shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> I think logical sequence-sync worker can also hit this problem as
> worker fetches values from publisher using pg_get_sequence_data.
> Vignesh, right?

Yes, we will get an error like this in the log file:
2026-07-29 10:22:28.550 IST [36098] ERROR: could not fetch sequence
information from the publisher: ERROR: could not read blocks 0..0 in
file "base/5/16387": read only 0 of 8192 bytes
2026-07-29 10:22:28.552 IST [35941] LOG: background worker "logical
replication sequencesync worker" (PID 36098) exited with exit code 1

> It may not be that harmful though, as the worker will
> start again and get it right the next time.

Yes, it will be restarted after failure and sync the sequence.

> But whatever we decide we
> need to keep the seq-synchronization case in mind as well.

I agree.

Regards,
Vignesh

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2026-07-29 05:00:00 Re: nbtree backwards scan test coverage
Previous Message Michael Paquier 2026-07-29 04:54:34 Re: Fix race in background worker termination for database