public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v3 3/3] Fix timeline-tracking failure while sending a historic timeline
5+ messages / 3 participants
[nested] [flat]
* [PATCH v3 3/3] Fix timeline-tracking failure while sending a historic timeline
@ 2020-12-09 08:22 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Kyotaro Horiguchi @ 2020-12-09 08:22 UTC (permalink / raw)
Walsender should track timeline switches while sending a historic
timeline. Regain that behavior, which was broken in PG13, by a thinko
of 709d003fbd.
---
src/backend/replication/walsender.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index fe0d368a35..8545c6c423 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -2491,7 +2491,7 @@ WalSndSegmentOpen(XLogReaderState *state, XLogSegNo nextSegNo,
XLogSegNo endSegNo;
XLByteToSeg(sendTimeLineValidUpto, endSegNo, state->segcxt.ws_segsize);
- if (state->seg.ws_segno == endSegNo)
+ if (nextSegNo == endSegNo)
*tli_p = sendTimeLineNextTLI;
}
--
2.27.0
----Next_Part(Tue_Jan__5_17_26_02_2021_224)----
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Unlogged relations and WAL-logging
@ 2023-07-07 15:21 Heikki Linnakangas <[email protected]>
2023-08-23 14:40 ` Re: Unlogged relations and WAL-logging Heikki Linnakangas <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Heikki Linnakangas @ 2023-07-07 15:21 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
On 28/01/2022 15:57, Robert Haas wrote:
> On Thu, Jan 27, 2022 at 2:32 PM Heikki Linnakangas <[email protected]> wrote:
>> Unlogged relations are not WAL-logged, but creating the init-fork is.
>> There are a few things around that seem sloppy:
>>
>> 1. In index_build(), we do this:
>>
>>> */
>>> if (indexRelation->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED &&
>>> !smgrexists(RelationGetSmgr(indexRelation), INIT_FORKNUM))
>>> {
>>> smgrcreate(RelationGetSmgr(indexRelation), INIT_FORKNUM, false);
>>> indexRelation->rd_indam->ambuildempty(indexRelation);
>>> }
>>
>> Shouldn't we call log_smgrcreate() here? Creating the init fork is
>> otherwise not WAL-logged at all.
>
> Yes, that's a bug.
Pushed and backpatched this patch (commit 3142a8845b).
>> 2. Some implementations of ambuildempty() use the buffer cache (hash,
>> gist, gin, brin), while others bypass it and call smgrimmedsync()
>> instead (btree, spgist, bloom). I don't see any particular reason for
>> those decisions, it seems to be based purely on which example the author
>> happened to copy-paste.
>
> I thought that this inconsistency was odd when I was developing the
> unlogged feature, but I tried to keep each routine's ambuildempty()
> consistent with whatever ambuild() was doing. I don't mind if you want
> to change it, though.
>
>> 3. Those ambuildempty implementations that bypass the buffer cache use
>> smgrwrite() to write the pages. That doesn't make any difference in
>> practice, but in principle it's wrong: You are supposed to use
>> smgrextend() when extending a relation.
>
> That's a mistake on my part.
>
>> 4. Also, the smgrwrite() calls are performed before WAL-logging the
>> pages, so the page that's written to disk has 0/0 as the LSN, not the
>> LSN of the WAL record. That's harmless too, but seems a bit sloppy.
>
> That is also a mistake on my part.
I'm still sitting on these fixes. I think the patch I posted still makes
sense, but I got carried away with a more invasive approach that
introduces a whole new set of functions for bulk-creating a relation,
which would handle WAL-logging, smgrimmedsync() and all that (see
below). We have some repetitive, error-prone code in all the index build
functions for that. But that's not backpatchable, so I'll rebase the
original approach next week.
>> 5. In heapam_relation_set_new_filenode(), we do this:
>>
>>>
>>> /*
>>> * If required, set up an init fork for an unlogged table so that it can
>>> * be correctly reinitialized on restart. An immediate sync is required
>>> * even if the page has been logged, because the write did not go through
>>> * shared_buffers and therefore a concurrent checkpoint may have moved the
>>> * redo pointer past our xlog record. Recovery may as well remove it
>>> * while replaying, for example, XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE
>>> * record. Therefore, logging is necessary even if wal_level=minimal.
>>> */
>>> if (persistence == RELPERSISTENCE_UNLOGGED)
>>> {
>>> Assert(rel->rd_rel->relkind == RELKIND_RELATION ||
>>> rel->rd_rel->relkind == RELKIND_MATVIEW ||
>>> rel->rd_rel->relkind == RELKIND_TOASTVALUE);
>>> smgrcreate(srel, INIT_FORKNUM, false);
>>> log_smgrcreate(newrnode, INIT_FORKNUM);
>>> smgrimmedsync(srel, INIT_FORKNUM);
>>> }
>>
>> The comment doesn't make much sense, we haven't written nor WAL-logged
>> any page here, with nor without the buffer cache. It made more sense
>> before commit fa0f466d53.
>
> Well, it seems to me (and perhaps I am just confused) that complaining
> that there's no page written here might be a technicality. The point
> is that there's no synchronization between the work we're doing here
> -- which is creating a fork, not writing a page -- and any concurrent
> checkpoint. So we both need to log it, and also sync it immediately.
I see. I pushed the fix from the other thread that makes smgrcreate()
call register_dirty_segment (commit 4b4798e13). I believe that makes
this smgrimmedsync() unnecessary. If a concurrent checkpoint happens
with a redo pointer greater than this WAL record, it must've received
the fsync request created by smgrcreate(). That depends on the fact that
we write the WAL record *after* smgrcreate(). Subtle..
Hmm, we have a similar smgrimmedsync() call after index build, because
we have written pages directly with smgrextend(skipFsync=true). If no
checkpoints have occurred during the index build, we could call
register_dirty_segment() instead of smgrimmedsync(). That would avoid
the fsync() latency when creating an index on an empty or small index.
This is all very subtle to get right though. That's why I'd like to
invent a new bulk-creation facility that would handle this stuff, and
make the callers less error-prone.
--
Heikki Linnakangas
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Unlogged relations and WAL-logging
2023-07-07 15:21 Re: Unlogged relations and WAL-logging Heikki Linnakangas <[email protected]>
@ 2023-08-23 14:40 ` Heikki Linnakangas <[email protected]>
2023-09-01 12:49 ` Re: Unlogged relations and WAL-logging Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Heikki Linnakangas @ 2023-08-23 14:40 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
On 07/07/2023 18:21, Heikki Linnakangas wrote:
> On 28/01/2022 15:57, Robert Haas wrote:
>>> 4. Also, the smgrwrite() calls are performed before WAL-logging the
>>> pages, so the page that's written to disk has 0/0 as the LSN, not the
>>> LSN of the WAL record. That's harmless too, but seems a bit sloppy.
>>
>> That is also a mistake on my part.
>
> I'm still sitting on these fixes. I think the patch I posted still makes
> sense, but I got carried away with a more invasive approach that
> introduces a whole new set of functions for bulk-creating a relation,
> which would handle WAL-logging, smgrimmedsync() and all that (see
> below). We have some repetitive, error-prone code in all the index build
> functions for that. But that's not backpatchable, so I'll rebase the
> original approach next week.
Committed this fix to master and v16. Didn't seem worth backpatching
further than that, given that there is no live user-visible issue here.
>>> 5. In heapam_relation_set_new_filenode(), we do this:
>>>
>>>>
>>>> /*
>>>> * If required, set up an init fork for an unlogged table so that it can
>>>> * be correctly reinitialized on restart. An immediate sync is required
>>>> * even if the page has been logged, because the write did not go through
>>>> * shared_buffers and therefore a concurrent checkpoint may have moved the
>>>> * redo pointer past our xlog record. Recovery may as well remove it
>>>> * while replaying, for example, XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE
>>>> * record. Therefore, logging is necessary even if wal_level=minimal.
>>>> */
>>>> if (persistence == RELPERSISTENCE_UNLOGGED)
>>>> {
>>>> Assert(rel->rd_rel->relkind == RELKIND_RELATION ||
>>>> rel->rd_rel->relkind == RELKIND_MATVIEW ||
>>>> rel->rd_rel->relkind == RELKIND_TOASTVALUE);
>>>> smgrcreate(srel, INIT_FORKNUM, false);
>>>> log_smgrcreate(newrnode, INIT_FORKNUM);
>>>> smgrimmedsync(srel, INIT_FORKNUM);
>>>> }
>>>
>>> The comment doesn't make much sense, we haven't written nor WAL-logged
>>> any page here, with nor without the buffer cache. It made more sense
>>> before commit fa0f466d53.
>>
>> Well, it seems to me (and perhaps I am just confused) that complaining
>> that there's no page written here might be a technicality. The point
>> is that there's no synchronization between the work we're doing here
>> -- which is creating a fork, not writing a page -- and any concurrent
>> checkpoint. So we both need to log it, and also sync it immediately.
>
> I see. I pushed the fix from the other thread that makes smgrcreate()
> call register_dirty_segment (commit 4b4798e13). I believe that makes
> this smgrimmedsync() unnecessary. If a concurrent checkpoint happens
> with a redo pointer greater than this WAL record, it must've received
> the fsync request created by smgrcreate(). That depends on the fact that
> we write the WAL record *after* smgrcreate(). Subtle..
>
> Hmm, we have a similar smgrimmedsync() call after index build, because
> we have written pages directly with smgrextend(skipFsync=true). If no
> checkpoints have occurred during the index build, we could call
> register_dirty_segment() instead of smgrimmedsync(). That would avoid
> the fsync() latency when creating an index on an empty or small index.
>
> This is all very subtle to get right though. That's why I'd like to
> invent a new bulk-creation facility that would handle this stuff, and
> make the callers less error-prone.
Having a more generic and less error-prone bulk-creation mechanism is
still on my long TODO list..
--
Heikki Linnakangas
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Unlogged relations and WAL-logging
2023-07-07 15:21 Re: Unlogged relations and WAL-logging Heikki Linnakangas <[email protected]>
2023-08-23 14:40 ` Re: Unlogged relations and WAL-logging Heikki Linnakangas <[email protected]>
@ 2023-09-01 12:49 ` Peter Eisentraut <[email protected]>
2023-09-15 14:54 ` Re: Unlogged relations and WAL-logging Heikki Linnakangas <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Peter Eisentraut @ 2023-09-01 12:49 UTC (permalink / raw)
To: Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; +Cc: pgsql-hackers
Is the patch
0003-Remove-unnecessary-smgrimmedsync-when-creating-unlog.patch still
relevant, or can this commitfest entry be closed?
On 23.08.23 16:40, Heikki Linnakangas wrote:
>>>> 5. In heapam_relation_set_new_filenode(), we do this:
>>>>
>>>>>
>>>>> /*
>>>>> * If required, set up an init fork for an unlogged table
>>>>> so that it can
>>>>> * be correctly reinitialized on restart. An immediate
>>>>> sync is required
>>>>> * even if the page has been logged, because the write did
>>>>> not go through
>>>>> * shared_buffers and therefore a concurrent checkpoint may
>>>>> have moved the
>>>>> * redo pointer past our xlog record. Recovery may as well
>>>>> remove it
>>>>> * while replaying, for example, XLOG_DBASE_CREATE or
>>>>> XLOG_TBLSPC_CREATE
>>>>> * record. Therefore, logging is necessary even if
>>>>> wal_level=minimal.
>>>>> */
>>>>> if (persistence == RELPERSISTENCE_UNLOGGED)
>>>>> {
>>>>> Assert(rel->rd_rel->relkind == RELKIND_RELATION ||
>>>>> rel->rd_rel->relkind == RELKIND_MATVIEW ||
>>>>> rel->rd_rel->relkind ==
>>>>> RELKIND_TOASTVALUE);
>>>>> smgrcreate(srel, INIT_FORKNUM, false);
>>>>> log_smgrcreate(newrnode, INIT_FORKNUM);
>>>>> smgrimmedsync(srel, INIT_FORKNUM);
>>>>> }
>>>>
>>>> The comment doesn't make much sense, we haven't written nor WAL-logged
>>>> any page here, with nor without the buffer cache. It made more sense
>>>> before commit fa0f466d53.
>>>
>>> Well, it seems to me (and perhaps I am just confused) that complaining
>>> that there's no page written here might be a technicality. The point
>>> is that there's no synchronization between the work we're doing here
>>> -- which is creating a fork, not writing a page -- and any concurrent
>>> checkpoint. So we both need to log it, and also sync it immediately.
>>
>> I see. I pushed the fix from the other thread that makes smgrcreate()
>> call register_dirty_segment (commit 4b4798e13). I believe that makes
>> this smgrimmedsync() unnecessary. If a concurrent checkpoint happens
>> with a redo pointer greater than this WAL record, it must've received
>> the fsync request created by smgrcreate(). That depends on the fact that
>> we write the WAL record *after* smgrcreate(). Subtle..
>>
>> Hmm, we have a similar smgrimmedsync() call after index build, because
>> we have written pages directly with smgrextend(skipFsync=true). If no
>> checkpoints have occurred during the index build, we could call
>> register_dirty_segment() instead of smgrimmedsync(). That would avoid
>> the fsync() latency when creating an index on an empty or small index.
>>
>> This is all very subtle to get right though. That's why I'd like to
>> invent a new bulk-creation facility that would handle this stuff, and
>> make the callers less error-prone.
>
> Having a more generic and less error-prone bulk-creation mechanism is
> still on my long TODO list..
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Unlogged relations and WAL-logging
2023-07-07 15:21 Re: Unlogged relations and WAL-logging Heikki Linnakangas <[email protected]>
2023-08-23 14:40 ` Re: Unlogged relations and WAL-logging Heikki Linnakangas <[email protected]>
2023-09-01 12:49 ` Re: Unlogged relations and WAL-logging Peter Eisentraut <[email protected]>
@ 2023-09-15 14:54 ` Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Heikki Linnakangas @ 2023-09-15 14:54 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; Robert Haas <[email protected]>; +Cc: pgsql-hackers
On 01/09/2023 15:49, Peter Eisentraut wrote:
> Is the patch
> 0003-Remove-unnecessary-smgrimmedsync-when-creating-unlog.patch still
> relevant, or can this commitfest entry be closed?
Yes. Pushed it now, thanks!
--
Heikki Linnakangas
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2023-09-15 14:54 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-12-09 08:22 [PATCH v3 3/3] Fix timeline-tracking failure while sending a historic timeline Kyotaro Horiguchi <[email protected]>
2023-07-07 15:21 Re: Unlogged relations and WAL-logging Heikki Linnakangas <[email protected]>
2023-08-23 14:40 ` Re: Unlogged relations and WAL-logging Heikki Linnakangas <[email protected]>
2023-09-01 12:49 ` Re: Unlogged relations and WAL-logging Peter Eisentraut <[email protected]>
2023-09-15 14:54 ` Re: Unlogged relations and WAL-logging Heikki Linnakangas <[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