| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Git Queries <gitqueries0(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18084: Count Mismatch Challenges During PostgreSQL Database Migration: Causes and Solutions |
| Date: | 2023-09-07 01:00:15 |
| Message-ID: | ZPkgn2sIEj6yryb7@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Sep 7, 2023 at 12:26:53PM +1200, David Rowley wrote:
> On Thu, 7 Sept 2023 at 11:17, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > On Wed, Sep 6, 2023 at 11:11:05PM +0530, Git Queries wrote:
> > > Migration was performed using pg_dump.
> >
> > Uh, that is kind of a surprise since pg_dump/restore does a logical dump
> > --- none of the binary files are transfered, so it should always be
> > accurate.
>
> I can't be certain, but I think the likely reason here is that the
> newly restored instance is fine and all indexes match the heap, but
> it's the source instance that has indexes with missing entries. Since
> the pg_dump queries are most likely to result in seqscans, then all
> rows will be returned and the new instance has no missing rows.
Yes, very good point.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James Pang (chaolpan) | 2023-09-07 01:35:00 | FW: query pg_stat_ssl hang 100%cpu |
| Previous Message | David Rowley | 2023-09-07 00:26:53 | Re: BUG #18084: Count Mismatch Challenges During PostgreSQL Database Migration: Causes and Solutions |