pg_amcheck: Minor test speedups
Freezing the relation N times and fetching the tuples one-by-one isn't that
cheap. On my machine this reduces test times by a bit less than one second, on
windows CI it's a few seconds.
Reviewed-by: Mark Dilger
Discussion:
https://postgr.es/m/20230309001558.b7shz
amcheck: Fix ordering bug in update_cached_xid_range()
The initialization order in update_cached_xid_range() was wrong, calling
FullTransactionIdFromXidAndCtx() before setting
->next_xid. FullTransactionIdFromXidAndCtx() uses ->next_xid.
In most situations this will not cause visible issues, beca
amcheck: Fix FullTransactionIdFromXidAndCtx() for xids before epoch 0
64bit xids can't represent xids before epoch 0 (see also be504a3e974). When
FullTransactionIdFromXidAndCtx() was passed such an xid, it'd create a 64bit
xid far into the future. Noticed while adding assertions in the course of
i
amcheck: Fix FullTransactionIdFromXidAndCtx() for xids before epoch 0
64bit xids can't represent xids before epoch 0 (see also be504a3e974). When
FullTransactionIdFromXidAndCtx() was passed such an xid, it'd create a 64bit
xid far into the future. Noticed while adding assertions in the course of
i
amcheck: Fix ordering bug in update_cached_xid_range()
The initialization order in update_cached_xid_range() was wrong, calling
FullTransactionIdFromXidAndCtx() before setting
->next_xid. FullTransactionIdFromXidAndCtx() uses ->next_xid.
In most situations this will not cause visible issues, beca
amcheck: Fix FullTransactionIdFromXidAndCtx() for xids before epoch 0
64bit xids can't represent xids before epoch 0 (see also be504a3e974). When
FullTransactionIdFromXidAndCtx() was passed such an xid, it'd create a 64bit
xid far into the future. Noticed while adding assertions in the course of
i
amcheck: Fix ordering bug in update_cached_xid_range()
The initialization order in update_cached_xid_range() was wrong, calling
FullTransactionIdFromXidAndCtx() before setting
->next_xid. FullTransactionIdFromXidAndCtx() uses ->next_xid.
In most situations this will not cause visible issues, beca
> On Mar 11, 2023, at 5:05 PM, Andres Freund wrote:
>
> Hi,
>
>> On 2023-03-11 10:20:33 -0800, Jeff Davis wrote:
>> On Sat, 2023-03-11 at 08:31 -0500, Andrew Dunstan wrote:
>>> It's fairly old:
>>>
>>> $ rpm -q -a | grep icu
>>> libicu-50.2-4.0.amzn1.x86_64
>>> libicu-devel-50.2-4.0
Hi,
On 2023-03-11 10:20:33 -0800, Jeff Davis wrote:
> On Sat, 2023-03-11 at 08:31 -0500, Andrew Dunstan wrote:
> > >
> > It's fairly old:
> >
> > $ rpm -q -a | grep icu
> > libicu-50.2-4.0.amzn1.x86_64
> > libicu-devel-50.2-4.0.amzn1.x86_64
>
> FWIW I tried ICU 50.2 (built from sources) and t
meson: fix header path of ossp-uuid
The ossp-uuid pkg-config file includes the necessary -I to include the header
as uuid.h. Previously this would only work if ossp-uuid has its headers in
ossp/ in an already searched path.
Reported-by: Andrew Dunstan
Discussion:
https://postgr.es/m/7bb8b8a5-52
Jeff Davis writes:
> On Sat, 2023-03-11 at 08:31 -0500, Andrew Dunstan wrote:
>> It's fairly old:
>> $ rpm -q -a | grep icu
>> libicu-50.2-4.0.amzn1.x86_64
>> libicu-devel-50.2-4.0.amzn1.x86_64
> FWIW I tried ICU 50.2 (built from sources) and the root locale still
> sorts lowercase first.
snap
On Sat, 2023-03-11 at 08:31 -0500, Andrew Dunstan wrote:
> >
> It's fairly old:
>
> $ rpm -q -a | grep icu
> libicu-50.2-4.0.amzn1.x86_64
> libicu-devel-50.2-4.0.amzn1.x86_64
FWIW I tried ICU 50.2 (built from sources) and the root locale still
sorts lowercase first.
Regards,
Jeff Davi
Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.
If the regex compiler can see that a regex is unsatisfiable
(for example, '$foo') then it may emit an NFA having no arcs.
pg_trgm's packGraph function did the wrong thing in this case;
it would access off the end of a work array, and
Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.
If the regex compiler can see that a regex is unsatisfiable
(for example, '$foo') then it may emit an NFA having no arcs.
pg_trgm's packGraph function did the wrong thing in this case;
it would access off the end of a work array, and
Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.
If the regex compiler can see that a regex is unsatisfiable
(for example, '$foo') then it may emit an NFA having no arcs.
pg_trgm's packGraph function did the wrong thing in this case;
it would access off the end of a work array, and
Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.
If the regex compiler can see that a regex is unsatisfiable
(for example, '$foo') then it may emit an NFA having no arcs.
pg_trgm's packGraph function did the wrong thing in this case;
it would access off the end of a work array, and
Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.
If the regex compiler can see that a regex is unsatisfiable
(for example, '$foo') then it may emit an NFA having no arcs.
pg_trgm's packGraph function did the wrong thing in this case;
it would access off the end of a work array, and
Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.
If the regex compiler can see that a regex is unsatisfiable
(for example, '$foo') then it may emit an NFA having no arcs.
pg_trgm's packGraph function did the wrong thing in this case;
it would access off the end of a work array, and
On 2023-03-10 Fr 14:44, Jeff Davis wrote:
On Fri, 2023-03-10 at 12:42 +, Peter Eisentraut wrote:
Add standard collation UNICODE
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2023-03-10%2018%3A58%3A04
Looks like there's still a failure, even after subsequent fix
3e623ebc
19 matches
Mail list logo
