Hi hackers,
While reviewing pg_createsubscriber logs (in another thread) I saw
some unexpected (almost) duplicate consecutive logs for the slot
creation in --dry-run mode.
e.g.
--
pg_createsubscriber: creating the replication slot
"pg_createsubscriber_16386_e9a70df3" in database "db2"
pg_
On Wed, Oct 8, 2025 at 9:13 AM Dilip Kumar wrote:
>
> On Tue, Oct 7, 2025 at 5:46 PM Amit Kapila wrote:
> >
> >
> > Yes, we can add the additional functionality for selective sequences
> > if required but do we have an option to allow upgrade of selective
> > tables?
>
> If the user is upgrading
Dear Vitaly,
> > Per my understanding, this happened because there is a lag that restart_lsn
> > of
> > the slot is set, and it is protected by the system. Your idea is to ensure
> > the
> > restart_lsn is protected by the system before obtaining on-memory LSN,
> > right?
>
> Not sure what you
Hi Oliver,
I have just pushed a change to WinGetFuncArgInPartition() in
nodeWindowAgg.c to fix Coverity issues. So please update your git
respository.
> The result looks wrong. So I've just tried removing the "&& relpos != 0"
> and I get:
>
> SELECT x, y, lead(x, 0) IGNORE NULLS OVER w FROM g
>
On Tue, Oct 07, 2025 at 11:51:45AM -0700, Masahiko Sawada wrote:
> Just to be clear, did you mean that pg_checksums and pg_rewind already
> do such checks? IIUC pg_checksums does CRC check for the control file,
> and if we execute v18-pg_checksums against v17-cluster we end up with
> a similar erro
"Matheus Alcantara" writes:
> On Tue Oct 7, 2025 at 1:51 PM -03, Tom Lane wrote:
>> Also, I don't think it's the job of this patch to provide test
>> coverage for dshash. That should be quite well covered already.
> When I was mentioning to test that we can grow the dshash correctly it's
> becau
On Tue, Oct 7, 2025 at 3:46 PM Andres Freund wrote:
> I think this discrepancy is largely due to the fact that Tomas' is testing
> with a cold cache (he has numbers for both), whereas most production workloads
> have very high cache hit ratios.
Any test case that fails to ensure that all relevant
On Tue, Oct 07, 2025 at 12:45:12PM -0500, Sami Imseih wrote:
> The vacuum command detail can now be determined from
> pg_stat_activity.query by joining with pg_stat_progress_vacuum, right?
> I don't see why this is not sufficient, especially because it already
> indicates how the vacuum was trigger
Hi,
On 2025-10-07 14:39:44 -0400, Andrew Dunstan wrote:
> It's less clear to me how to do that in meson, though, since you can only
> have a single command in a custom target.
Create a stamp file for the check success and make that a dependency of
the main build too.
Greetings,
Andres Freund
On 2025-10-06 Mo 12:00 PM, Álvaro Herrera wrote:
On 2025-Oct-03, Tom Lane wrote:
Would it be unreasonable to discard the "check" target altogether?
It made sense back in the day when actually building the html docs
took many minutes. But I haven't used it in years, so I wonder
if anyone else
I am bit late to this thread, but I have a comment.
> This patch introduces a mode column to provide this visibility. The
> possible values are:
> - normal: A standard, user-initiated VACUUM or a regular autovacuum run.
> - anti-wraparound: An autovacuum run launched specifically to prevent
> tran
On Tue, Oct 7, 2025 at 1:08 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Oct 06, 2025 at 01:18:38PM -0700, Masahiko Sawada wrote:
> > On Sun, Oct 5, 2025 at 11:52 PM Bertrand Drouvot
> > wrote:
> > >
> > > Could we also imagine that there are other activities enough to reach the
> > > memory
>
On Tue, Oct 7, 2025, at 14:40, Matheus Alcantara wrote:
> This is not a complete review, I just read the v9 patch and summarized
> some points.
Many thanks for the review!
> 1. You may want to add ChannelEntry and ChannelHashKey to typedefs.list
> to get pgindent do the right job on indentation.
Hello hackers,
I stumbled upon a case and wanted to raise a quick thread to get some
feedback on this.
Basically, dropping a foreign key constraint or a table that owns an FK
currently blocks reads on the other table due to AccessExclusive locks
taken while removing the FK’s internal triggers and
Hi,
On Tue, 7 Oct 2025 at 00:55, Andres Freund wrote:
> On 2025-10-04 09:05:45 +0200, Matthias van de Meent wrote:
> > 0001 ensures that ReadRecentBuffer increments the usage counter, which
> > someone who uses an access strategy may want to prevent. I know this
> > isn't exactly new behaviour, b
I’ve looked through this patch. As far as I can tell, everything looks good,
working and well commented.
The only nitpick I could find is a mispelling "EXLCUDED" → "EXCLUDED" in
src/test/regress/expected/returning.out:464.
A maybe bigger question, is it nice that EXCLUDED is null when no conflic
On Tue, Oct 7, 2025 at 9:36 AM Amit Kapila wrote:
>
> On Fri, Oct 3, 2025 at 12:43 AM Masahiko Sawada wrote:
> >
> > On Wed, Oct 1, 2025 at 10:48 AM Amit Kapila wrote:
> > >
> > > The other point to consider is that during promotion after
> > > UpdateLogicalDecodingStatusEndOfRecovery(), we have
On Tue, 7 Oct 2025 at 11:46, Michael Paquier wrote:
>
> On Wed, Oct 01, 2025 at 03:39:35PM +0900, Michael Paquier wrote:
> > + int32 ntuples;
> > + ntuples = ((ginxlogUpdateMeta *) rec)->ntuples;
> > + appendStringInfo(buf, "ntuples: %d",
On Mon, Oct 6, 2025 at 4:33 PM vignesh C wrote:
>
> On Mon, 6 Oct 2025 at 12:07, vignesh C wrote:
> >
> > On Sat, 4 Oct 2025 at 21:24, Amit Kapila wrote:
> > >
> > > On Tue, Sep 30, 2025 at 9:55 PM vignesh C wrote:
> > > >
> > >
> > > In the 0001 patch, pg_get_sequence_data() exposes two new fi
19 matches
Mail list logo
