| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, Noah Misch <noah(at)leadboat(dot)com>, Jeff Davis <jdavis(at)postgresql(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pgsql: Add contrib/pg_walinspect. |
| Date: | 2022-04-30 16:24:02 |
| Message-ID: | c094bde0d6a984e21535fc66d31dc0f0b4ff4d6a.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Fri, 2022-04-29 at 10:46 +0530, Bharath Rupireddy wrote:
> It's not just the flush ptr, without no wait mode, the functions
> would
> wait if start/input lsn is, say current flush lsn - 1 or 2 or more
> (before the previous record) bytes. If the functions were to wait, by
> how much time should they wait? a timeout? forever?
I see, you're talking about the case of XLogFindNextRecord(), not
XLogReadRecord().
XLogFindNextRecord() is the only way to align the user-provided start
LSN on a valid record, but that calls XLogReadRecord(), which may wait
indefinitely. If there were a different entry point that just did the
alignment and skipped past continuation records, we could prevent it
from trying to read the next record if we are already at the flush
pointer. But without some tweak to that API, nowait is still needed.
Committed your v3 patch with minor modifications.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2022-04-30 20:52:54 | Re: pgsql: Remove command checks in tests of pg_basebackup and pg_receivewa |
| Previous Message | Jeff Davis | 2022-04-30 16:21:33 | pgsql: pg_walinspect: fix case where flush LSN is in the middle of a re |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2022-04-30 16:40:46 | Re: bogus: logical replication rows/cols combinations |
| Previous Message | Tom Lane | 2022-04-30 15:57:55 | Re: Missing can't-assign-to-constant checks in plpgsql |