public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 2/5] Allow composite types in bootstrap 7+ messages / 4 participants [nested] [flat]
* [PATCH 2/5] Allow composite types in bootstrap @ 2020-11-17 15:28 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 7+ messages in thread From: Justin Pryzby @ 2020-11-17 15:28 UTC (permalink / raw) --- src/backend/bootstrap/bootstrap.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c index 18eb62ca47..e4fc75ab84 100644 --- a/src/backend/bootstrap/bootstrap.c +++ b/src/backend/bootstrap/bootstrap.c @@ -916,6 +916,7 @@ gettype(char *type) { if (Typ != NIL) { + static bool did_reread PG_USED_FOR_ASSERTS_ONLY = false; /* Already reread pg_types */ ListCell *lc; foreach (lc, Typ) @@ -927,6 +928,33 @@ gettype(char *type) return app->am_oid; } } + + /* + * The type wasn't known; check again to handle composite + * types, added since first populating the array. + */ + + /* + * Once all the types are populated and we handled composite + * types, shouldn't need to do that again. + */ + Assert(!did_reread); + did_reread = true; + + list_free_deep(Typ); + Typ = NULL; + populate_typ_array(); + + /* Need to avoid infinite recursion... */ + foreach (lc, Typ) + { + struct typmap *app = lfirst(lc); + if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0) + { + Ap = app; + return app->am_oid; + } + } } else { -- 2.26.2 --------------614DDB87AFFED893713AC0E9 Content-Type: text/x-patch; charset=UTF-8; name="0003-Extended-statistics-on-expressions-20210304.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0003-Extended-statistics-on-expressions-20210304.patch" ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Regression tests fail with tzdata 2024b @ 2024-09-16 08:33 Sven Klemm <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: Sven Klemm @ 2024-09-16 08:33 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Wolfgang Walther <[email protected]>; [email protected] On Mon, Sep 16, 2024 at 7:09 AM Tom Lane <[email protected]> wrote: > Wolfgang Walther <[email protected]> writes: > > Tom Lane: > >> Also, as a real place to a greater extent > >> than "PST8PDT" is, it's more subject to historical revisionism when > >> somebody turns up evidence of local law having been different than > >> TZDB currently thinks. > > > I now tried all versions of tzdata which we had in tree back to 2018g, > > they all work fine with the same regression test output. 2018g was an > > arbitrary cutoff, I just didn't try any further. > > Yeah, my belly-aching above is just about hypothetical future > instability. In reality, I'm sure America/Los_Angeles is pretty > well researched and so it's unlikely that there will be unexpected > changes in its zone history. > > > In the end, we don't need a default timezone that will never change. > > We do, really. For example, there's a nonzero chance the USA will > cancel DST altogether at some future time. (This would be driven by > politicians who don't remember the last time, but there's no shortage > of those.) That'd likely break some of our test results, and even if > it happened not to, it'd still be bad because we'd probably lose some > coverage of the DST-transition-related code paths in src/timezone/. > So I'd really be way happier with a test timezone that never changes > but does include DST behavior. I thought PST8PDT fit those > requirements pretty well, and I'm annoyed at Eggert for having tossed > it overboard for no benefit whatever. But I don't run tzdb, so > here we are. > > > We just need one that didn't change in a reasonable number of > > releases going backwards. > > We've had this sort of fire-drill before, e.g. commit 8d7af8fbe. > It's no fun, and the potential surface area for unexpected changes > is now much greater than the few tests affected by that change. > > But here we are, so I pushed your patch with a couple of other > cosmetic bits. There are still a couple of references to PST8PDT > in the tree, but they don't appear to care what the actual meaning > of that zone is, so I left them be. > This is an unfortunate change as this will break extensions tests using pg_regress for testing. We run our tests against multiple minor versions and this getting backported means our tests will fail with the next minor pg release. Is there a workaround available to make the timezone for pg_regress configurable without going into every test? Regards, Sven Klemm ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Regression tests fail with tzdata 2024b @ 2024-09-16 15:19 Tom Lane <[email protected]> parent: Sven Klemm <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: Tom Lane @ 2024-09-16 15:19 UTC (permalink / raw) To: Sven Klemm <[email protected]>; +Cc: Wolfgang Walther <[email protected]>; [email protected] Sven Klemm <[email protected]> writes: > This is an unfortunate change as this will break extensions tests using > pg_regress for testing. We run our tests against multiple minor versions > and this getting backported means our tests will fail with the next minor > pg release. Is there a workaround available to make the timezone for > pg_regress configurable without going into every test? Configurable to what? If your test cases are dependent on the historical behavior of PST8PDT, you're out of luck, because that simply isn't available anymore (or won't be once 2024b reaches your platform, anyway). regards, tom lane ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Regression tests fail with tzdata 2024b @ 2024-09-17 05:38 Sven Klemm <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: Sven Klemm @ 2024-09-17 05:38 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Wolfgang Walther <[email protected]>; [email protected] On Mon, Sep 16, 2024 at 5:19 PM Tom Lane <[email protected]> wrote: > Configurable to what? If your test cases are dependent on the > historical behavior of PST8PDT, you're out of luck, because that > simply isn't available anymore (or won't be once 2024b reaches > your platform, anyway). > I was wondering whether the timezone used by pg_regress could be made configurable. -- Regards, Sven Klemm ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Regression tests fail with tzdata 2024b @ 2024-09-17 05:42 Tom Lane <[email protected]> parent: Sven Klemm <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: Tom Lane @ 2024-09-17 05:42 UTC (permalink / raw) To: Sven Klemm <[email protected]>; +Cc: Wolfgang Walther <[email protected]>; [email protected] Sven Klemm <[email protected]> writes: > On Mon, Sep 16, 2024 at 5:19 PM Tom Lane <[email protected]> wrote: >> Configurable to what? If your test cases are dependent on the >> historical behavior of PST8PDT, you're out of luck, because that >> simply isn't available anymore (or won't be once 2024b reaches >> your platform, anyway). > I was wondering whether the timezone used by pg_regress could be made > configurable. Yes, I understood that you were suggesting that. My point is that it wouldn't do you any good: you will still have to change any regression test cases that depend on behavior PST8PDT has/had that is different from America/Los_Angeles. That being the case, I don't see much value in making it configurable. regards, tom lane ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Regression tests fail with tzdata 2024b @ 2024-09-17 06:39 Wolfgang Walther <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 7+ messages in thread From: Wolfgang Walther @ 2024-09-17 06:39 UTC (permalink / raw) To: Tom Lane <[email protected]>; Sven Klemm <[email protected]>; +Cc: [email protected] Tom Lane: >> I was wondering whether the timezone used by pg_regress could be made >> configurable. > > Yes, I understood that you were suggesting that. My point is that > it wouldn't do you any good: you will still have to change any > regression test cases that depend on behavior PST8PDT has/had that > is different from America/Los_Angeles. That being the case, > I don't see much value in making it configurable. Just changing it back to PST8PDT wouldn't really help as Tom pointed out. You'd still get different results depending on which tzdata version you are running with. The core regression tests need to be run with a timezone that tests special cases in the timezone handling code. But that might not be true for extensions - all they want could be a stable output across major and minor versions of postgres and versions of tzdata. It could be helpful to set pg_regress' timezone to UTC, for example? Best, Wolfgang ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Regression tests fail with tzdata 2024b @ 2024-09-17 14:15 Tom Lane <[email protected]> parent: Wolfgang Walther <[email protected]> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-09-17 14:15 UTC (permalink / raw) To: Wolfgang Walther <[email protected]>; +Cc: Sven Klemm <[email protected]>; [email protected] Wolfgang Walther <[email protected]> writes: > The core regression tests need to be run with a timezone that tests > special cases in the timezone handling code. But that might not be true > for extensions - all they want could be a stable output across major and > minor versions of postgres and versions of tzdata. It could be helpful > to set pg_regress' timezone to UTC, for example? I would not recommend that choice. It would mask simple errors such as failing to apply the correct conversion between timestamptz and timestamp values. Also, if you have test cases that are affected by this issue at all, you probably have a need/desire to test things like DST transitions. regards, tom lane ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-09-17 14:15 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-17 15:28 [PATCH 2/5] Allow composite types in bootstrap Justin Pryzby <[email protected]> 2024-09-16 08:33 Re: Regression tests fail with tzdata 2024b Sven Klemm <[email protected]> 2024-09-16 15:19 ` Re: Regression tests fail with tzdata 2024b Tom Lane <[email protected]> 2024-09-17 05:38 ` Re: Regression tests fail with tzdata 2024b Sven Klemm <[email protected]> 2024-09-17 05:42 ` Re: Regression tests fail with tzdata 2024b Tom Lane <[email protected]> 2024-09-17 06:39 ` Re: Regression tests fail with tzdata 2024b Wolfgang Walther <[email protected]> 2024-09-17 14:15 ` Re: Regression tests fail with tzdata 2024b Tom Lane <[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