pledesc->natts >= NUM_BUFFERCACHE_PAGES_ELEM - 1)
+ TupleDescInitEntry(tupledesc, (AttrNumber) 9,
"pinning_backends",
+ INT4OID, -1, 0);
I think we should not change the "expected_tupledesc->natts" check here until
v17-0003 is applied.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
bout PG16-v2-0001
Same as for PG17-v2-0001.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Thu, Apr 03, 2025 at 09:25:02AM +0530, vignesh C wrote:
> On Mon, 31 Mar 2025 at 18:35, Bertrand Drouvot
> wrote:
> >
> Couple of suggestions:
Thanks for looking at it!
> 1) I felt we can include a similar verification for one of the logical
> replication tests t
) is better (given the examples you just
shared).
=== 6
> I find all of those non-user friendly and I'm afraid I won't be able
> to pull that alone in time...
Maybe we could add a few words in the doc to mention the "multiple nodes per
buffer" case? And try to impr
A few random comments:
=== 1
It looks like that firstNumaTouch is not set to false anymore.
=== 2
+ pfree(os_page_status);
+ pfree(os_page_ptrs);
Not sure that's needed, we should be in a short-lived memory context here
(ExprContext or such).
=== 3
+ ro_volatile_var = *(uint64 *)ptr
space missing before "ptr"?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
to the log file (if log level <= DEBUG2)
- the doc explains what the function does
- that name also makes sense from an API point of view as it calls
"LogStandbySnapshot"
> The other option could be pg_create_standby_snapshot(), which would be
> similar to the existing functio
Hi Jakub,
On Wed, Apr 02, 2025 at 04:45:53PM +0200, Jakub Wartak wrote:
> On Tue, Apr 1, 2025 at 5:13 PM Bertrand Drouvot
> wrote:
> >
> > === 4
> >
> > + for (i = 0; i < NBuffers; i++)
> > + {
> > +
Hi,
On Thu, Apr 03, 2025 at 03:23:31PM +0530, vignesh C wrote:
> Can we add it to one of the subscription tests, such as 001_rep_changes.pl?
Yeah that sounds like a good place for it. Done in the attached.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databa
Hi Jakub,
On Thu, Apr 03, 2025 at 02:36:57PM +0200, Jakub Wartak wrote:
> On Thu, Apr 3, 2025 at 10:23 AM Bertrand Drouvot
> wrote:
> Right, we could also put it as a limitation. I would be happy to leave
> it as it must be a rare condition, but Tomas stated he's not.
>
>
It looks like that check_slots_conflict_reason() is not called with
checks_active_slot
as argument.
=== 5
I think that we could remove the need for the drop_active_slot parameter in
drop_logical_slots() and just check if an active slot exists (and if so drop
it). That said I'm not sure it
cts/a xl_running_xacts/? in the second one? Also I'm not sure
"even here" is needed.
Apart from the above that LGTM.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
would make sense to work an a "larger" cleanup instead?
(in the same vein as [1] did)
[1]:
https://www.postgresql.org/message-id/af837490-6b2f-46df-ba05-37ea6a6653fc%40eisentraut.org
"
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
uld really only acquire one" but
probably not this one "I think it might result in acquiring the
locks on those other objects at a subtly wrong time (leading to race
conditions)".
For the latter I'm not sure how that could be a subtly wrong time or how could
we determine what
existing lock (and if so, skip acquiring a new one) but your proposal
sounds better. Indeed it would make the locking behavior explicit and also
be flexible (allowing the callers to choose the LOCKMODE).
I'll prepare a new version implementing your proposal.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
() in generate-wait_event_types.pl
(in v1-0002) to ensure that the number of LWLocks description generated in the
documentation match the ones defined in lwlock.h and lwlocklist.h.
Looking forward to your feedback,
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
A
801 - 815 of 815 matches
Mail list logo
