| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Should logtape.c blocks be of type long? |
| Date: | 2023-09-26 04:15:03 |
| Message-ID: | ZRJax7xO-zHSNRbd@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Sep 24, 2023 at 10:42:49AM +0900, Michael Paquier wrote:
> Indeed, or Windows decides that making long 8-byte is wiser, but I
> doubt that's ever going to happen on backward-compatibility ground.
While looking more at that, I've noticed that I missed BufFileAppend()
and BufFileSeekBlock(), that themselves rely on long. The other code
paths calling these two routines rely on BlockNumber (aka uint32), so
that seems to be the bottom of it.
For now, I have registered this patch to the next CF:
https://commitfest.postgresql.org/45/4589/
Comments are welcome.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Change-logtape-tuplestore-code-to-use-int64-for-bloc.patch | text/x-diff | 17.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Markur Sens | 2023-09-26 04:19:06 | How are jsonb_path_query SRFs $.datetime() defined ? |
| Previous Message | Amit Kapila | 2023-09-26 04:10:48 | Re: pg_upgrade and logical replication |