Re: [Proposal] Page Compression for OLTP

Hi, hackers I want to know whether this patch can be accepted by the community, that is, whether it is necessary for me to continue working for this Patch. If you have any suggestions, please feedback to me. Best Regards Chen Huajun

Re: [Proposal] Page Compression for OLTP

At 2021-02-16 21:51:14, "Daniel Gustafsson" wrote: >> On 16 Feb 2021, at 15:45, chenhj wrote: > >> I want to know whether this patch can be accepted by the community, that is, >> whether it is necessary for me to continue working for this Patch. >> If you

could not access status of transaction

In our PG 10.2(CentOS 7.3) database, the following error is reported when querying a table. We have already restored the production data through backup, but i want to confirm what may be the reason and how to avoid it in the future. lma=# select count(*) from bi_dm.tdm_ttk_site_on_way_rt

When use prepared protocol, transaction will hold backend_xmin until the end of the transaction.

Hi, hackers! When execute sql with prepared protocol, read committed transaction will hold backend_xmin until the end of the transaction. Is this behavior normal? Should read committed transaction release backend_xmin immediately after SQL executing is completed? Just like when executing sql w

Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

Hi,all In our PostgreSQL 10.2 database, two sessions of insert and autovacuum of gin index blocked in LWLock:buffer_content. This blocked checkpoint and dead tuple recycle,and we had to restart the datebase. According to the information collected from gcore, a deadlock occurred when acquiring

Re:Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

Hi,all I analyzed the btree block where lwlock deadlock occurred, as follows: ## insert process(ginInsertValue()) 644(root blkno) | 7054(2. held LWLock:0x2aaac587ae64) rightlink>(3. Acquire LWLock:0x2aaab4009564，buffer = 2119

Re:Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

Hi Before we only discussed the connection hang on the primary, the connection hang on the standby database should be another problem. When the recovery process replays the gin's delete WAL record, the order of get lwlock is not the same as the select process, resulting in a deadlock. Accord

Re:Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

At 2017-12-01 12:27:09, "Michael Paquier" wrote: >On Tue, Oct 3, 2017 at 1:20 AM, chenhj wrote: >> I had filled the authors field of this patch in commitfest, and will rebase >> this patch if needed. Thank you for your help! > >The documentation of the patch ne

Re:Re: could not access status of transaction

Hi, all Our other system had encountered the same failure, but this time it is PostgreSQL 10.7(rhel 6.3). Details are as follows: Phenomenon: app_db=# select count(*) from loba_sp_cost_xcd_104561; ERROR: could not access status of transaction 35153545 DETAIL: Could not open file "pg_xact

Connections hang indefinitely while taking a gin index's LWLock buffer_content lock(PG10.7)

Hi,all In our PostgreSQL 10.7(rhel 6.3) database, autovacuum process and many insert processes blocked in gin index's LWLock:buffer_content for long time. In other words, the following gin index lwlock deadlock phenomenon has occurred again. Since the following bug in 10.7 has been fixed. So

Re:Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

At 2018-01-23 09:56:48, "Stephen Frost" wrote: > >I've only read through the thread to try and understand what's going on >and the first thing that comes to mind is that you're changing >pg_rewind to not remove the WAL from before the divergence (split) >point, but I'm not sure why. As noted, t

Re:could not access status of transaction

Hi, This database has not had the same failure again 2019/09/16(reported at 2019/09/29), so this is a very low probability failure, but it is uncertain whether it will happen again in the future. Now add some information for incident at 2019/09/16, may be useful for analyze the cause of this

[Proposal] Page Compression for OLTP

Hello hackers! This email is about the proposal to implement OLTP-oriented compression on PostgreSQL. Although there are currently some alternative ways to achieve compression, such as using a file system that supports compression. However, this depends on a specific file system and is not suit

Re: [Proposal] Page Compression for OLTP

At 2020-05-21 15:04:55, "Fabien COELHO" wrote: > >Hello, > >My 0.02, some of which may just show some misunderstanding on my part: > > - Could this be proposed as some kind of extension, provided that enough > hooks are available? ISTM that foreign tables and/or alternative > storage engine (

Re: [Proposal] Page Compression for OLTP

Sorry, There may be a problem with the display format of the previous mail. So resend it At 2020-05-21 15:04:55, "Fabien COELHO" wrote: > >Hello, > >My 0.02, some of which may just show some mi

Re: [Proposal] Page Compression for OLTP

Hi hackers, > # Page storage(Plan C) > > Further, since the size of the compress address file is fixed, the above > address file and data file can also be combined into one file > > 0 1 2 1230710 1 2 > +===+===+===+ +===+=+=