is a major issue because detecting the
deadlock is better than data loss. The schema issue is probably more
important. I didn't test it out with the latest patches sent by
Vignesh but since the code changes in that patch are also in
OpenTableList, I think the schema scenario won't be
On Wed, Jul 10, 2024 at 11:22 PM Nitin Motiani wrote:
>
> On Wed, Jul 10, 2024 at 10:39 PM vignesh C wrote:
> >
> > On Wed, 10 Jul 2024 at 12:28, Amit Kapila wrote:
> > > The patch missed to use the ShareRowExclusiveLock for partitions, see
> > > attached.
Relation(resultRelInfo->ri_RelationDesc). Is there a
big advantage of storing a separate bool field? Also there is another
write to ri_RelationDesc in CatalogOpenIndexes in
src/backlog/catalog/indexing.c. I think ri_needLockTagTuple needs to
be set there also to keep it consistent with ri_RelationDesc. Please
let me know if I am missing something about the usage of the new
field.
Thanks & Regards,
Nitin Motiani
Google
CT * FROM update_test;
1 | Eeshan
(1 row)
While this is the state on the subscriber :
SELECT * FROM update_test;
1 | Chiranjiv
(1 row)
I think the update during a transaction scenario might be more common
than deletion right after insertion. But both of these seem like real
issues to consider. Please let me know if I'm missing something.
Thanks & Regards
Nitin Motiani
Google
On Sat, Aug 31, 2024 at 6:40 AM Noah Misch wrote:
>
> On Thu, Aug 29, 2024 at 09:08:43PM +0530, Nitin Motiani wrote:
> > On Thu, Aug 29, 2024 at 8:11 PM Noah Misch wrote:
> > > On Tue, Aug 20, 2024 at 11:59:45AM +0300, Heikki Linnakangas wrote:
> > > > M
g
assert assert (or just a debug assert) in this function?
Assert(rel->ri_needsLockTagTuple == IsInplaceUpdateRelation(rel->relationDesc)
This can safeguard against users of ResultRelInfo missing this field.
An alternative might be to only do debug assertions in the functions
which use the field. But it seems simpler to just do it once in the
ExecInitModifyTable.
> > But even for the
> > ri_TrigDesc, CatalogOpenIndexes() still sets it to NULL. So shouldn't
> > ri_needLockTagTuple also be set to a default value of false?
>
> CatalogOpenIndexes() explicitly zero-initializes two fields and relies on
> makeNode() zeroing for dozens of others. Hence, omitting the initialization
> fits the function's local convention better than including it. (PostgreSQL
> has no policy or dominant practice about redundant zero-initialization.)
Thanks. Makes sense.
Thanks & Regards
Nitin Motiani
Google
On Thu, Sep 5, 2024 at 1:27 AM Noah Misch wrote:
>
> On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote:
> > How about this alternative then? The tuple length check
> > and the elog(ERROR) gets its own function. Something like
> > heap_in
On Fri, Sep 6, 2024 at 3:34 AM Noah Misch wrote:
>
> On Thu, Sep 05, 2024 at 07:10:04PM +0530, Nitin Motiani wrote:
> > On Thu, Sep 5, 2024 at 1:27 AM Noah Misch wrote:
> > > On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote:
> > > >
On Sat, Sep 7, 2024 at 12:25 AM Noah Misch wrote:
>
> On Fri, Sep 06, 2024 at 03:22:48PM +0530, Nitin Motiani wrote:
> > Thanks. I have no other comments.
>
> https://commitfest.postgresql.org/49/5090/ remains in status="Needs review".
> When someone moves it to
On Thu, Sep 5, 2024 at 4:04 PM Amit Kapila wrote:
>
> On Mon, Sep 2, 2024 at 9:19 PM Nitin Motiani wrote:
> >
> > I think that the partial data replication for one table is a bigger
> > issue than the case of data being sent for a subset of the tables in
> > the
On Mon, Jul 15, 2024 at 11:42 PM vignesh C wrote:
>
> On Mon, 15 Jul 2024 at 15:31, Amit Kapila wrote:
> >
> > On Thu, Jul 11, 2024 at 6:19 PM Nitin Motiani
> > wrote:
> > > I looked further into the scenario of adding the tables in schema to
> > >
On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote:
>
> On Wed, 17 Jul 2024 at 11:54, Amit Kapila wrote:
> >
> > On Tue, Jul 16, 2024 at 6:54 PM vignesh C wrote:
> > >
> > > On Tue, 16 Jul 2024 at 11:59, Amit Kapila wrote:
> > > >
> > > > On Tue, Jul 16, 2024 at 9:29 AM Amit Kapila
> > > > wrote
On Thu, Jul 18, 2024 at 3:05 PM Nitin Motiani wrote:
>
> On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote:
> >
> > I tested these scenarios, and as you expected, it throws an error for
> > the create publication case:
> > 2024-07-17 14:50:01.145 IST [481526] 481
On Thu, Jul 18, 2024 at 3:25 PM Nitin Motiani wrote:
>
> On Thu, Jul 18, 2024 at 3:05 PM Nitin Motiani wrote:
> >
> > On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote:
> > >
> > > I tested these scenarios, and as you expected, it throws an error for
> >
On Thu, Jul 18, 2024 at 3:30 PM Nitin Motiani wrote:
>
> On Thu, Jul 18, 2024 at 3:25 PM Nitin Motiani wrote:
> >
> > On Thu, Jul 18, 2024 at 3:05 PM Nitin Motiani
> > wrote:
> > >
> > > On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote:
> >
On Sat, Oct 12, 2024 at 5:47 PM Noah Misch wrote:
>
> Rebased.
Hi,
I have a couple of questions :
1. In heap_inplace_update_and_unlock, currently both buffer and tuple
are unlocked outside the critical section. Why do we have to move the
buffer unlock within the critical section here? My guess
On Sun, Oct 13, 2024 at 6:15 AM Noah Misch wrote:
>
> On Sat, Oct 12, 2024 at 06:05:06PM +0530, Nitin Motiani wrote:
> > 1. In heap_inplace_update_and_unlock, currently both buffer and tuple
> > are unlocked outside the critical section. Why do we have to move the
> >
On Mon, Oct 14, 2024 at 3:15 PM Nitin Motiani wrote:
>
> On Sun, Oct 13, 2024 at 6:15 AM Noah Misch wrote:
> >
> > On Sat, Oct 12, 2024 at 06:05:06PM +0530, Nitin Motiani wrote:
> > > 1. In heap_inplace_update_and_unlock, currently both buffer and tuple
> > &g
On Thu, Oct 24, 2024 at 8:24 AM Noah Misch wrote:
>
> With the releases wrapping in 2.5 weeks, I'm ambivalent about pushing this
> before the release or after. Pushing before means fewer occurrences of
> corruption, but pushing after gives more bake time to discover these changes
> were defective
. In the patch, we have changed it to 'w' pipe-command
only and added the ideas for potential solutions in the comments.
2. We are also not sure yet on how to handle the environment
issues when trying to add new tests to 002_pg_dump.pl.
Please let us know what you think.
Thanks
commend using
> git format-patch when you post patches so that you have a place to
> write a commit message including a note about which bits are WIP and
> known not to work correctly yet.
Will follow these recommendations when sending the next set of patches.
Regards,
Nitin Motiani
Google
er to restore.
*/
Should the comment provide further detail on why this is only being done
for v12 and above?
Thanks & Regards,
Nitin Motiani
Google
On Fri, Jul 11, 2025 at 3:12 AM Nathan Bossart
wrote:
> On Thu, Jul 10, 2025 at 06:05:26PM +0530, Nitin Motiani wrote:
> > - * pg_largeobject_metadata, after the dump is restored.
> > + * pg_largeobject_metadata, after the dump is restored
On Fri, Jul 11, 2025 at 8:21 PM Nathan Bossart wrote:
>
> > Also just would like to confirm that the pg_dump_sort change will go in a
> > different patch.
>
> That's already been committed: http://postgr.es/c/fb6c860.
>
That's great. Thank you.
Hi,
Apologies for the delay on this thread.
On Mon, Apr 28, 2025 at 1:52 PM Nitin Motiani wrote:
>
> Thanks for the feedback, Thomas.
>
> > Do I understand correctly that
> > the problem you encountered is in some other tests that you haven't
> > attached yet?
On Tue, Sep 9, 2025 at 1:23 PM Fujii Masao wrote:
>
> On Mon, Sep 8, 2025 at 6:33 PM Nitin Motiani wrote:
> >
> > Hi Hackers,
> >
> > I'd like to propose a patch to allow accepting connections post recovery
> > without waiting for the removal of old xlo
ne the two files. Other than that, some are about the open
questions. We will remove those from the code and will discuss those
issues on the thread.
Thanks,
Nitin Motiani
Google
oval of old xlog files was
going on in async, I also ran a few queries, created another table,
inserted data etc and it was all working.
I'm attaching the patch here. Currently I have not added any tests as I
would like to get feedback on this approach to solve the problem vs the
alternatives.
integrity. pgstat_gist_page() is a thin
wrapper around the generic pgstat_index_page(). pgstat_hash_page() does
slightly more, but a page failing the _hash_checkpage() checks still wouldn't
elicit intolerable behavior from pgstat_hash_page().
Let me know what you folks think of this.
Thanks &am
Apologies, I accidentally sent my previous reply only to Michael
instead of hitting 'reply all'. Adding the contents of those messages
in the quoted text.
On Wed, Oct 1, 2025 at 4:45 PM Michael Paquier wrote:
>
> On Wed, Oct 01, 2025 at 04:17:49PM +0530, Nitin Motiani wrote:
&g
On Mon, Sep 29, 2025 at 9:03 AM Dilip Kumar wrote:
>
> I observed that pgstat_btree_page() incorporates the count of new
> pages into its free space calculation[1]. Does it make sense to do the
> same for hash and gist as well as we are leaning towards making these
> consistent.
>
> [1]
> if (Page
Thank you, Michael!
32 matches
Mail list logo