pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18240: Undefined behaviour in cash_mul_flt8() and friends
24+ messages / 9 participants
[nested] [flat]
Commits from this thread:
2024-07-19 e8dfe0430f 22b0ccd65d 4f96281587 c5321e9651 3764ee47f7 34e9dce69c b82791c8fc Add overflow checks to money type.
2024-01-15 31acee4b66 Reduce dependency to money data type in main regression test suite
* BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-11 06:00 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 24+ messages in thread
From: PG Bug reporting form @ 2023-12-11 06:00 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: exclusion@gmail.com
The following bug has been logged on the website:
Bug reference: 18240
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 16.1
Operating system: Ubuntu 22.04
Description:
The following multiplication:
SELECT 1_000_000_000::money * 1_000_000_000::float8;
gives the incorrect result:
-$92,233,720,368,547,758.08
UBSan detects undefined behaviour:
cash.c:669:11: runtime error: 1e+20 is outside the range of representable
values of type 'long'
#0 0x55d66011b73a in cash_mul_flt8
.../src/backend/utils/adt/cash.c:669:11
The same is observed with float4:
cash.c:719:11: runtime error: 1e+20 is outside the range of representable
values of type 'long'
#0 0x55f2adc46072 in cash_mul_flt4
.../src/backend/utils/adt/cash.c:719:11
And with float8 * money...
Reproduced on REL9_6_0 (but the defect is much older, AFAICS) .. HEAD.
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-11 10:22 Michael Paquier <michael@paquier.xyz>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 24+ messages in thread
From: Michael Paquier @ 2023-12-11 10:22 UTC (permalink / raw)
To: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Mon, Dec 11, 2023 at 06:00:02AM +0000, PG Bug reporting form wrote:
> The following multiplication:
> SELECT 1_000_000_000::money * 1_000_000_000::float8;
>
> gives the incorrect result:
> -$92,233,720,368,547,758.08
Yep, good catch. Reproduced here.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-11 15:05 Tom Lane <tgl@sss.pgh.pa.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 2 replies; 24+ messages in thread
From: Tom Lane @ 2023-12-11 15:05 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Dec 11, 2023 at 06:00:02AM +0000, PG Bug reporting form wrote:
>> The following multiplication:
>> SELECT 1_000_000_000::money * 1_000_000_000::float8;
>> gives the incorrect result:
>> -$92,233,720,368,547,758.08
> Yep, good catch. Reproduced here.
Yeah, approximately none of cash.c pays any attention to the risks
of overflow/underflow. Improving that situation would be a good
finger exercise for some aspiring hacker, perhaps. Although I bet
somebody will ask again why it is that we continue to support the
money type.
regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-12 03:00 Alexander Lakhin <exclusion@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 24+ messages in thread
From: Alexander Lakhin @ 2023-12-12 03:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Michael Paquier <michael@paquier.xyz>; +Cc: pgsql-bugs@lists.postgresql.org
Hello Michael and Tom,
11.12.2023 18:05, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> On Mon, Dec 11, 2023 at 06:00:02AM +0000, PG Bug reporting form wrote:
>>> The following multiplication:
>>> SELECT 1_000_000_000::money * 1_000_000_000::float8;
>>> gives the incorrect result:
>>> -$92,233,720,368,547,758.08
>> Yep, good catch. Reproduced here.
> Yeah, approximately none of cash.c pays any attention to the risks
> of overflow/underflow. Improving that situation would be a good
> finger exercise for some aspiring hacker, perhaps. Although I bet
> somebody will ask again why it is that we continue to support the
> money type.
Thank you for looking at that!
I've tried a simple operator-testing query (with already known problematic
operators spelled out):
SELECT format('SELECT ''2000000000''::%s %s ''2000000000''::%s;',
tl.typname, oprname, tr.typname) FROM pg_operator
INNER JOIN pg_type tl ON tl.oid = oprleft
INNER JOIN pg_type tr ON tr.oid = oprright WHERE (
/* 2000000000 xxx 2000000000 */
NOT(tl.typname = 'money' AND oprname = '*' AND tr.typname = 'float4') AND
NOT(tl.typname = 'float4' AND oprname = '*' AND tr.typname = 'money') AND
NOT(tl.typname = 'money' AND oprname = '*' AND tr.typname = 'float8') AND
NOT(tl.typname = 'float8' AND oprname = '*' AND tr.typname = 'money') AND
NOT(tl.typname = 'int4' AND oprname = '<<' AND tr.typname = 'int4') AND
NOT(tl.typname = 'int4' AND oprname = '>>' AND tr.typname = 'int4') AND
NOT(tl.typname = 'int8' AND oprname = '<<' AND tr.typname = 'int4') AND
NOT(tl.typname = 'int8' AND oprname = '>>' AND tr.typname = 'int4') AND
/* 2000000000 xxx 0.0000000002 */
NOT(tl.typname = 'money' AND oprname = '/' AND tr.typname = 'float4') AND
NOT(tl.typname = 'money' AND oprname = '/' AND tr.typname = 'float8') AND
/* 32767 xxx 32767 */
NOT(tl.typname = 'int2' AND oprname = '<<' AND tr.typname = 'int4') AND
NOT(tl.typname = 'int2' AND oprname = '>>' AND tr.typname = 'int4')
)
\gexec
and found no new UBSan-detected anomalies with "extraordinary" numbers.
Best regards,
Alexander
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-12 09:03 Michael Paquier <michael@paquier.xyz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 24+ messages in thread
From: Michael Paquier @ 2023-12-12 09:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Mon, Dec 11, 2023 at 10:05:53AM -0500, Tom Lane wrote:
> Yeah, approximately none of cash.c pays any attention to the risks
> of overflow/underflow. Improving that situation would be a good
> finger exercise for some aspiring hacker, perhaps. Although I bet
> somebody will ask again why it is that we continue to support the
> money type.
AFAIK, we discourage the use of money in the wiki for quite a few
years:
https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_money
And numeric has much better code coverage and support. I am wondering
whether we've reached the point where it would be better to remove it
entirely from the tree, and just tell people to use numeric. This has
a cost for upgrades, where we should cross check for its use but there
is already check_for_data_type_usage() to do this job so the facility
is there.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-12 10:37 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 0 replies; 24+ messages in thread
From: Bruce Momjian @ 2023-12-12 10:37 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Tue, Dec 12, 2023 at 10:03:43AM +0100, Michael Paquier wrote:
> On Mon, Dec 11, 2023 at 10:05:53AM -0500, Tom Lane wrote:
> > Yeah, approximately none of cash.c pays any attention to the risks
> > of overflow/underflow. Improving that situation would be a good
> > finger exercise for some aspiring hacker, perhaps. Although I bet
> > somebody will ask again why it is that we continue to support the
> > money type.
>
> AFAIK, we discourage the use of money in the wiki for quite a few
> years:
> https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_money
>
> And numeric has much better code coverage and support. I am wondering
> whether we've reached the point where it would be better to remove it
> entirely from the tree, and just tell people to use numeric. This has
> a cost for upgrades, where we should cross check for its use but there
> is already check_for_data_type_usage() to do this job so the facility
> is there.
Yes, probably.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-12 12:01 David Rowley <dgrowleyml@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 1 reply; 24+ messages in thread
From: David Rowley @ 2023-12-12 12:01 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Tue, 12 Dec 2023 at 22:03, Michael Paquier <michael@paquier.xyz> wrote:
> AFAIK, we discourage the use of money in the wiki for quite a few
> years:
> https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_money
>
> And numeric has much better code coverage and support. I am wondering
> whether we've reached the point where it would be better to remove it
> entirely from the tree, and just tell people to use numeric. This has
> a cost for upgrades, where we should cross check for its use but there
> is already check_for_data_type_usage() to do this job so the facility
> is there.
We could extract it into a contrib module.
That might help reduce new usages of it and would also allow people
who have large tables using the money type but can't realistically
wait out a table rewrite to upgrade to a newer version of Postgres.
David
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-12 14:37 Tom Lane <tgl@sss.pgh.pa.us>
parent: David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 24+ messages in thread
From: Tom Lane @ 2023-12-12 14:37 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
David Rowley <dgrowleyml@gmail.com> writes:
> On Tue, 12 Dec 2023 at 22:03, Michael Paquier <michael@paquier.xyz> wrote:
>> And numeric has much better code coverage and support. I am wondering
>> whether we've reached the point where it would be better to remove it
>> entirely from the tree, and just tell people to use numeric.
> We could extract it into a contrib module.
Perhaps, but ...
> That might help reduce new usages of it and would also allow people
> who have large tables using the money type but can't realistically
> wait out a table rewrite to upgrade to a newer version of Postgres.
... I doubt that a contrib module would solve the problem for people
who can't afford a rewrite. pg_upgrade requires that datatype OIDs
stay the same, which is something I don't believe a contrib module
could manage. We've run into that before if memory serves. Is it
time to do something about that? Perhaps we could allow extension
modules to use binary_upgrade_set_next_pg_type_oid, and then somehow
reserve the money and _money OIDs forever?
regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-16 09:19 Michael Paquier <michael@paquier.xyz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 24+ messages in thread
From: Michael Paquier @ 2023-12-16 09:19 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Tue, Dec 12, 2023 at 09:37:58AM -0500, Tom Lane wrote:
> ... I doubt that a contrib module would solve the problem for people
> who can't afford a rewrite. pg_upgrade requires that datatype OIDs
> stay the same, which is something I don't believe a contrib module
> could manage. We've run into that before if memory serves. Is it
> time to do something about that? Perhaps we could allow extension
> modules to use binary_upgrade_set_next_pg_type_oid, and then somehow
> reserve the money and _money OIDs forever?
You mean with an integration in binary dumps? I don't see why it
would not work and this facility may prove to be useful for
out-of-core extension, assuming that this can be made transparent
based on some new .control properties on the upgrade cluster, I
guess..
Now, I am not sure that we're making users a favor in keeping around a
data type that's kind of obsolete these days, particularly when all of
them basically require handling of fractional cents when doing serious
calculations. That's a trap in disguise, even if tying data to a
locale for the unit sounds appealing for some applications.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-16 15:19 Tom Lane <tgl@sss.pgh.pa.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 24+ messages in thread
From: Tom Lane @ 2023-12-16 15:19 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Dec 12, 2023 at 09:37:58AM -0500, Tom Lane wrote:
>> ... Perhaps we could allow extension
>> modules to use binary_upgrade_set_next_pg_type_oid, and then somehow
>> reserve the money and _money OIDs forever?
> Now, I am not sure that we're making users a favor in keeping around a
> data type that's kind of obsolete these days, particularly when all of
> them basically require handling of fractional cents when doing serious
> calculations. That's a trap in disguise, even if tying data to a
> locale for the unit sounds appealing for some applications.
Yeah, I wouldn't propose this if money were the only type we were
thinking of getting rid of; likely not worth the trouble. But I've
got one eye on the geometric types as well --- I think it would be
great all around if we could kick those out of the core distribution
and let them be maintained independently. But I fear we can't do that
without some method whereby pg_upgrade is still possible across the
change.
regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-24 17:16 Jonathan S. Katz <jkatz@postgresql.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 24+ messages in thread
From: Jonathan S. Katz @ 2023-12-24 17:16 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Michael Paquier <michael@paquier.xyz>; +Cc: David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On 12/16/23 10:19 AM, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> On Tue, Dec 12, 2023 at 09:37:58AM -0500, Tom Lane wrote:
>>> ... Perhaps we could allow extension
>>> modules to use binary_upgrade_set_next_pg_type_oid, and then somehow
>>> reserve the money and _money OIDs forever?
>
>> Now, I am not sure that we're making users a favor in keeping around a
>> data type that's kind of obsolete these days, particularly when all of
>> them basically require handling of fractional cents when doing serious
>> calculations. That's a trap in disguise, even if tying data to a
>> locale for the unit sounds appealing for some applications.
>
> Yeah, I wouldn't propose this if money were the only type we were
> thinking of getting rid of; likely not worth the trouble. But I've
> got one eye on the geometric types as well --- I think it would be
> great all around if we could kick those out of the core distribution
> and let them be maintained independently. But I fear we can't do that
> without some method whereby pg_upgrade is still possible across the
> change.
"money" poses a bit more risk than the geometric types (I do want to
come back to geometric types later), and it'd be good if we could make
some headway on removing it. Just this past week I came across a case
where "money" was being discussed as being valid, and had to give the
"it's kinda, sorta deprecated" talk.
I'm of the strong opinion that we should get rid of money. I personally
haven't encountered it in the wild -- I'm sure it's there, but it seems
limited -- and most apps that seriously deal with money will either user
either "numeric" or an integer-based type.
I am sensitive to the upgrade piece, as we don't want someone relying on
that behavior to be indefinitely stuck. But perhaps part of the
deprecation plan is to just keep the casts around[1] for a few releases,
without exposing the type, and prevent new creations of the type? We do
state that "A money value can be cast to numeric without loss of
precision"[1], but I do agree with the concerns on a pg_upgrade
operation being stuck on a costly rewrite operation.
Would it make sense to block an upgrade via pg_upgrade if we detect a
money type unless it's rewritten to a different type? Users should still
be able to user other upgrades methods if need be, and handle the
rewrite during that time.
Jonathan
[1] https://www.postgresql.org/docs/current/datatype-money.html
Attachments:
OpenPGP_signature.asc (application/pgp-signature, 839B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-24 18:21 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jonathan S. Katz <jkatz@postgresql.org>
0 siblings, 2 replies; 24+ messages in thread
From: Tom Lane @ 2023-12-24 18:21 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Michael Paquier <michael@paquier.xyz>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> I'm of the strong opinion that we should get rid of money. I personally
> haven't encountered it in the wild -- I'm sure it's there, but it seems
> limited -- and most apps that seriously deal with money will either user
> either "numeric" or an integer-based type.
Yeah, maybe we should just do it. I was pleasantly surprised by how
little push-back we got from nuking the 32-bit datetime types a few
releases ago; perhaps this one would likewise not have much of a
constituency.
> I am sensitive to the upgrade piece, as we don't want someone relying on
> that behavior to be indefinitely stuck. But perhaps part of the
> deprecation plan is to just keep the casts around[1] for a few releases,
> without exposing the type, and prevent new creations of the type?
I don't really see a way to do that, especially not if we don't want
to put a large amount of effort into it. We can certainly make
pg_upgrade reject "money" columns, and tell people they need to
rewrite those before they upgrade not after.
regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-25 00:52 Michael Paquier <michael@paquier.xyz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 24+ messages in thread
From: Michael Paquier @ 2023-12-25 00:52 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jonathan S. Katz <jkatz@postgresql.org>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Sun, Dec 24, 2023 at 01:21:15PM -0500, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> I'm of the strong opinion that we should get rid of money. I personally
>> haven't encountered it in the wild -- I'm sure it's there, but it seems
>> limited -- and most apps that seriously deal with money will either user
>> either "numeric" or an integer-based type.
>
> Yeah, maybe we should just do it. I was pleasantly surprised by how
> little push-back we got from nuking the 32-bit datetime types a few
> releases ago; perhaps this one would likewise not have much of a
> constituency.
Yeah, that's hard to say. Perhaps it would a good idea to ask more
widely how much people have been relying on that and how large these
data sets are. Another thing that we could attempt is doing something
about the the table rewrites on type changes to require an EOL. Like
more CONCURRENTLY flavors in ALTER TABLE?
>> I am sensitive to the upgrade piece, as we don't want someone relying on
>> that behavior to be indefinitely stuck. But perhaps part of the
>> deprecation plan is to just keep the casts around[1] for a few releases,
>> without exposing the type, and prevent new creations of the type?
>
> I don't really see a way to do that, especially not if we don't want
> to put a large amount of effort into it. We can certainly make
> pg_upgrade reject "money" columns, and tell people they need to
> rewrite those before they upgrade not after.
At least the infra to be able to achieve that should be here.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-25 01:09 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 24+ messages in thread
From: Laurenz Albe @ 2023-12-25 01:09 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Michael Paquier <michael@paquier.xyz>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Sun, 2023-12-24 at 13:21 -0500, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
> > I'm of the strong opinion that we should get rid of money. I personally
> > haven't encountered it in the wild -- I'm sure it's there, but it seems
> > limited -- and most apps that seriously deal with money will either user
> > either "numeric" or an integer-based type.
>
> Yeah, maybe we should just do it. I was pleasantly surprised by how
> little push-back we got from nuking the 32-bit datetime types a few
> releases ago; perhaps this one would likewise not have much of a
> constituency.
There are questions on Stackoverflow:
https://stackoverflow.com/search?q=%5Bpostgresql%5D+money
But of course it is hard to say if these are production uses or just
experiments.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-25 09:57 Michael Paquier <michael@paquier.xyz>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 24+ messages in thread
From: Michael Paquier @ 2023-12-25 09:57 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jonathan S. Katz <jkatz@postgresql.org>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Mon, Dec 25, 2023 at 09:52:53AM +0900, Michael Paquier wrote:
> At least the infra to be able to achieve that should be here.
Looking at that, I can see that Peter has added a few tests to test
the predictability of plans generated with non-hashable types, and
that these are based on money. See 6dd8b0080787.
One possible pick to replace money for these tests is tsvector, that
cannot be hashed and has an equality operator. Perhaps these had
better be replaced anyway?
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2023-12-25 15:58 Tom Lane <tgl@sss.pgh.pa.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 24+ messages in thread
From: Tom Lane @ 2023-12-25 15:58 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Jonathan S. Katz <jkatz@postgresql.org>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Michael Paquier <michael@paquier.xyz> writes:
> Looking at that, I can see that Peter has added a few tests to test
> the predictability of plans generated with non-hashable types, and
> that these are based on money. See 6dd8b0080787.
> One possible pick to replace money for these tests is tsvector, that
> cannot be hashed and has an equality operator. Perhaps these had
> better be replaced anyway?
Hm. A quick check in pg_opclass shows that these are the types that
currently have btree but not hash opclasses:
# select ob.opcintype::regtype from (select * from pg_opclass where opcmethod = 403) ob
left join (select * from pg_opclass where opcmethod = 405) oh using(opcintype) where oh.opcintype is null;
opcintype
-------------
bit
bit varying
money
tsvector
tsquery
(5 rows)
I'm a little nervous about using tsvector or tsquery, as it seems
pretty plausible that somebody would get around to making hash
support for them someday. Perhaps the same argument could be made
about bit or varbit, but I'd bet a lot less on that happening,
as those are backwater-ish types (not even in the standard
anymore, IIRC). So I'd think about using one of those.
Or we could build a for-test-purposes-only datatype, but that
could require a lot of scaffolding work.
regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2024-01-11 01:12 Michael Paquier <michael@paquier.xyz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 24+ messages in thread
From: Michael Paquier @ 2024-01-11 01:12 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jonathan S. Katz <jkatz@postgresql.org>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Mon, Dec 25, 2023 at 10:58:59AM -0500, Tom Lane wrote:
> I'm a little nervous about using tsvector or tsquery, as it seems
> pretty plausible that somebody would get around to making hash
> support for them someday. Perhaps the same argument could be made
> about bit or varbit, but I'd bet a lot less on that happening,
> as those are backwater-ish types (not even in the standard
> anymore, IIRC). So I'd think about using one of those.
Okay, I've used varbit then.
> Or we could build a for-test-purposes-only datatype, but that
> could require a lot of scaffolding work.
It took me some time to come back to this thread, apologies for the
delay.
I have been looking at all that, and finished for now with the
attached patch that removes the dependency to "money" in the main
regression test suite in all the relevant places without losing
coverage, switching these to use varbit (well, mostly):
- Tests for hashing and hash-based plans (6dd8b0080787).
- A set of tests in rules used money historically but these can be
switched to numeric.
- Two tests in stats_ext relied on cash_words() to generate different
strings, but the same variance can be achieved without it.
- One test in create_table relied on money as its cast is not
immutable. Here it is possible to use a timestamptz to achieve the
same, with something like to_date() to force a function execution
when defining a partition boundary for one of the partitions (from
7c079d7417a8).
With this patch, the tests related to money that remain are for
type_sanity, window.sql and of course money which are all related to
the data type so they could be wiped out once the type is itself
removed.
While looking at the whole picture, an issue with the direct removal
of money is how we should handle btree_gin and btree_gist which have
operators based on money. We try to keep things compatible at
run-time, but could this be worth a hard break in these modules,
dropping the older sql scripts used in the modules if we don't have
access to money anymore at runtime? These are not popular modules..
Any thoughts about that?
For now, please find attached a patch to adjust the regression tests
to depend less on money, which does not depend on the type removal.
Comments are welcome.
--
Michael
Attachments:
0001-Reduce-dependency-to-money-type-in-regression-tests.patch (text/x-diff, 30.2K) download
From a62b6f731a1c876f172283573f15dc72a572d508 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@paquier.xyz>
Date: Thu, 11 Jan 2024 09:51:20 +0900
Subject: [PATCH] Reduce dependency to money type in regression tests
Most of these tests have been introduced in 6dd8b0080787. Some other
tests historically used money but don't really need it for what they
wanted to test. Plans and coverage is unchanged.
---
src/test/regress/expected/create_table.out | 13 +--
src/test/regress/expected/hash_func.out | 18 ++--
src/test/regress/expected/multirangetypes.out | 8 +-
src/test/regress/expected/rangetypes.out | 10 +-
src/test/regress/expected/rules.out | 98 +++++++++----------
src/test/regress/expected/stats_ext.out | 4 +-
src/test/regress/expected/union.out | 48 ++++-----
src/test/regress/expected/with.out | 6 +-
src/test/regress/sql/create_table.sql | 13 +--
src/test/regress/sql/hash_func.sql | 10 +-
src/test/regress/sql/multirangetypes.sql | 2 +-
src/test/regress/sql/rangetypes.sql | 4 +-
src/test/regress/sql/rules.sql | 6 +-
src/test/regress/sql/stats_ext.sql | 4 +-
src/test/regress/sql/union.sql | 18 ++--
src/test/regress/sql/with.sql | 6 +-
16 files changed, 135 insertions(+), 133 deletions(-)
diff --git a/src/test/regress/expected/create_table.out b/src/test/regress/expected/create_table.out
index 344d05233a..7828a46095 100644
--- a/src/test/regress/expected/create_table.out
+++ b/src/test/regress/expected/create_table.out
@@ -474,13 +474,14 @@ LINE 1: ...REATE TABLE bools_true PARTITION OF bools FOR VALUES IN (1);
^
DROP TABLE bools;
-- specified literal can be cast, and the cast might not be immutable
-CREATE TABLE moneyp (
- a money
+CREATE TABLE castablep (
+ a timestamptz
) PARTITION BY LIST (a);
-CREATE TABLE moneyp_10 PARTITION OF moneyp FOR VALUES IN (10);
-CREATE TABLE moneyp_11 PARTITION OF moneyp FOR VALUES IN ('11');
-CREATE TABLE moneyp_12 PARTITION OF moneyp FOR VALUES IN (to_char(12, '99')::int);
-DROP TABLE moneyp;
+CREATE TABLE castablep_1 PARTITION OF castablep
+ FOR VALUES IN ('2014-01-01 01:00:00');
+CREATE TABLE castablep_2 PARTITION OF castablep
+ FOR VALUES IN (to_date('2014', 'yyyy-mm-dd')::timestamptz);
+DROP TABLE castablep;
-- cast is immutable
CREATE TABLE bigintp (
a bigint
diff --git a/src/test/regress/expected/hash_func.out b/src/test/regress/expected/hash_func.out
index 8e23dc3978..2d625a247b 100644
--- a/src/test/regress/expected/hash_func.out
+++ b/src/test/regress/expected/hash_func.out
@@ -179,11 +179,11 @@ WHERE hash_array(v)::bit(32) != hash_array_extended(v, 0)::bit(32)
-- array hashing with non-hashable element type
SELECT v as value, hash_array(v)::bit(32) as standard
-FROM (VALUES ('{0}'::money[])) x(v);
-ERROR: could not identify a hash function for type money
+FROM (VALUES ('{101}'::varbit[])) x(v);
+ERROR: could not identify a hash function for type bit varying
SELECT v as value, hash_array_extended(v, 0)::bit(32) as extended0
-FROM (VALUES ('{0}'::money[])) x(v);
-ERROR: could not identify an extended hash function for type money
+FROM (VALUES ('{101}'::varbit[])) x(v);
+ERROR: could not identify an extended hash function for type bit varying
SELECT v as value, hashbpchar(v)::bit(32) as standard,
hashbpcharextended(v, 0)::bit(32) as extended0,
hashbpcharextended(v, 1)::bit(32) as extended1
@@ -331,13 +331,13 @@ WHERE hash_record(v)::bit(32) != hash_record_extended(v, 0)::bit(32)
DROP TYPE hash_test_t1;
-- record hashing with non-hashable field type
-CREATE TYPE hash_test_t2 AS (a money, b text);
+CREATE TYPE hash_test_t2 AS (a varbit, b text);
SELECT v as value, hash_record(v)::bit(32) as standard
-FROM (VALUES (row(1, 'aaa')::hash_test_t2)) x(v);
-ERROR: could not identify a hash function for type money
+FROM (VALUES (row('10'::varbit, 'aaa')::hash_test_t2)) x(v);
+ERROR: could not identify a hash function for type bit varying
SELECT v as value, hash_record_extended(v, 0)::bit(32) as extended0
-FROM (VALUES (row(1, 'aaa')::hash_test_t2)) x(v);
-ERROR: could not identify an extended hash function for type money
+FROM (VALUES (row('11'::varbit, 'aaa')::hash_test_t2)) x(v);
+ERROR: could not identify an extended hash function for type bit varying
DROP TYPE hash_test_t2;
--
-- Check special cases for specific data types
diff --git a/src/test/regress/expected/multirangetypes.out b/src/test/regress/expected/multirangetypes.out
index a0cb875492..9808587532 100644
--- a/src/test/regress/expected/multirangetypes.out
+++ b/src/test/regress/expected/multirangetypes.out
@@ -3273,10 +3273,10 @@ NOTICE: drop cascades to type two_ints_range
-- Check behavior when subtype lacks a hash function
--
set enable_sort = off; -- try to make it pick a hash setop implementation
-select '{(2,5)}'::cashmultirange except select '{(5,6)}'::cashmultirange;
- cashmultirange
------------------
- {($2.00,$5.00)}
+select '{(01,10)}'::varbitmultirange except select '{(10,11)}'::varbitmultirange;
+ varbitmultirange
+------------------
+ {(01,10)}
(1 row)
reset enable_sort;
diff --git a/src/test/regress/expected/rangetypes.out b/src/test/regress/expected/rangetypes.out
index ee02ff0163..07d5621ef8 100644
--- a/src/test/regress/expected/rangetypes.out
+++ b/src/test/regress/expected/rangetypes.out
@@ -1761,12 +1761,12 @@ NOTICE: drop cascades to type two_ints_range
--
-- Check behavior when subtype lacks a hash function
--
-create type cashrange as range (subtype = money);
+create type varbitrange as range (subtype = varbit);
set enable_sort = off; -- try to make it pick a hash setop implementation
-select '(2,5)'::cashrange except select '(5,6)'::cashrange;
- cashrange
----------------
- ($2.00,$5.00)
+select '(01,10)'::varbitrange except select '(10,11)'::varbitrange;
+ varbitrange
+-------------
+ (01,10)
(1 row)
reset enable_sort;
diff --git a/src/test/regress/expected/rules.out b/src/test/regress/expected/rules.out
index d878a971df..55f2e95352 100644
--- a/src/test/regress/expected/rules.out
+++ b/src/test/regress/expected/rules.out
@@ -51,9 +51,9 @@ create rule rtest_pers_del as on delete to rtest_person do also
--
-- Tables and rules for the logging test
--
-create table rtest_emp (ename char(20), salary money);
-create table rtest_emplog (ename char(20), who name, action char(10), newsal money, oldsal money);
-create table rtest_empmass (ename char(20), salary money);
+create table rtest_emp (ename char(20), salary numeric);
+create table rtest_emplog (ename char(20), who name, action char(10), newsal numeric, oldsal numeric);
+create table rtest_empmass (ename char(20), salary numeric);
create rule rtest_emp_ins as on insert to rtest_emp do
insert into rtest_emplog values (new.ename, current_user,
'hired', new.salary, '0.00');
@@ -410,13 +410,13 @@ update rtest_emp set ename = 'wieck', salary = '6000.00' where ename = 'wiecx';
update rtest_emp set salary = '7000.00' where ename = 'wieck';
delete from rtest_emp where ename = 'gates';
select ename, who = current_user as "matches user", action, newsal, oldsal from rtest_emplog order by ename, action, newsal;
- ename | matches user | action | newsal | oldsal
-----------------------+--------------+------------+------------+------------
- gates | t | fired | $0.00 | $80,000.00
- gates | t | hired | $80,000.00 | $0.00
- wiecc | t | hired | $5,000.00 | $0.00
- wieck | t | honored | $6,000.00 | $5,000.00
- wieck | t | honored | $7,000.00 | $6,000.00
+ ename | matches user | action | newsal | oldsal
+----------------------+--------------+------------+----------+----------
+ gates | t | fired | 0.00 | 80000.00
+ gates | t | hired | 80000.00 | 0.00
+ wiecc | t | hired | 5000.00 | 0.00
+ wieck | t | honored | 6000.00 | 5000.00
+ wieck | t | honored | 7000.00 | 6000.00
(5 rows)
insert into rtest_empmass values ('meyer', '4000.00');
@@ -424,54 +424,54 @@ insert into rtest_empmass values ('maier', '5000.00');
insert into rtest_empmass values ('mayr', '6000.00');
insert into rtest_emp select * from rtest_empmass;
select ename, who = current_user as "matches user", action, newsal, oldsal from rtest_emplog order by ename, action, newsal;
- ename | matches user | action | newsal | oldsal
-----------------------+--------------+------------+------------+------------
- gates | t | fired | $0.00 | $80,000.00
- gates | t | hired | $80,000.00 | $0.00
- maier | t | hired | $5,000.00 | $0.00
- mayr | t | hired | $6,000.00 | $0.00
- meyer | t | hired | $4,000.00 | $0.00
- wiecc | t | hired | $5,000.00 | $0.00
- wieck | t | honored | $6,000.00 | $5,000.00
- wieck | t | honored | $7,000.00 | $6,000.00
+ ename | matches user | action | newsal | oldsal
+----------------------+--------------+------------+----------+----------
+ gates | t | fired | 0.00 | 80000.00
+ gates | t | hired | 80000.00 | 0.00
+ maier | t | hired | 5000.00 | 0.00
+ mayr | t | hired | 6000.00 | 0.00
+ meyer | t | hired | 4000.00 | 0.00
+ wiecc | t | hired | 5000.00 | 0.00
+ wieck | t | honored | 6000.00 | 5000.00
+ wieck | t | honored | 7000.00 | 6000.00
(8 rows)
update rtest_empmass set salary = salary + '1000.00';
update rtest_emp set salary = rtest_empmass.salary from rtest_empmass where rtest_emp.ename = rtest_empmass.ename;
select ename, who = current_user as "matches user", action, newsal, oldsal from rtest_emplog order by ename, action, newsal;
- ename | matches user | action | newsal | oldsal
-----------------------+--------------+------------+------------+------------
- gates | t | fired | $0.00 | $80,000.00
- gates | t | hired | $80,000.00 | $0.00
- maier | t | hired | $5,000.00 | $0.00
- maier | t | honored | $6,000.00 | $5,000.00
- mayr | t | hired | $6,000.00 | $0.00
- mayr | t | honored | $7,000.00 | $6,000.00
- meyer | t | hired | $4,000.00 | $0.00
- meyer | t | honored | $5,000.00 | $4,000.00
- wiecc | t | hired | $5,000.00 | $0.00
- wieck | t | honored | $6,000.00 | $5,000.00
- wieck | t | honored | $7,000.00 | $6,000.00
+ ename | matches user | action | newsal | oldsal
+----------------------+--------------+------------+----------+----------
+ gates | t | fired | 0.00 | 80000.00
+ gates | t | hired | 80000.00 | 0.00
+ maier | t | hired | 5000.00 | 0.00
+ maier | t | honored | 6000.00 | 5000.00
+ mayr | t | hired | 6000.00 | 0.00
+ mayr | t | honored | 7000.00 | 6000.00
+ meyer | t | hired | 4000.00 | 0.00
+ meyer | t | honored | 5000.00 | 4000.00
+ wiecc | t | hired | 5000.00 | 0.00
+ wieck | t | honored | 6000.00 | 5000.00
+ wieck | t | honored | 7000.00 | 6000.00
(11 rows)
delete from rtest_emp using rtest_empmass where rtest_emp.ename = rtest_empmass.ename;
select ename, who = current_user as "matches user", action, newsal, oldsal from rtest_emplog order by ename, action, newsal;
- ename | matches user | action | newsal | oldsal
-----------------------+--------------+------------+------------+------------
- gates | t | fired | $0.00 | $80,000.00
- gates | t | hired | $80,000.00 | $0.00
- maier | t | fired | $0.00 | $6,000.00
- maier | t | hired | $5,000.00 | $0.00
- maier | t | honored | $6,000.00 | $5,000.00
- mayr | t | fired | $0.00 | $7,000.00
- mayr | t | hired | $6,000.00 | $0.00
- mayr | t | honored | $7,000.00 | $6,000.00
- meyer | t | fired | $0.00 | $5,000.00
- meyer | t | hired | $4,000.00 | $0.00
- meyer | t | honored | $5,000.00 | $4,000.00
- wiecc | t | hired | $5,000.00 | $0.00
- wieck | t | honored | $6,000.00 | $5,000.00
- wieck | t | honored | $7,000.00 | $6,000.00
+ ename | matches user | action | newsal | oldsal
+----------------------+--------------+------------+----------+----------
+ gates | t | fired | 0.00 | 80000.00
+ gates | t | hired | 80000.00 | 0.00
+ maier | t | fired | 0.00 | 6000.00
+ maier | t | hired | 5000.00 | 0.00
+ maier | t | honored | 6000.00 | 5000.00
+ mayr | t | fired | 0.00 | 7000.00
+ mayr | t | hired | 6000.00 | 0.00
+ mayr | t | honored | 7000.00 | 6000.00
+ meyer | t | fired | 0.00 | 5000.00
+ meyer | t | hired | 4000.00 | 0.00
+ meyer | t | honored | 5000.00 | 4000.00
+ wiecc | t | hired | 5000.00 | 0.00
+ wieck | t | honored | 6000.00 | 5000.00
+ wieck | t | honored | 7000.00 | 6000.00
(14 rows)
--
diff --git a/src/test/regress/expected/stats_ext.out b/src/test/regress/expected/stats_ext.out
index a430153b22..10903bdab0 100644
--- a/src/test/regress/expected/stats_ext.out
+++ b/src/test/regress/expected/stats_ext.out
@@ -359,7 +359,7 @@ CREATE TABLE ndistinct (
WITH (autovacuum_enabled = off);
-- over-estimates when using only per-column statistics
INSERT INTO ndistinct (a, b, c, filler1)
- SELECT i/100, i/100, i/100, cash_words((i/100)::money)
+ SELECT i/100, i/100, i/100, (i/100) || ' dollars and zero cents'
FROM generate_series(1,1000) s(i);
ANALYZE ndistinct;
-- Group Aggregate, due to over-estimate of the number of groups
@@ -499,7 +499,7 @@ TRUNCATE TABLE ndistinct;
-- under-estimates when using only per-column statistics
INSERT INTO ndistinct (a, b, c, filler1)
SELECT mod(i,13), mod(i,17), mod(i,19),
- cash_words(mod(i,23)::int::money)
+ mod(i,23) || ' dollars and zero cents'
FROM generate_series(1,1000) s(i);
ANALYZE ndistinct;
SELECT s.stxkind, d.stxdndistinct
diff --git a/src/test/regress/expected/union.out b/src/test/regress/expected/union.out
index 64cebe4833..73e320bad4 100644
--- a/src/test/regress/expected/union.out
+++ b/src/test/regress/expected/union.out
@@ -479,7 +479,7 @@ reset enable_hashagg;
-- non-hashable type
set enable_hashagg to on;
explain (costs off)
-select x from (values (100::money), (200::money)) _(x) union select x from (values (100::money), (300::money)) _(x);
+select x from (values ('11'::varbit), ('10'::varbit)) _(x) union select x from (values ('11'::varbit), ('10'::varbit)) _(x);
QUERY PLAN
-----------------------------------------------
Unique
@@ -492,7 +492,7 @@ select x from (values (100::money), (200::money)) _(x) union select x from (valu
set enable_hashagg to off;
explain (costs off)
-select x from (values (100::money), (200::money)) _(x) union select x from (values (100::money), (300::money)) _(x);
+select x from (values ('11'::varbit), ('10'::varbit)) _(x) union select x from (values ('11'::varbit), ('10'::varbit)) _(x);
QUERY PLAN
-----------------------------------------------
Unique
@@ -563,7 +563,7 @@ select x from (values (array[1, 2]), (array[1, 3])) _(x) except select x from (v
-- non-hashable type
explain (costs off)
-select x from (values (array[100::money]), (array[200::money])) _(x) union select x from (values (array[100::money]), (array[300::money])) _(x);
+select x from (values (array['10'::varbit]), (array['11'::varbit])) _(x) union select x from (values (array['10'::varbit]), (array['01'::varbit])) _(x);
QUERY PLAN
-----------------------------------------------
Unique
@@ -574,12 +574,12 @@ select x from (values (array[100::money]), (array[200::money])) _(x) union selec
-> Values Scan on "*VALUES*_1"
(6 rows)
-select x from (values (array[100::money]), (array[200::money])) _(x) union select x from (values (array[100::money]), (array[300::money])) _(x);
- x
------------
- {$100.00}
- {$200.00}
- {$300.00}
+select x from (values (array['10'::varbit]), (array['11'::varbit])) _(x) union select x from (values (array['10'::varbit]), (array['01'::varbit])) _(x);
+ x
+------
+ {01}
+ {10}
+ {11}
(3 rows)
set enable_hashagg to off;
@@ -710,7 +710,7 @@ select x from (values (row(1, 2)), (row(1, 3))) _(x) except select x from (value
-- With an anonymous row type, the typcache does not report that the
-- type is hashable. (Otherwise, this would fail at execution time.)
explain (costs off)
-select x from (values (row(100::money)), (row(200::money))) _(x) union select x from (values (row(100::money)), (row(300::money))) _(x);
+select x from (values (row('10'::varbit)), (row('11'::varbit))) _(x) union select x from (values (row('10'::varbit)), (row('01'::varbit))) _(x);
QUERY PLAN
-----------------------------------------------
Unique
@@ -721,19 +721,19 @@ select x from (values (row(100::money)), (row(200::money))) _(x) union select x
-> Values Scan on "*VALUES*_1"
(6 rows)
-select x from (values (row(100::money)), (row(200::money))) _(x) union select x from (values (row(100::money)), (row(300::money))) _(x);
- x
------------
- ($100.00)
- ($200.00)
- ($300.00)
+select x from (values (row('10'::varbit)), (row('11'::varbit))) _(x) union select x from (values (row('10'::varbit)), (row('01'::varbit))) _(x);
+ x
+------
+ (01)
+ (10)
+ (11)
(3 rows)
-- With a defined row type, the typcache can inspect the type's fields
-- for hashability.
-create type ct1 as (f1 money);
+create type ct1 as (f1 varbit);
explain (costs off)
-select x from (values (row(100::money)::ct1), (row(200::money)::ct1)) _(x) union select x from (values (row(100::money)::ct1), (row(300::money)::ct1)) _(x);
+select x from (values (row('10'::varbit)::ct1), (row('11'::varbit)::ct1)) _(x) union select x from (values (row('10'::varbit)::ct1), (row('01'::varbit)::ct1)) _(x);
QUERY PLAN
-----------------------------------------------
Unique
@@ -744,12 +744,12 @@ select x from (values (row(100::money)::ct1), (row(200::money)::ct1)) _(x) union
-> Values Scan on "*VALUES*_1"
(6 rows)
-select x from (values (row(100::money)::ct1), (row(200::money)::ct1)) _(x) union select x from (values (row(100::money)::ct1), (row(300::money)::ct1)) _(x);
- x
------------
- ($100.00)
- ($200.00)
- ($300.00)
+select x from (values (row('10'::varbit)::ct1), (row('11'::varbit)::ct1)) _(x) union select x from (values (row('10'::varbit)::ct1), (row('01'::varbit)::ct1)) _(x);
+ x
+------
+ (01)
+ (10)
+ (11)
(3 rows)
drop type ct1;
diff --git a/src/test/regress/expected/with.out b/src/test/regress/expected/with.out
index 3cf969d938..7d796ea69c 100644
--- a/src/test/regress/expected/with.out
+++ b/src/test/regress/expected/with.out
@@ -51,11 +51,11 @@ SELECT * FROM t;
-- UNION DISTINCT requires hashable type
WITH RECURSIVE t(n) AS (
- VALUES (1::money)
+ VALUES ('01'::varbit)
UNION
- SELECT n+1::money FROM t WHERE n < 100::money
+ SELECT n || '10'::varbit FROM t WHERE n < '100'::varbit
)
-SELECT sum(n) FROM t;
+SELECT n FROM t;
ERROR: could not implement recursive UNION
DETAIL: All column datatypes must be hashable.
-- recursive view
diff --git a/src/test/regress/sql/create_table.sql b/src/test/regress/sql/create_table.sql
index 1fd4cbfa7e..7a3761bb8d 100644
--- a/src/test/regress/sql/create_table.sql
+++ b/src/test/regress/sql/create_table.sql
@@ -322,13 +322,14 @@ CREATE TABLE bools_true PARTITION OF bools FOR VALUES IN (1);
DROP TABLE bools;
-- specified literal can be cast, and the cast might not be immutable
-CREATE TABLE moneyp (
- a money
+CREATE TABLE castablep (
+ a timestamptz
) PARTITION BY LIST (a);
-CREATE TABLE moneyp_10 PARTITION OF moneyp FOR VALUES IN (10);
-CREATE TABLE moneyp_11 PARTITION OF moneyp FOR VALUES IN ('11');
-CREATE TABLE moneyp_12 PARTITION OF moneyp FOR VALUES IN (to_char(12, '99')::int);
-DROP TABLE moneyp;
+CREATE TABLE castablep_1 PARTITION OF castablep
+ FOR VALUES IN ('2014-01-01 01:00:00');
+CREATE TABLE castablep_2 PARTITION OF castablep
+ FOR VALUES IN (to_date('2014', 'yyyy-mm-dd')::timestamptz);
+DROP TABLE castablep;
-- cast is immutable
CREATE TABLE bigintp (
diff --git a/src/test/regress/sql/hash_func.sql b/src/test/regress/sql/hash_func.sql
index 5ad33c1f9d..33756bd288 100644
--- a/src/test/regress/sql/hash_func.sql
+++ b/src/test/regress/sql/hash_func.sql
@@ -132,9 +132,9 @@ WHERE hash_array(v)::bit(32) != hash_array_extended(v, 0)::bit(32)
-- array hashing with non-hashable element type
SELECT v as value, hash_array(v)::bit(32) as standard
-FROM (VALUES ('{0}'::money[])) x(v);
+FROM (VALUES ('{101}'::varbit[])) x(v);
SELECT v as value, hash_array_extended(v, 0)::bit(32) as extended0
-FROM (VALUES ('{0}'::money[])) x(v);
+FROM (VALUES ('{101}'::varbit[])) x(v);
SELECT v as value, hashbpchar(v)::bit(32) as standard,
hashbpcharextended(v, 0)::bit(32) as extended0,
@@ -247,11 +247,11 @@ WHERE hash_record(v)::bit(32) != hash_record_extended(v, 0)::bit(32)
DROP TYPE hash_test_t1;
-- record hashing with non-hashable field type
-CREATE TYPE hash_test_t2 AS (a money, b text);
+CREATE TYPE hash_test_t2 AS (a varbit, b text);
SELECT v as value, hash_record(v)::bit(32) as standard
-FROM (VALUES (row(1, 'aaa')::hash_test_t2)) x(v);
+FROM (VALUES (row('10'::varbit, 'aaa')::hash_test_t2)) x(v);
SELECT v as value, hash_record_extended(v, 0)::bit(32) as extended0
-FROM (VALUES (row(1, 'aaa')::hash_test_t2)) x(v);
+FROM (VALUES (row('11'::varbit, 'aaa')::hash_test_t2)) x(v);
DROP TYPE hash_test_t2;
--
diff --git a/src/test/regress/sql/multirangetypes.sql b/src/test/regress/sql/multirangetypes.sql
index fefb4b4d42..cadf312031 100644
--- a/src/test/regress/sql/multirangetypes.sql
+++ b/src/test/regress/sql/multirangetypes.sql
@@ -802,7 +802,7 @@ drop type two_ints cascade;
set enable_sort = off; -- try to make it pick a hash setop implementation
-select '{(2,5)}'::cashmultirange except select '{(5,6)}'::cashmultirange;
+select '{(01,10)}'::varbitmultirange except select '{(10,11)}'::varbitmultirange;
reset enable_sort;
diff --git a/src/test/regress/sql/rangetypes.sql b/src/test/regress/sql/rangetypes.sql
index c23be928c3..c5dbe0c04f 100644
--- a/src/test/regress/sql/rangetypes.sql
+++ b/src/test/regress/sql/rangetypes.sql
@@ -575,11 +575,11 @@ drop type two_ints cascade;
-- Check behavior when subtype lacks a hash function
--
-create type cashrange as range (subtype = money);
+create type varbitrange as range (subtype = varbit);
set enable_sort = off; -- try to make it pick a hash setop implementation
-select '(2,5)'::cashrange except select '(5,6)'::cashrange;
+select '(01,10)'::varbitrange except select '(10,11)'::varbitrange;
reset enable_sort;
diff --git a/src/test/regress/sql/rules.sql b/src/test/regress/sql/rules.sql
index 8b7e255dcd..93aff4e66f 100644
--- a/src/test/regress/sql/rules.sql
+++ b/src/test/regress/sql/rules.sql
@@ -57,9 +57,9 @@ create rule rtest_pers_del as on delete to rtest_person do also
--
-- Tables and rules for the logging test
--
-create table rtest_emp (ename char(20), salary money);
-create table rtest_emplog (ename char(20), who name, action char(10), newsal money, oldsal money);
-create table rtest_empmass (ename char(20), salary money);
+create table rtest_emp (ename char(20), salary numeric);
+create table rtest_emplog (ename char(20), who name, action char(10), newsal numeric, oldsal numeric);
+create table rtest_empmass (ename char(20), salary numeric);
create rule rtest_emp_ins as on insert to rtest_emp do
insert into rtest_emplog values (new.ename, current_user,
diff --git a/src/test/regress/sql/stats_ext.sql b/src/test/regress/sql/stats_ext.sql
index 90b625a5a2..42cb7dd97d 100644
--- a/src/test/regress/sql/stats_ext.sql
+++ b/src/test/regress/sql/stats_ext.sql
@@ -234,7 +234,7 @@ WITH (autovacuum_enabled = off);
-- over-estimates when using only per-column statistics
INSERT INTO ndistinct (a, b, c, filler1)
- SELECT i/100, i/100, i/100, cash_words((i/100)::money)
+ SELECT i/100, i/100, i/100, (i/100) || ' dollars and zero cents'
FROM generate_series(1,1000) s(i);
ANALYZE ndistinct;
@@ -299,7 +299,7 @@ TRUNCATE TABLE ndistinct;
-- under-estimates when using only per-column statistics
INSERT INTO ndistinct (a, b, c, filler1)
SELECT mod(i,13), mod(i,17), mod(i,19),
- cash_words(mod(i,23)::int::money)
+ mod(i,23) || ' dollars and zero cents'
FROM generate_series(1,1000) s(i);
ANALYZE ndistinct;
diff --git a/src/test/regress/sql/union.sql b/src/test/regress/sql/union.sql
index 599013e7c9..6c509ac80c 100644
--- a/src/test/regress/sql/union.sql
+++ b/src/test/regress/sql/union.sql
@@ -162,12 +162,12 @@ reset enable_hashagg;
set enable_hashagg to on;
explain (costs off)
-select x from (values (100::money), (200::money)) _(x) union select x from (values (100::money), (300::money)) _(x);
+select x from (values ('11'::varbit), ('10'::varbit)) _(x) union select x from (values ('11'::varbit), ('10'::varbit)) _(x);
set enable_hashagg to off;
explain (costs off)
-select x from (values (100::money), (200::money)) _(x) union select x from (values (100::money), (300::money)) _(x);
+select x from (values ('11'::varbit), ('10'::varbit)) _(x) union select x from (values ('11'::varbit), ('10'::varbit)) _(x);
reset enable_hashagg;
@@ -186,8 +186,8 @@ select x from (values (array[1, 2]), (array[1, 3])) _(x) except select x from (v
-- non-hashable type
explain (costs off)
-select x from (values (array[100::money]), (array[200::money])) _(x) union select x from (values (array[100::money]), (array[300::money])) _(x);
-select x from (values (array[100::money]), (array[200::money])) _(x) union select x from (values (array[100::money]), (array[300::money])) _(x);
+select x from (values (array['10'::varbit]), (array['11'::varbit])) _(x) union select x from (values (array['10'::varbit]), (array['01'::varbit])) _(x);
+select x from (values (array['10'::varbit]), (array['11'::varbit])) _(x) union select x from (values (array['10'::varbit]), (array['01'::varbit])) _(x);
set enable_hashagg to off;
@@ -221,15 +221,15 @@ select x from (values (row(1, 2)), (row(1, 3))) _(x) except select x from (value
-- With an anonymous row type, the typcache does not report that the
-- type is hashable. (Otherwise, this would fail at execution time.)
explain (costs off)
-select x from (values (row(100::money)), (row(200::money))) _(x) union select x from (values (row(100::money)), (row(300::money))) _(x);
-select x from (values (row(100::money)), (row(200::money))) _(x) union select x from (values (row(100::money)), (row(300::money))) _(x);
+select x from (values (row('10'::varbit)), (row('11'::varbit))) _(x) union select x from (values (row('10'::varbit)), (row('01'::varbit))) _(x);
+select x from (values (row('10'::varbit)), (row('11'::varbit))) _(x) union select x from (values (row('10'::varbit)), (row('01'::varbit))) _(x);
-- With a defined row type, the typcache can inspect the type's fields
-- for hashability.
-create type ct1 as (f1 money);
+create type ct1 as (f1 varbit);
explain (costs off)
-select x from (values (row(100::money)::ct1), (row(200::money)::ct1)) _(x) union select x from (values (row(100::money)::ct1), (row(300::money)::ct1)) _(x);
-select x from (values (row(100::money)::ct1), (row(200::money)::ct1)) _(x) union select x from (values (row(100::money)::ct1), (row(300::money)::ct1)) _(x);
+select x from (values (row('10'::varbit)::ct1), (row('11'::varbit)::ct1)) _(x) union select x from (values (row('10'::varbit)::ct1), (row('01'::varbit)::ct1)) _(x);
+select x from (values (row('10'::varbit)::ct1), (row('11'::varbit)::ct1)) _(x) union select x from (values (row('10'::varbit)::ct1), (row('01'::varbit)::ct1)) _(x);
drop type ct1;
set enable_hashagg to off;
diff --git a/src/test/regress/sql/with.sql b/src/test/regress/sql/with.sql
index ff68e21e2e..f8a213e357 100644
--- a/src/test/regress/sql/with.sql
+++ b/src/test/regress/sql/with.sql
@@ -33,11 +33,11 @@ SELECT * FROM t;
-- UNION DISTINCT requires hashable type
WITH RECURSIVE t(n) AS (
- VALUES (1::money)
+ VALUES ('01'::varbit)
UNION
- SELECT n+1::money FROM t WHERE n < 100::money
+ SELECT n || '10'::varbit FROM t WHERE n < '100'::varbit
)
-SELECT sum(n) FROM t;
+SELECT n FROM t;
-- recursive view
CREATE RECURSIVE VIEW nums (n) AS
--
2.43.0
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2024-01-12 16:19 Jonathan S. Katz <jkatz@postgresql.org>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 24+ messages in thread
From: Jonathan S. Katz @ 2024-01-12 16:19 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On 1/10/24 8:12 PM, Michael Paquier wrote:
> While looking at the whole picture, an issue with the direct removal
> of money is how we should handle btree_gin and btree_gist which have
> operators based on money. We try to keep things compatible at
> run-time, but could this be worth a hard break in these modules,
> dropping the older sql scripts used in the modules if we don't have
> access to money anymore at runtime? These are not popular modules..
> Any thoughts about that?
Both modules are pretty popular. Personally, I used it in scheduling
apps that involved range types + exclusion constraints. The data I've
seen suggests btree_gist / btree_gin are widely deployed.
That said, I don't know how much of these modules are used with the
money type specifically. My guess is that it's more common to combine it
with something like an {int,bool}/range type than a money type.
It sounds like we'd have to tread a bit lightly because of this, even if
money is not frequently (or at all) used with btree_gist/gin?
Jonathan
Attachments:
OpenPGP_signature.asc (application/pgp-signature, 839B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2024-01-12 16:33 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jonathan S. Katz <jkatz@postgresql.org>
0 siblings, 1 reply; 24+ messages in thread
From: Tom Lane @ 2024-01-12 16:33 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Michael Paquier <michael@paquier.xyz>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 1/10/24 8:12 PM, Michael Paquier wrote:
>> While looking at the whole picture, an issue with the direct removal
>> of money is how we should handle btree_gin and btree_gist which have
>> operators based on money. We try to keep things compatible at
>> run-time, but could this be worth a hard break in these modules,
>> dropping the older sql scripts used in the modules if we don't have
>> access to money anymore at runtime? These are not popular modules..
>> Any thoughts about that?
> Both modules are pretty popular.
Yeah, I think it's a serious error to assume they aren't used plenty.
Not the money part, but other scalar types.
> It sounds like we'd have to tread a bit lightly because of this, even if
> money is not frequently (or at all) used with btree_gist/gin?
What'd have to happen is that people would have to upgrade to a
version of btree_gin/btree_gist that deletes its money support
before they could pg_upgrade into a core version that lacks money.
So we'd have to ship that version at least one major release before
nuking the core support.
I think the shortest timeline we could possibly do this on is:
v17: label money as deprecated and due for removal in the SGML docs
v18: remove support in btree_gin/btree_gist (and any other affected
extensions)
v19: remove it from core
Note that in v18, people could still use money even in
btree_gin/btree_gist, just by installing a non-default extension
version. So their C code for money would have to stay.
regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2024-01-13 03:50 Jonathan S. Katz <jkatz@postgresql.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 24+ messages in thread
From: Jonathan S. Katz @ 2024-01-13 03:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On 1/12/24 11:33 AM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> It sounds like we'd have to tread a bit lightly because of this, even if
>> money is not frequently (or at all) used with btree_gist/gin?
>
> What'd have to happen is that people would have to upgrade to a
> version of btree_gin/btree_gist that deletes its money support
> before they could pg_upgrade into a core version that lacks money.
> So we'd have to ship that version at least one major release before
> nuking the core support.
Hm -- what about people who skip versions (e.g. 16 => 19)? Would they
have to stop at 18 first to perform the upgrade? And does this only
affect people who use btree_gist/gin for moeny, or all btree_gist/gin users?
> I think the shortest timeline we could possibly do this on is:
>
> v17: label money as deprecated and due for removal in the SGML docs
We had apparently deprecation notice as late as 8.2[1], but this warning
is missing in the docs :(
> v18: remove support in btree_gin/btree_gist (and any other affected
> extensions)
If the btree_gist/gin issue only affects people who use it in
combination with money, I'd at least think we consider this for v17, and
make clear that a users with money have to take action before upgrading.
If we stick with just adding the deprecation notice in the v17 docs, I'd
also suggest we emit a log warning when loading the catalog if the user
has an active use of a "money" type in a table. (I understand that may a
pain to do, but at least wanted to suggested it).
> v19: remove it from core
>
> Note that in v18, people could still use money even in
> btree_gin/btree_gist, just by installing a non-default extension
> version. So their C code for money would have to stay.
Yeah, but for what we support directly in PostgreSQL, we will have made
best effort. If someone _really_ wants to do something with "money" in
the way you describe above, then they're committed to it.
Thanks,
Jonathan
[1] https://www.postgresql.org/docs/8.2/datatype-money.html
Attachments:
OpenPGP_signature.asc (application/pgp-signature, 839B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2024-01-14 00:55 Michael Paquier <michael@paquier.xyz>
parent: Jonathan S. Katz <jkatz@postgresql.org>
0 siblings, 1 reply; 24+ messages in thread
From: Michael Paquier @ 2024-01-14 00:55 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Fri, Jan 12, 2024 at 10:50:25PM -0500, Jonathan S. Katz wrote:
> On 1/12/24 11:33 AM, Tom Lane wrote:
>> What'd have to happen is that people would have to upgrade to a
>> version of btree_gin/btree_gist that deletes its money support
>> before they could pg_upgrade into a core version that lacks money.
>> So we'd have to ship that version at least one major release before
>> nuking the core support.
>
> Hm -- what about people who skip versions (e.g. 16 => 19)? Would they have
> to stop at 18 first to perform the upgrade? And does this only affect people
> who use btree_gist/gin for moeny, or all btree_gist/gin users?
That's exactly why I am worried about a schedule being too aggressive
here. Less runs of pg_upgrade means less headaches and less downtime.
I'd guess that we should have at least 3~4 years between a deprecation
in the docs and the actual removal. It seems like this is what we
should do now on HEAD, aiming at a complete removal in 21~22 when 17
gets out of support (even if pg_upgrade support is down to 10 years).
>> v19: remove it from core
>>
>> Note that in v18, people could still use money even in
>> btree_gin/btree_gist, just by installing a non-default extension
>> version. So their C code for money would have to stay.
>
> Yeah, but for what we support directly in PostgreSQL, we will have made best
> effort. If someone _really_ wants to do something with "money" in the way
> you describe above, then they're committed to it.
By the way, let me know if you have any objections about the patch I
have posted upthread that reduces the dependency to money in the main
regression test suite, replacing things with varbit while keeping
coverage the same. I have a few second thoughts about the change in
create_table, so I'm tempted to leave that part out for now, switching
the rest.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2024-01-15 07:54 Michael Paquier <michael@paquier.xyz>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 24+ messages in thread
From: Michael Paquier @ 2024-01-15 07:54 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Sun, Jan 14, 2024 at 09:55:03AM +0900, Michael Paquier wrote:
> By the way, let me know if you have any objections about the patch I
> have posted upthread that reduces the dependency to money in the main
> regression test suite, replacing things with varbit while keeping
> coverage the same. I have a few second thoughts about the change in
> create_table, so I'm tempted to leave that part out for now, switching
> the rest.
This one has been backpatched as 31acee4b66f9 for now, but I've left
out the test case in create_table with partitions. I kind of felt
that I was missing something, and it did not prevent to switch all the
others.
I'll spawn a thread on -hackers about what to do next, with probably a
patch to propose a deprecation notice in the docs for v17.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2024-07-19 14:44 Nathan Bossart <nathandbossart@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 24+ messages in thread
From: Nathan Bossart @ 2024-07-19 14:44 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Jonathan S. Katz <jkatz@postgresql.org>; Tom Lane <tgl@sss.pgh.pa.us>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Mon, Jan 15, 2024 at 04:54:51PM +0900, Michael Paquier wrote:
> I'll spawn a thread on -hackers about what to do next, with probably a
> patch to propose a deprecation notice in the docs for v17.
Did this thread ever materialize? I searched around a bit and couldn't
find anything.
--
nathan
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
@ 2024-07-19 17:06 Nathan Bossart <nathandbossart@gmail.com>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 0 replies; 24+ messages in thread
From: Nathan Bossart @ 2024-07-19 17:06 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Jonathan S. Katz <jkatz@postgresql.org>; Tom Lane <tgl@sss.pgh.pa.us>; David Rowley <dgrowleyml@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
For future reference, this bug should be fixed by commit 22b0ccd.
--
nathan
^ permalink raw reply [nested|flat] 24+ messages in thread
end of thread, other threads:[~2024-07-19 17:06 UTC | newest]
Thread overview: 24+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-12-11 06:00 BUG #18240: Undefined behaviour in cash_mul_flt8() and friends PG Bug reporting form <noreply@postgresql.org>
2023-12-11 10:22 ` Michael Paquier <michael@paquier.xyz>
2023-12-11 15:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-12-12 03:00 ` Alexander Lakhin <exclusion@gmail.com>
2023-12-12 09:03 ` Michael Paquier <michael@paquier.xyz>
2023-12-12 10:37 ` Bruce Momjian <bruce@momjian.us>
2023-12-12 12:01 ` David Rowley <dgrowleyml@gmail.com>
2023-12-12 14:37 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-12-16 09:19 ` Michael Paquier <michael@paquier.xyz>
2023-12-16 15:19 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-12-24 17:16 ` Jonathan S. Katz <jkatz@postgresql.org>
2023-12-24 18:21 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-12-25 00:52 ` Michael Paquier <michael@paquier.xyz>
2023-12-25 09:57 ` Michael Paquier <michael@paquier.xyz>
2023-12-25 15:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-01-11 01:12 ` Michael Paquier <michael@paquier.xyz>
2024-01-12 16:19 ` Jonathan S. Katz <jkatz@postgresql.org>
2024-01-12 16:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-01-13 03:50 ` Jonathan S. Katz <jkatz@postgresql.org>
2024-01-14 00:55 ` Michael Paquier <michael@paquier.xyz>
2024-01-15 07:54 ` Michael Paquier <michael@paquier.xyz>
2024-07-19 14:44 ` Nathan Bossart <nathandbossart@gmail.com>
2024-07-19 17:06 ` Nathan Bossart <nathandbossart@gmail.com>
2023-12-25 01:09 ` Laurenz Albe <laurenz.albe@cybertec.at>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox