| 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
| 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 |