I hope there can be a high-level design document that includes a
description, high-level architecture, and low-level design.
This way, others can also participate in reviewing the code.
For example, which paths were modified in the AIO module? Is it the
path for writing WAL logs, or the path for fl
uot;blindly" without reading the
> > old pages first. We have WAL prefetching now, which alleviates that, but
> > it's no panacea.
>
> 陈宗志, you mimght find this blog post helpful:
>
> https://momjian.us/main/blogs/pgblog/2017.html#June_5_2017
>
&g
someone could write a demo to show it..
On Tue, Aug 20, 2024 at 9:46 PM Heikki Linnakangas wrote:
>
> On 20/08/2024 11:46, 陈宗志 wrote:
> > I’ve recently started exploring PostgreSQL implementation. I used to
> > be a MySQL InnoDB developer, and I find the PostgreSQL community feels
I’ve recently started exploring PostgreSQL implementation. I used to
be a MySQL InnoDB developer, and I find the PostgreSQL community feels
a bit strange.
There are some areas where they’ve done really well, but there are
also some obvious issues that haven’t been improved.
For example, the B-lin
Hello, I have a question about cross-compiling. I get an error when doing
initdb for postgresql for arm64 architecture devices.
The error information is Error relocating
/data/postgresql/postgresql-16.3-arm64-v8a-build/tmp_install/usr/postgresql/arm64-v8a/lib/dict_snowball.so:
palloc0: symbol no
Hi, all
We use 32bit postgres PG11 in our product for X86_64 platform, Now we want to
add new process which is 64bit
to access the 32bit progres using 64bit libpq.
I tried to access the PostgresDB 32bit, with 64bit libpq and it works very nice.
So my question is, can we use 64bit lippq to acc
I think we must meet some corner cases about our storage. The relation has
32TB blocks, so 'mdnblocks' gets the unexpected value, we will check it again.
Thanks a lot.
Hello
We know that PostgreSQL doesn't support a single relation size over 32TB,
limited by the MaxBlockNumber. But if we just 'insert into' one relation over
32TB, it will get an error message 'unexpected data beyond EOF in block 0 of
relation' in ReadBuffer_common. The '0 block' is from mdnblo
+1, This would be an nice improvement even the lseek is fast usually, it is a
system call after all
Buzhen--
发件人：Andy Fan
日 期：2021年05月31日 13:46:22
收件人：PostgreSQL Hackers
主 题：Re: Regarding the necessity of RelationGetNumberOfBlocks f
Hi Thomas
I want to share a patch with you, I change the replacement algorithm from fifo
to a simple lru.
Buzhen
0001-update-fifo-to-lru-to-sweep-a-valid-cache.patch
Description: Binary data
--原始邮件 --
发件人:Thomas Munro
发送时间:Fri Jan 8 00:56:17 2021
收件人:陈佳昕(步真)
抄送:Amit Kapila , Konstantin Knizhnik
, PostgreSQL Hackers
主题:Re: Cache relation sizes?
On Wed, Dec 30, 2020 at 4:13 AM 陈佳昕(步真) wrote:
> I found some other problems which I want to share my change with you
't
remove the sr_pool. But in smgrnblocks_fast, it just get sr from sr_pool, so I
add some codes as above to avoid some corner cases get an unexpected result
from smgrnblocks_fast. Is it necessary, I also want some advice from you.
Thanks a lot.
Buzhen
--原始邮件 ----
Hi Thomas:
I studied your patch these days and found there might be a problem.
When execute 'drop database', the smgr shared pool will not be removed because
of no call 'smgr_drop_sr'. Function 'dropdb' in dbcommands.c remove the buffer
from bufferpool and unlink the real files by 'rmtree', It d
Hi pg-hackers,
We archive the WAL to a remote storage and will perform Point-in-Time
Recovery by replaying the log from that remote storage. Under heavy load,
our archiving pipeline is not able to archive WAL quick enough and we would
like to get more visibility on the lag.
pg_stat_archiver is gr
14 matches
Mail list logo
