Re: Assertion failure while streaming toasted data

On Tue, May 25, 2021 at 6:55 PM Dilip Kumar wrote: > On Tue, May 25, 2021 at 6:50 PM Pavan Deolasee > wrote: > > > Is that test good enough to trigger the original bug? In my experience, > I had to add a lot more tuples before the logical_decoding_work_mem > threshol

Re: Assertion failure while streaming toasted data

ler value. But that same GUC is used to decide spilling txn to disk as well. So I am not sure if reducing the compile time default is acceptable or not. Thanks, Pavan -- Pavan Deolasee EnterpriseDB: https://www.enterprisedb..com

Re: Shmem queue is not flushed if receiver is not yet attached

le preserving the > essence of your proposed fix. > This looks good to me, > > I'm not sure that we need a shm_mq_flush(), but we definitely don't > have one currently, so I've also adjusted your patch to remove the > dead prototype. > > Makes sense to me. Tha

Re: Shmem queue is not flushed if receiver is not yet attached

e facility. Not sure how useful that is for your purpose. Thanks, Pavan -- Pavan Deolasee EnterpriseDB: https://www.enterprisedb..com

Re: Backporting BackgroundPsql

On Thu, Jun 27, 2024 at 10:05 PM Heikki Linnakangas wrote: > > Ok, I pushed commits to backport BackgroundPsql down to v12. I used > "option 2", i.e. I changed background_psql() to return the new > BackgroundPsql object. > > Don't we need to add install and uninstall rules for the new module, lik

Re: Backporting BackgroundPsql

H i Daniel, On Mon, Jul 1, 2024 at 1:09 PM Daniel Gustafsson wrote: > > On 29 Jun 2024, at 06:38, Pavan Deolasee > wrote: > > > Don't we need to add install and uninstall rules for the new module, > like we did in > https://git

Assertion failure on PG15 with modified test_shm_mq test

Hello, I've a slightly modified version of test_shm_mq, that I changed to include a shared fileset. The motivation to do that came because I hit an assertion failure with PG15 while doing some development work on BDR and I suspected it to be a PG15 bug. The stack trace looks as below: (lldb) bt

Re: Assertion failure on PG15 with modified test_shm_mq test

ried if the code can be reached from multiple paths and testing all of those would be difficult for extension developers, especially given this may happen in error recovery path. Thanks, Pavan -- Pavan Deolasee EnterpriseDB: https://www.enterprisedb..com

Question regarding ASSERT_NO_PARTITION_LOCKS_HELD_BY_ME in dshash_detach()

was very small before. If this is a problem worth addressing, I wonder if we should explicitly release all LWLocks in the long jump handler, like we do for other processes. Thanks, Pavan -- Pavan Deolasee EnterpriseDB: https://www.enterprisedb..com

pg_dump dumps row level policies on extension tables

or row level policies? Or somehow pg_dump should skip dumping those policies? Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

A separate table level option to control compression

RT will not compress the tuple since its length is less than the toast threshold. With the patch and after setting table level option, one can compress such tuples. The attached patch implements this idea. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL D

Re: Another way to fix inherited UPDATE/DELETE

parate mergeTargetRelation, but that approach has been criticised. May be Tom's idea doesn't have the same problem or most likely he will have a far better approach to address that. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

] https://www.postgresql.org/message-id/CAMkU%3D1w3osJJ2FneELhhNRLxfZitDgp9FPHee08NT2FQFmz_pQ%40mail.gmail.com -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services copy_freeze_v3.patch Description: Binary data

Re: [HACKERS] COPY FREEZE and PD_ALL_VISIBLE

d a new patch [1] for consideration to include in PG12. I started a new thread because the patch is completely new and this thread was a bit too old. Thanks, Pavan [1] https://www.postgresql.org/message-id/CABOikdN-ptGv0mZntrK2Q8OtfUuAjqaYMGmkdU1dCKFtUxVLrg%40mail.gmail.com -- Pavan Deolasee

Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

intermediate blocks remain. I wonder if we should instead track the last used block in BulkInsertState and if the relcache invalidation flushes smgr, start inserting again from the last saved block. In fact, we already track the last used buffer in BulkInsertState and that's enough to

Re: monitoring CREATE INDEX [CONCURRENTLY]

OGRESS_CREATEIDX_PHASE 0 +/* 1 and 2 reserved for "waitfor" metrics */ +#define PROGRESS_CREATEIDX_PARTITIONS_TOTAL 3 +#define PROGRESS_CREATEIDX_PARTITIONS_DONE 4 + Is there a reason to leave those reserve placeholders, only to fill them a few lines down? Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: MERGE SQL statement for PG12

if it wasn't last April, because nothing has changed since then. The purpose of keeping it up-to-date is to solicit feedback and directions and to show that my interest in the patch is still intact. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

Hi Andres, On Wed, May 29, 2019 at 1:50 PM Pavan Deolasee wrote: > > > On Tue, 28 May 2019 at 4:36 PM, Andres Freund wrote: > >> Hi, >> >> On 2019-04-07 18:04:27 -0700, Andres Freund wrote: >> > Here's a *prototype* patch for this.

Locking considerations of REINDEX

be someday we would have ability so that the existing queries can continue to read from the old physical index, new queries will shift to the new index and eventually the old index's storage will be dropped when nobody can see it. Thanks, Pavan [1] https://www.postgresql.org/docs/11/static/sql-

Re: PANIC during crash recovery of a recently promoted standby

e complete fix, verifying all the cases, in various back branches. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

PANIC during crash recovery of a recently promoted standby

RecoveryPoint after promotion to ensure that crash recovery always run to the end if a just-promoted standby crashes before completing its first regular checkpoint. A WIP patch is attached. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Sup

Re: PANIC during crash recovery of a recently promoted standby

On Fri, May 11, 2018 at 8:39 PM, Alvaro Herrera wrote: > Michael Paquier wrote: > > On Thu, May 10, 2018 at 10:52:12AM +0530, Pavan Deolasee wrote: > > > I propose that we should always clear the minRecoveryPoint after > promotion > > > to ensure that crash recov

Re: MERGE SQL statement for PG12

e complexity of the patch. So I thought it makes sense to submit it early. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: PATCH: backtraces for error messages

tten and has a bad UI, but those can be improved if there is interest. Given the lack of response, I suspect there is enough interest in the feature though. Thanks, Pavan [1] https://www.postgresql.org/message-id/CABOikdMvx_Kr_b4ELhJEoeGcLTZKrDma%2BfPZpoZVdpL7Zc0bVw%40mail.gmail.com -- Pavan Deolas

Re: PATCH: backtraces for error messages

t much more likely to get nowhere. > > Sorry, I did not mean to mix up two patches. I brought it up just in case it provides another idea about when and how to log the backtrace. So yeah, let's discuss that patch separately. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: PANIC during crash recovery of a recently promoted standby

hat point. + */ s/that/this Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Faster inserts with mostly-monotonically increasing values

nt becomes higher. Patch credit: this work is based on Simon Riggs's original ideas and research. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services pg_btree_target_block_v1.patch Description: Binary data

Accidental removal of a file causing various problems

worth pursuing? Or are these side effects are well understood and known? IMHO even if we accept that we can't do much about a missing file, it seems quite odd that both 1 and 3 happens. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: Accidental removal of a file causing various problems

On Sat, Aug 25, 2018 at 12:16 AM Tom Lane wrote: > Pavan Deolasee writes: > > 1. The user soon found out that they can no longer connect to any > database > > in the cluster. Not just the one to which the affected table belonged, > but > > no other database in the clu

Re: Accidental removal of a file causing various problems

relfilenode, a more interesting question is: should this be automatic or require administrative action? Does either of the ideas sound interesting enough for further work? Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: Potential ABI breakage in upcoming minor releases

On Fri, Nov 15, 2024 at 1:00 AM Tom Lane wrote: > Noah Misch writes: > > It's not immediately to clear to me why this would crash in a non-asserts > > build. palloc issues a 512-byte chunk for sizeof(ResultRelInfo)==368 on > v16, > > so I expect no actual writing past the end of the chunk. > >

Re: Potential ABI breakage in upcoming minor releases

On Thu, Nov 14, 2024 at 9:43 PM Peter Eisentraut wrote: > On 14.11.24 15:35, Noah Misch wrote: > > The postgr.es/c/e54a42a standard would have us stop here. But I'm open > to > > treating the standard as mistaken and changing things. > > That text explicitly calls out that adding struct members

Re: Potential ABI breakage in upcoming minor releases

On Fri, Nov 15, 2024 at 11:39 PM Pavan Deolasee wrote: > > Looking more carefully at the usage of `ResultRelInfo` in the PGD code, I > think we might also be impacted by it. At one place, we loop through the > `es_result_relations` array and a size mismatch there will ca

Potential ABI breakage in upcoming minor releases

Hello, Commit 51ff46de29f67d73549b2858f57e77ada8513369 (backported all the way back to v12) added a new member to `ResultRelInfo` struct. This can potentially cause ABI breakage for the extensions that allocate the struct and pass it down to the PG code. The previously built extensions may allocat

Re: Potential ABI breakage in upcoming minor releases

On Fri, Nov 15, 2024 at 11:22 PM Noah Misch wrote: > > > > I'm starting to lean to the opinion that we need a re-wrap. > > Perhaps. Even if we do rewrap for some reason, it's not a given that > restoring the old struct size is net beneficial. If we restore the old > struct > size in v16.6, thos

<    1   2