| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Include replication origins in SQL functions for commit timestam |
| Date: | 2020-07-13 01:53:04 |
| Message-ID: | 20200713015304.GA1868@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
On Sun, Jul 12, 2020 at 09:25:07PM +0900, Michael Paquier wrote:
> longfin has been failing here:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2020-07-12%2011%3A49%3A08
>
> The buildfarm logs include no output, but the problem comes from
> -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, where replication origins
> should be prefixed by "regress_". I did not know that this rule was
> applied here.
Sorry for the delay. jacana has been complaining here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2020-07-12%2018%3A02%3A48
Visily switching to tstzrange() is not a brilliant idea, as I suspect
here that the problem is caused by the timestamp comparison in the
upper bound: using the internal range checks, the upper bound is
excluded, so if the follow-up query's now() matches the commit
timestamp of the previous transaction, the comparison fails.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-07-13 01:57:13 | pgsql: Fix timestamp range handling in regression tests of modules/comm |
| Previous Message | Michael Paquier | 2020-07-12 12:28:59 | pgsql: Fix test failure with -DENFORCE_REGRESSION_TEST_NAME_RESTRICTION |