public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v3 3/3] Fix timeline-tracking failure while sending a historic timeline
3+ 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; 3+ 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] 3+ messages in thread
* Re: New Object Access Type hooks
@ 2022-03-21 15:41 Andrew Dunstan <[email protected]>
2022-03-21 19:58 ` Re: New Object Access Type hooks Mark Dilger <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Dunstan @ 2022-03-21 15:41 UTC (permalink / raw)
To: Mark Dilger <[email protected]>; pgsql-hackers; Joshua Brindle <[email protected]>; +Cc: Robert Haas <[email protected]>; Tom Lane <[email protected]>; Jeff Davis <[email protected]>; Joe Conway <[email protected]>
On 3/17/22 23:21, Mark Dilger wrote:
> Hackers,
>
> Over in [1], Joshua proposed a new set of Object Access Type hooks based on strings rather than Oids.
>
> His patch was written to be applied atop my patch for granting privileges on gucs.
>
> On review of his patch, I became uncomfortable with the complete lack of regression test coverage. To be fair, he did paste a bit of testing logic to the thread, but it appears to be based on pgaudit, and it is unclear how to include such a test in the core project, where pgaudit is not assumed to be installed.
>
> First, I refactored his patch to work against HEAD and not depend on my GUCs patch. Find that as v1-0001. The refactoring exposed a bit of a problem. To call the new hook for SET and ALTER SYSTEM commands, I need to pass in the Oid of a catalog table. But since my GUC patch isn't applied yet, there isn't any such table (pg_setting_acl or whatnot) to pass. So I'm passing InvalidOid, but I don't know if that is right. In any event, if we want a new API like this, we should think a bit harder about whether it can be used to check operations where no table Oid is applicable.
My first inclination is to say it's probably ok. The immediately obvious
alternative would be to create yet another set of functions that don't
have classId parameters. That doesn't seem attractive.
Modulo that issue I think patch 1 is basically ok, but we should fix the
comments in objectaccess.c. Rather than "It is [the] entrypoint ..." we
should have something like "Oid variant entrypoint ..." and "Name
variant entrypoint ...", and also fix the function names in the comments.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: New Object Access Type hooks
2022-03-21 15:41 Re: New Object Access Type hooks Andrew Dunstan <[email protected]>
@ 2022-03-21 19:58 ` Mark Dilger <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Mark Dilger @ 2022-03-21 19:58 UTC (permalink / raw)
To: Joshua Brindle <[email protected]>; +Cc: pgsql-hackers; Robert Haas <[email protected]>; Tom Lane <[email protected]>; Jeff Davis <[email protected]>; Joe Conway <[email protected]>; Andrew Dunstan <[email protected]>
> On Mar 21, 2022, at 8:41 AM, Andrew Dunstan <[email protected]> wrote:
>
> My first inclination is to say it's probably ok. The immediately obvious
> alternative would be to create yet another set of functions that don't
> have classId parameters. That doesn't seem attractive.
>
> Modulo that issue I think patch 1 is basically ok, but we should fix the
> comments in objectaccess.c. Rather than "It is [the] entrypoint ..." we
> should have something like "Oid variant entrypoint ..." and "Name
> variant entrypoint ...", and also fix the function names in the comments.
Joshua,
Do you care to create a new version of this, perhaps based on the v2-0001 patch I just posted?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-03-21 19:58 UTC | newest]
Thread overview: 3+ 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]>
2022-03-21 15:41 Re: New Object Access Type hooks Andrew Dunstan <[email protected]>
2022-03-21 19:58 ` Re: New Object Access Type hooks Mark Dilger <[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