Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 24 Jun 2025 11:59:17 +0900,
Masahiko Sawada wrote:
>> 1. This provides 2 registration APIs
>>(RegisterCopy{From,To}Routine(name, routine)) instead of
>>1 registration API (RegisterCopyFormat(na
On Mon, Jun 23, 2025 at 03:59:56PM -0500, Nathan Bossart wrote:
> Here is a very rough proof-of-concept patch set for this. AFAICT there are
> a few options we cannot fix on the back-branches because there is no way to
> tell whether it is set or has just picked up the default. On v18 and
> newer
On Mon, Jun 23, 2025 at 09:44:29AM +0200, Jelte Fennema-Nio wrote:
> On Mon, 23 Jun 2025 at 09:40, Michael Paquier wrote:
>> This renaming patch looks correct to me. I am not seeing any missing
>> references of \close remaining, including APIs, comments and docs.
>
> Agreed
Applied.
--
Michael
On Tue, Jun 24, 2025 at 4:21 AM Melanie Plageman
wrote:
>
> Hi,
>
> In dc6acfd910b8, I added some counters to track and log in
> autovacuum/vacuum output the number of pages newly set
> all-visible/frozen. Taking another look at the code recently, I
> realized the conditions for setting the counte
On Tue, Jun 24, 2025 at 5:30 AM Melanie Plageman
wrote:
> Attached v3 has all of the above. I think the only thing that is
> needed to be changed for the backpatch to 17 is removing
> io_combine_limit.
Looks good to me.
--
John Naylor
Amazon Web Services
On Mon, Jun 23, 2025 at 10:05 PM Nathan Bossart
wrote:
>
> On Mon, Jun 23, 2025 at 10:51:21AM -0400, Tom Lane wrote:
> > This has broken the build completely on my RHEL8 x86_64 box,
> > with gcc 8.5.0:
> >
> > $ ./configure ...
> > $ make -s
> > pg_crc32c_sse42.c: In function 'pg_comp_crc32c_avx51
On Wed, Jun 18, 2025 at 12:59 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 17 Jun 2025 09:38:54 +0900,
> Michael Paquier wrote:
>
> > On Tue, Jun 17, 2025 at 08:50:37AM +0900, Sutou Kouhei wrote:
> >> OK. I'll im
On 6/23/25 23:47, Tomas Vondra wrote:
> ...
>
> Or maybe the 32-bit chroot on 64-bit host matters and confuses some
> calculation.
>
I think it's likely something like this. I noticed that if I modify
pg_buffercache_numa_pages() to query the addresses one by one, it works.
And when I increase the
On Mon, Jun 23, 2025 at 10:38:40AM -0500, Nathan Bossart wrote:
> Is the idea to do something like this for v19 and this [0] for the
> back-branches?
Yes, that would be the idea. Let's do the bug fix first on all the
branches, then do the refactoring. Knowing that I'm indirectly
responsible for
Jacob Champion writes:
> As a potential follow-up, is there any interest in switching the
> Cirrus Meson setup to explicitly enable the features that we expect to
> test? That would match what we do for Autoconf, I think; it would have
> helped me catch my mistake earlier.
As far as I recall, we'
On Mon, Jun 23, 2025 at 11:52 AM Jelte Fennema-Nio wrote:
> On Mon, 23 Jun 2025 at 18:29, Jacob Champion
> wrote:
> > - "dblink" seems overly specific compared to the others.
>
> It seemed roughly as specific as postgres_fdw to me. Maybe we should
> make sure they are grouped more alphabetically.
I've been annoyed for awhile because, while a parallel check-world
run usually takes a bit over a minute on my machine, sometimes it
takes between three and four minutes. I was finally able to
track down what is happening, and it's this: sometimes one or
another of the src/test/subscription tests
>>> Do we know which implementations aren't sending keys?
>
>> Nope, that's totally unclear. It would be very nice knowing which
>> database this is, and if it's at all a production system.
>
> Yeah, I'm very hesitant to spend any effort here without having
> a more concrete use-case.
One exampl
Hi all,
I noticed that the OpenBSD build in CI wasn't running the libcurl
tests. Turns out the feature test I added in b0635bfda is subtly
broken, because it uses cc.check_header() rather than cc.has_header().
On OpenBSD, apparently, the header can't be compiled
without including additional prere
On Wed, Jun 11, 2025 at 05:22:53PM +0200, Peter Eisentraut wrote:
> On 09.12.24 02:25, Noah Misch wrote:
> > > Ok, we should probably put that comment back in slightly altered form,
> > > like
> > >
> > > "XXX This function intentionally takes only an AccessShareLock ...
> > > $REASON.
> > > In
On Mon, Jun 23, 2025 at 1:44 AM John Naylor wrote:
>
> On Fri, Jun 20, 2025 at 9:45 PM Melanie Plageman
> wrote:
>
> > Using auto_explain, I determined that the cursor was using an index-only
> > scan with lower row counts. That meant it pinned an index leaf page instead
> > of a heap page and
Hi,
In dc6acfd910b8, I added some counters to track and log in
autovacuum/vacuum output the number of pages newly set
all-visible/frozen. Taking another look at the code recently, I
realized the conditions for setting the counters could be simplified
because of what we know to be true about the st
On 6/23/25 21:57, Christoph Berg wrote:
> Re: Andres Freund
>> How confident are we that this isn't actually because we passed a bogus
>> address to the kernel or such? With this patch, are *any* pages recognized as
>> valid on the machines that triggered the error?
>
> See upthread - the first
On 6/23/25 23:25, Christoph Berg wrote:
> Re: Tomas Vondra
>> True. If it fails on first call, but succeeds on the other, then the
>> problem is likely somewhere else. But also on the second call we won't
>> do the memory touching. Can you try setting firstNumaTouch=false, so
>> that we do this
Maxim Orlov writes:
> 1) Can this behaviour, in the case described above, when after dump and
> recovery we receive different data, be considered correct?
It's undesirable, for sure.
> 4) Does it make sense to extend the "simple case" grammar so that it can
> accept a custom operator?
This has
On 6/23/25 22:31, Christoph Berg wrote:
> Re: Tomas Vondra
>> Huh. So it's only the first call that does this?
>
> The first call after a restart. Reconnecting is not enough.
>
>> Can you maybe print the addresses passed to pg_numa_query_pages? I
>
> The addresses look good:
>
> Breakpoint 1
Re: Tomas Vondra
> True. If it fails on first call, but succeeds on the other, then the
> problem is likely somewhere else. But also on the second call we won't
> do the memory touching. Can you try setting firstNumaTouch=false, so
> that we do this on every call?
firstNumaTouch=false, it still fa
Re: Tomas Vondra
> Huh. So it's only the first call that does this?
The first call after a restart. Reconnecting is not enough.
> Can you maybe print the addresses passed to pg_numa_query_pages? I
The addresses look good:
Breakpoint 1, pg_numa_query_pages (pid=0, count=32768, pages=0xeb44d02c,
On 6/23/25 22:51, Christoph Berg wrote:
> Re: Tomas Vondra
>> Didn't you say the first ~35 addresses succeed, right? What about the
>> addresses after that?
>
> That was pg_shmem_allocations_numa. The pg_numa_query_pages() in there
> works (does not return -1), but then some of the status[] val
Re: Tomas Vondra
> Didn't you say the first ~35 addresses succeed, right? What about the
> addresses after that?
That was pg_shmem_allocations_numa. The pg_numa_query_pages() in there
works (does not return -1), but then some of the status[] values are
-14.
When pg_buffercache_numa fails, pg_numa
On Fri, Jun 20, 2025 at 11:05:37AM +0900, Michael Paquier wrote:
> On Thu, Jun 19, 2025 at 03:20:27PM -0500, Nathan Bossart wrote:
>> I think we need to do something like the following to fix this:
>>
>> * Teach autovacuum to combine the TOAST reloptions with the main relation's
>> when processi
Re: Andres Freund
> How confident are we that this isn't actually because we passed a bogus
> address to the kernel or such? With this patch, are *any* pages recognized as
> valid on the machines that triggered the error?
See upthread - the first 35 pages were ok, then a lot of -14.
> I wonder if
Jelte Fennema-Nio writes:
> On Mon, 23 Jun 2025 at 18:42, Jacob Champion
> wrote:
>> From reading this thread, I'm not convinced that's "clear". I wouldn't
>> have chosen the existing behavior, for sure, but any existing servers
>> that don't send a key must be doing _something_ with that cancel
On Monday, June 23, 2025, Jelte Fennema-Nio wrote:
> On Mon, 23 Jun 2025 at 18:29, Jacob Champion
> wrote:
> > Initial thoughts:
>
> below my reasoning (feel free to disagree).
>
> > - "dblink" seems overly specific compared to the others.
>
> It seemed roughly as specific as postgres_fdw to me.
On Mon, 23 Jun 2025 at 18:29, Jacob Champion
wrote:
> Initial thoughts:
below my reasoning (feel free to disagree).
> - "dblink" seems overly specific compared to the others.
It seemed roughly as specific as postgres_fdw to me. Maybe we should
make sure they are grouped more alphabetically.
co
On Mon, Jun 23, 2025 at 8:04 PM vignesh C wrote:
>
> On Mon, 23 Jun 2025 at 04:36, Alexander Korotkov wrote:
> >
> > On Fri, Jun 20, 2025 at 2:24 PM vignesh C wrote:
> > > On Fri, 20 Jun 2025 at 05:54, Alexander Korotkov
> > > wrote:
> > > > Dear Kuroda-san,
> > > >
> > > > On Thu, Jun 19, 202
On Mon, 23 Jun 2025 at 18:42, Jacob Champion
wrote:
> > To be clear, I'm not saying we should start throwing errors for things
> > in libpq that weren't errors before.
>
> But that is _exactly_ what we've started doing now, in 18. We return
> NULL instead of an "empty" cancellation object, and at
On Wed, Jun 18, 2025 at 1:21 PM Jeff Davis wrote:
> The only downside of this approach is that we'd be stuck with both --
> with-statistics and --no-statistics forever. That's a bit inconsistent
> with the other options, and it doesn't satisfy Robert's concern about
> the --help output. But Robert
Hi,
Here's patch version 4.
1. The problem
I conducted further investigation on this issue. The 1ms sleep in
XactLockTableWait that falls back to polling was not problematic in certain
scenarios prior to v16. It became an potential issue after the "Allow
logical decoding on standbys" feature w
On Mon, 23 Jun 2025 at 04:36, Alexander Korotkov wrote:
>
> On Fri, Jun 20, 2025 at 2:24 PM vignesh C wrote:
> > On Fri, 20 Jun 2025 at 05:54, Alexander Korotkov
> > wrote:
> > > Dear Kuroda-san,
> > >
> > > On Thu, Jun 19, 2025 at 2:05 PM Hayato Kuroda (Fujitsu)
> > > wrote:
> > > > > > Regar
Hi,
On 2025-06-23 17:59:24 +0200, Christoph Berg wrote:
> Re: To Andres Freund
> > Ok, so we leave the touching in, but still defend against negative
> > status values?
>
> v2 attached.
How confident are we that this isn't actually because we passed a bogus
address to the kernel or such? With th
On Mon, Jun 23, 2025 at 9:24 AM Jelte Fennema-Nio wrote:
> On Mon, 23 Jun 2025 at 18:02, Jacob Champion
> wrote:
> > If anyone today is relying on "backend-key-less" connection, this is
> > potentially a breaking change. For example, psycopg2 now complains:
> >
> > psycopg2.OperationalError:
On Mon, Jun 23, 2025 at 1:17 AM Jelte Fennema-Nio wrote:
> The tags that are currently available are some default ones that I
> thought might be useful. If you're missing certain tags or don't like
> the default ones, please respond to this thread. If you have the right
> permissions, you can even
On Mon, 23 Jun 2025 at 18:02, Jacob Champion
wrote:
> If anyone today is relying on "backend-key-less" connection, this is
> potentially a breaking change. For example, psycopg2 now complains:
>
> psycopg2.OperationalError: can't get cancellation key
It's not super clear what you're referrin
On Mon, Jun 23, 2025 at 9:13 PM Peter Eisentraut wrote:
>
> >
> > Note: Support for composite types in virtual generated columns is
> > currently partial.
> > for example:
> >
> > CREATE TYPE double_int as (a int, b int);
> > --ok
> > CREATE TABLE gtest4 (
> > a int,
> > b double_int GEN
On Thu, Jun 19, 2025 at 5:12 AM Jelte Fennema-Nio wrote:
> I'd be surprised if many clients handle it correctly if it is not
> sent. Looking quickly at the code for pgbouncer and libpq for PG17
> (and lower) they definitely don't. They won't throw an error, but
> instead of doing nothing when the
On Sat, Jun 21, 2025 at 11:45:25PM -0400, shihao zhong wrote:
> 2) When updating a table's relopt, also update the relopt of its
> associated TOAST table if it's not already set. Similarly, when
> creating a new TOAST table, it would inherit the parent's relopt.
>
> Option 2 seems more reasonable
Re: To Andres Freund
> Ok, so we leave the touching in, but still defend against negative
> status values?
v2 attached.
Christoph
>From f05e0f4503b920cd9f136f57dc9707a47786a69c Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Mon, 23 Jun 2025 17:50:41 +0200
Subject: [PATCH v2] Accept unmapped
On Mon, Jun 23, 2025 at 11:29:32AM -0400, Tom Lane wrote:
> The code still uses _mm512_castsi512_si128, so I think removing it
> from the configure snippet might not be bright.
Ah, right. I'm not firing on all cylinders this morning, apparently.
> I adapted what's
> there now to get the attached
Hi!
Imagine that I need to use custom operators for one of the table fields in
a "simple case"
and let these operators not be in a default scheme. As far as I understand,
the only way
to specify the operator in this case is to use the search path.
In the example below, this corresponds to column
On Mon, Jun 23, 2025 at 08:48:35AM +0900, Michael Paquier wrote:
> Anyway, here is an attempt at leaning all that. I am really tempted
> to add a couple of const markers to force VacuumParams to be in
> read-only mode, even if it means doing so for vacuum() but not touch
> at vacuum_rel() where we
On Fri, Jun 20, 2025 at 3:08 AM Ivan Kush wrote:
>
> Hello!
>
> This patch fixes CPPFLAGS, LDFLAGS, LIBS when checking AsyncDNS libcurl
> support in configure
Hi Ivan, thanks for the report! Your patch puts new logic directly
after an AC_MSG_ERROR() call, so any effect has to come from the fact
t
Nathan Bossart writes:
> On Mon, Jun 23, 2025 at 11:10:45AM -0400, Tom Lane wrote:
>> I was imagining just including _mm512_zextsi128_si512() in the
>> code being tested during configure, so that we fall back to
>> the non-AVX-512 code if the compiler is too old to have it.
>> I don't really feel
Re: Andres Freund
> > > Why do we try to force the pages to be allocated at all? This is just
> > > a monitoring function, it should not change the actual system state.
>
> The problem is that the kernel function just gives bogus results for pages
> that *are* present in memory but that have only
On Mon, Jun 23, 2025 at 11:10:45AM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Mon, Jun 23, 2025 at 10:51:21AM -0400, Tom Lane wrote:
>>> This has broken the build completely on my RHEL8 x86_64 box,
>>> with gcc 8.5.0:
>
>> Unfortunately, this will probably require more than replacing
>
Hi,
On 2025-06-23 16:48:27 +0200, Christoph Berg wrote:
> Re: To Tomas Vondra
> > Why do we try to force the pages to be allocated at all? This is just
> > a monitoring function, it should not change the actual system state.
The problem is that the kernel function just gives bogus results for pag
On Mon, Jun 23, 2025 at 7:01 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Jun 23, 2025 at 05:10:37PM +0900, Masahiko Sawada wrote:
> > On Thu, Jun 19, 2025 at 6:00 PM Bertrand Drouvot
> > wrote:
> > >
> > > - pg_activate_logical_decoding() is needed only if there is not already a
> > > logical
Nathan Bossart writes:
> On Mon, Jun 23, 2025 at 10:51:21AM -0400, Tom Lane wrote:
>> This has broken the build completely on my RHEL8 x86_64 box,
>> with gcc 8.5.0:
> Unfortunately, this will probably require more than replacing
> _mm512_castsi512_si128 with _mm512_zextsi512_si128 because the la
On Mon, Jun 23, 2025 at 10:51:21AM -0400, Tom Lane wrote:
> This has broken the build completely on my RHEL8 x86_64 box,
> with gcc 8.5.0:
>
> $ ./configure ...
> $ make -s
> pg_crc32c_sse42.c: In function 'pg_comp_crc32c_avx512':
> pg_crc32c_sse42.c:126:25: warning: implicit declaration of functi
John Naylor writes:
> Pushed, thanks everyone!
This has broken the build completely on my RHEL8 x86_64 box,
with gcc 8.5.0:
$ ./configure ...
$ make -s
pg_crc32c_sse42.c: In function 'pg_comp_crc32c_avx512':
pg_crc32c_sse42.c:126:25: warning: implicit declaration of function
'_mm512_zextsi128_s
Re: To Tomas Vondra
> Why do we try to force the pages to be allocated at all? This is just
> a monitoring function, it should not change the actual system state.
One-time touching might also not be enough, what if the pages later
get swapped out and the monitoring functions are called again? They
Hi.
IMO, I think that some sources can have api misuse.
The functions * PQconnectdbParams* and * PQconnectdb*,
can return NULL and need a handler too.
More, if a connection fail with CONNECTION_BAD, some
sources do not handle correctly when failing.
Must call PQfinish, to release OS resources.
P
Re: To Tomas Vondra
> This is acting up on Debian's 32-bit architectures, namely i386, armel
> and armhf:
... and x32 (x86_64 instruction set with 32-bit pointers).
> SELECT COUNT(*) >= 0 AS ok FROM pg_shmem_allocations_numa;
> +ERROR: invalid NUMA node id outside of allowed range [0, 0]: -14
>
Hi Nikita,
Thank you so much for reviewing!
On Wed, Apr 23, 2025 at 6:54 PM Nikita Malakhov wrote:
> Hi Alex!
>
> Glad you made so much effort to develop this patch set!
> I think this is an important part of Json functionality.
>
> I've looked into you patch and noticed change in behavior
> in
Hi Vik,
On Thu, Mar 27, 2025 at 3:27 PM Vik Fearing wrote:
>
> I am reviewing this from a feature perspective and not from a code
> perspective. On the whole, this looks good to me from a standards point
> of view.
>
Thank you so much for reviewing!
On Thu, Mar 27, 2025 at 3:27 PM Vik Fearing
On Sat, Jun 21, 2025 at 7:37 AM Shayon Mukherjee wrote:
> On Jun 11, 2025, at 9:00 AM, Sami Imseih wrote:
>> IMO, having this GUC to force the use of invisible indexes is quite
>> strange. In my view, it detracts from the guarantees that you're meant
>> to get from disabling indexes. What if some
On Sat, Jun 21, 2025 at 10:59 AM Merlin Moncure wrote:
> On Sat, Jun 21, 2025 at 8:38 AM Shayon Mukherjee wrote:
>> The primary use case I have in mind is for helping engineers (ones not so
>> seasoned like DBAs) decide whether to drop *existing* indexes. For new
>> indexes, I expect most users
On Mon, Jun 23, 2025 at 12:53 PM Hans Buschmann wrote:
> Hello hackers,
>
>
> While exploring some data cleanup and transformation in old data I
> stumbeld over $topic:
>
>
> In a set of data (selected by season=23) I want to determine the min and
> max value of an order number (of_fac_order_n)
> On 23 Jun 2025, at 15:18, Damien Clochard wrote:
>
> Le 25.02.2025 10:34, Andres Freund a écrit :
>> Hi,
>> On February 25, 2025 10:08:44 AM GMT+01:00, Damien Clochard
>> wrote:
>>> So my first question is : Do you think it would be helpful to update the
>>> SECURITY LABEL command documentati
On Sun, Jun 22, 2025, 21:59 Amit Kapila wrote:
>
> On Sat, Jun 21, 2025 at 12:57 AM Anne Struble
wrote:
> >
> > Hello,
> > I'm writing in regards to a fix made in the last release of Postgresql
(specifically, I've looked at versions 15.13 and 16.9). The fix in question
is:
> > Fix data loss in lo
On 23.06.25 09:04, Anthonin Bonnefoy wrote:
On Thu, Jun 19, 2025 at 9:09 AM Michael Paquier wrote:
Good point. I would be on board with a \close_prepared then, if
that's the consensus we reach, without touching at \bind_named. We
still have time to decide on the name until the release, just l
Le 25.02.2025 10:34, Andres Freund a écrit :
Hi,
On February 25, 2025 10:08:44 AM GMT+01:00, Damien Clochard
wrote:
So my first question is : Do you think it would be helpful to update
the SECURITY LABEL command documentation to clarify that security
labels are not concerned by object inherit
On 21.06.25 16:45, jian he wrote:
CREATE TABLE gtest1 (a int42 GENERATED ALWAYS AS ('1') VIRTUAL);
CREATE TABLE gtest2 (a int42 GENERATED ALWAYS AS ('1'::int42) VIRTUAL);
ERROR: generation expression uses user-defined type
LINE 1: CREATE TABLE gtest2 (a int42 GENERATED ALWAYS AS ('1'::int42...
On Wed, Nov 6, 2024 at 12:20 AM Dean Rasheed wrote:
>
> On Tue, 5 Nov 2024 at 15:23, Aleksander Alekseev
> wrote:
> >
> > > > =# SELECT array_random(1, 10, random(0, 3)) FROM generate_series( ... )
> > > > {5}
> > > > {1, 3, 8}
> > > > {7, 6}
> > > > ...
> > >
> > > Yeah, that looks like a neater
install 18.beta1 from source ,remove enable_debug, much better now. it's
better than pgv14.11.
postgres=# select * from tt where b ~~ 'a%';
a | b
---+---
(0 rows)
Time: 67.545 ms
postgres=# select * from tt where b ~~ 'a%';
a | b
---+---
(0 rows)
Time: 50.945 ms
postgres=# select * from tt whe
Dear hackers,
(Adding Amit in CC because he was an original committer)
While reading codes in master, I found the below comment in worker.c.:
```
* We don't allow to toggle two_phase option of a subscription because it can
* lead to an inconsistent replica. Consider, initially, it was on and we
Re: Tom Lane
> I checked Debian and SUSE and noted that their "extended support"
> windows are a lot shorter than RHEL's, just two or three years.
> So maybe we shouldn't buy into RHEL's five-year window.
Fwiw, what we are doing for apt.postgresql.org and Debian is to
support LTS which extends Deb
Thanks for your replies!
Tom Lane wrote:
> Yugo Nagata writes:
> > I'm not sure whether multi-tenant applications fall into the category
where
> > LEAKPROOFness isn't considered important, since security is typically a
key
> > concern for users of such systems.
> Yeah, ISTM that you might as we
On Thu, Jun 19, 2025 at 6:00 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Wed, Jun 18, 2025 at 03:22:59PM +0530, shveta malik wrote:
> > On Wed, Jun 18, 2025 at 2:39 PM Bertrand Drouvot
> > wrote:
> > >
> > > IIUC the idea is to "just" increase WAL level to 'logical' so that one
> > > could then
>
Hello hackers,
While exploring some data cleanup and transformation in old data I stumbeld
over $topic:
In a set of data (selected by season=23) I want to determine the min and max
value of an order number (of_fac_order_n) for all occuring factories
(am_fac_code).
I defined an external wi
On Mon, Jun 23, 2025 at 09:04:15AM +0200, Anthonin Bonnefoy wrote:
> Since the consensus seems to lean toward \close_prepared, I've
> prepared the patch to rename the command.
This renaming patch looks correct to me. I am not seeing any missing
references of \close remaining, including APIs, comm
On Mon, 23 Jun 2025 at 03:37, Tatsuo Ishii wrote:
> And I found "Author" column is shown as "+4207-35" which does not seem
> to be an author name. Likewise followings columns seem to show
> inappropriate contents.
Thanks for the report. That's fixed now (it was missing a header
column for the new
On Mon, 23 Jun 2025 at 09:40, Michael Paquier wrote:
>
> On Mon, Jun 23, 2025 at 09:04:15AM +0200, Anthonin Bonnefoy wrote:
> > Since the consensus seems to lean toward \close_prepared, I've
> > prepared the patch to rename the command.
>
> This renaming patch looks correct to me. I am not seeing
On Fri, Jun 20, 2025 at 4:48 PM Zhijie Hou (Fujitsu)
wrote:
>
> Here is the V39 patch set which includes the following changes:
>
1.
-static void
-create_conflict_slot_if_not_exists(void)
+void
+ApplyLauncherCreateConflictDetectionSlot(void)
I am not so sure about adding ApplyLauncher in front o
On Tue, Jun 17, 2025 at 3:55 PM John Naylor wrote:
> > > Replacing that with _mm512_zextsi128_si512 fixes the problem.
>
> Here's a patch for testing, which also reverts the previous
> workaround.
Pushed, thanks everyone!
--
John Naylor
Amazon Web Services
On Wed, Jun 11, 2025 at 1:49 PM Shinya Kato wrote:
> On Thu, Jun 5, 2025 at 3:53 AM Sami Imseih wrote:
>
>> > Approach 2:
>> > - log_autovacuum_min_duration: Changed behavior, which controls only
>> > autovacuum logging.
>> > - log_autoanalyze_min_duration: New parameter, which controls
>> > aut
On Sun, Jun 22, 2025 at 10:23 PM Nikolay Samokhvalov
wrote:
>
> On Wed, May 28, 2025 at 11:43 AM J. Javier Maestro
> wrote:
>
>> On Wed, May 28, 2025 at 6:08 PM Andres Freund wrote:
>>
> ...
>
>> Do you want to write a patch like that? Otherwise I can.
>>>
>>
>> Sure, I've attached the new patc
On Thu, Jun 12, 2025 at 1:16 AM Masahiko Sawada wrote:
> Related to this, I
> realized that TidStoreSetBlockOffsets() checks if the given offset
> number is a valid OffsetNumber
To be specific, it does not check for OffsetNumberIsValid, it checks
that the offset can actually be stored in TidStore
On Fri, Jun 20, 2025 at 9:45 PM Melanie Plageman
wrote:
> So, I think I figured out why I was seeing the test hang waiting for
> pg_stat_progress_vacuum to report an index count.
>
> Using auto_explain, I determined that the cursor was using an index-only scan
> with lower row counts. That mean
Hi,
While adding parsing of logical replication to Wireshark[1], I've
found the Stream Abort description possibly misleading. Stream Abort
will have the Abort LSN and TS when parallel streaming is enabled.
However, the documentation only mentions "This field is available
since protocol version 4"
Hi Arseniy,
Thanks for the feedback!
> Now it affects 4 times more files (380). What I noticed:
> 1) Most of the comments are bordered comments like this:
> -/*
>
> +/*
> + *
> -
On Mon, Jun 23, 2025 at 1:41 PM Masahiko Sawada wrote:
>
> Given the discussion so far, it seems we might want to have a
> safeguard to prevent the effective_wal_level from being dropped to
> 'replica' if the last logical slot is accidentally dropped.
Yes, needed for cases where standby or cascad
Hi,
On Mon, Jun 23, 2025 at 05:10:37PM +0900, Masahiko Sawada wrote:
> On Thu, Jun 19, 2025 at 6:00 PM Bertrand Drouvot
> wrote:
> >
> > - pg_activate_logical_decoding() is needed only if there is not already a
> > logical
> > slot on the primary
> > - the drop requires the user to think twice i
On Fri, Jun 20, 2025 at 12:15 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Fri, Jun 20, 2025 at 09:48:47AM +0530, shveta malik wrote:
> > On Thu, Jun 19, 2025 at 2:30 PM Bertrand Drouvot
> > wrote:
> > >
> > > I wonder if a way to address the concerns that we shared above is to use a
> > > mixed app
>
> Here is the V39 patch set which includes the following changes:
>
Few trivial comments:
1)
Currently we have this error and detail:
ERROR: Enabling retain_conflict_info requires "wal_level" >= "replica"
DETAIL: A replication slot must be created to retain conflict information.
Shall we ch
I deployed support for the ability to use tags in the commitfest app a
few hours ago. How exactly we want to use them is up to the community
at this point, but that seems hard to align on without people trying a
few things out.
That's why I added some tags to the patches on my dashboard. It would
Attached are some improvements to include/common/int128.h, including
some new functions that allow it to be used more widely in numeric.c.
In particular, this allows various aggregates to use 128-bit integers
regardless of whether they're natively supported, which should improve
the performance on
On Mon, 23 Jun 2025 at 09:43, Andreas Lind
wrote:
>
> Thanks for your replies!
>
> Tom Lane wrote:
> > Yugo Nagata writes:
> > > I'm not sure whether multi-tenant applications fall into the category
> > > where
> > > LEAKPROOFness isn't considered important, since security is typically a
> > >
On Thu, 19 Jun 2025 at 09:09, Michael Paquier wrote:
> > I think I still prefer \bind_named or maybe \bindnamed (depending on
> > what our policy for underscores in \ commands is).
>
> Not sure that there is such a policy in place. I find names with
> underscores easier to parse.
I just double c
On Thu, Jun 19, 2025 at 9:09 AM Michael Paquier wrote:
> Good point. I would be on board with a \close_prepared then, if
> that's the consensus we reach, without touching at \bind_named. We
> still have time to decide on the name until the release, just let's
> make sure to not do a rename multi
95 matches
Mail list logo
