On Sat, Apr 26, 2025, at 05:10, Tom Lane wrote:
> "Joel Jacobson" writes:
>> For years, I've felt we could benefit from introducing convenience syntax to
>> explicitly require that exactly one row is affected by a query, something
>> which
>> currently requires using a somewhat cumbersome work
Bertrand Drouvot writes:
> While working on wait events I faced some compilation issues due to circular
> header file dependency (introduced in fa88928470b5) between wait_event.h and
> wait_event_types.h.
Ugh. I still carry the scars of cleaning up after a previous
circular-inclusion mess (cf 16
On Fri, Apr 25, 2025 at 3:36 AM Alvaro Herrera wrote:
>
> On 2025-Apr-09, jian he wrote:
>
> > hi.
> >
> > attached patch is for address pg_dump inconsistency
> > when parent is "not null not valid" while child is "not null".
>
> Here's my take on this patch. We don't really need the
> notnull_pa
Hi hackers,
While working on wait events I faced some compilation issues due to circular
header file dependency (introduced in fa88928470b5) between wait_event.h and
wait_event_types.h. Those files have include guards but could still lead to
compilation issues in some cases due to the circular dep
"Joel Jacobson" writes:
> For years, I've felt we could benefit from introducing convenience syntax to
> explicitly require that exactly one row is affected by a query, something
> which
> currently requires using a somewhat cumbersome workaround:
> - Using `... INTO STRICT ...` for `SELECT`,
>
On Sat, Apr 26, 2025, at 06:44, Tom Lane wrote:
> This is a rather delayed response to the discussion of bug
> #18693 [1], in which I wrote:
...
> which is pretty bogus because the record *does* have a field
> named "strict". The actual problem is that STRICT is a fully
> reserved PL/pgSQL keyword
On Tue, Apr 8, 2025 at 7:48 AM Hannu Krosing wrote:
> Just to bring this out separately : Does anybody have any idea why pipe
> commands close inside tests ?
>
> Re: 003-pg_dump_basic_tests has a few basic validation tests for
> correctmflag combinations. We need to write more automated tests in
On Sat, Apr 26, 2025 at 5:43 AM Tom Lane wrote:
> Andres Freund writes:
> > It's kinda sad to not have any test that tests a larger
> > io_combine_limit/io_max_combine_limit - as evidenced by this bug that'd be
> > good. However, not all platforms have PG_IOV_MAX > 16, so it seems like it'd
> > b
Thanks for testing. I also tested it a bit more today with other
patterns like different fetch sizes, named portal, etc. and I can't
find an issue with this, but I could be missing something.
I will go ahead and attach this change in patch form.
--
Sami Imseih
Amazon Web Services (AWS)
v4-Corre
This is a rather delayed response to the discussion of bug
#18693 [1], in which I wrote:
> (It's kind of annoying that "strict" has to be double-quoted
> in the RAISE NOTICE, especially since you get a rather misleading
> error if it isn't. But that seems like a different discussion.)
As an exam
Hi,
In the original thread [0] we established that GIST and SP-GiST
support index-only scans, but don't have sufficient interlocking to
prevent dead tuples from being revived for their scan by vacuum. As
that thread already contains a lot of detail, I won't go into the
specifics here, but the gist
On Fri, Apr 25, 2025 at 4:13 PM David E. Wheeler wrote:
>
> On Apr 25, 2025, at 09:25, Matheus Alcantara wrote:
>
> > Yes, you are right. The problem was where I was asserting
> > control->control_dir != NULL. I've moved the assert after the "if
> > (!filename)" check that returns an error if the
On Fri, Apr 25, 2025 at 2:03 AM Christoph Berg wrote:
> My point is that we should be trying to change the ABI-as-coded-in-the-
> filename as rarely as possible.
I agree, but I'm also trying to say I can't unilaterally declare
pieces of our internal structs to be covered by an ABI guarantee.
Mayb
Hi,
On 2025-04-25 13:37:15 -0400, Tom Lane wrote:
> Whilst poking at Erik Rijkers' nearby report, I found that
> Fedora 42's gcc 15.0.1 will produce this complaint if you
> select optimization level -O3:
>
> In file included from ../../../../src/include/access/htup_details.h:22,
>
Hi,
On 2025-04-20 14:53:39 -0700, Noah Misch wrote:
> On Mon, Apr 14, 2025 at 09:19:35AM +0900, Michael Paquier wrote:
> > On Sun, Apr 13, 2025 at 11:51:57AM -0400, Tom Lane wrote:
> > > Noah Misch writes:
> > > > Tom and Michael, do you still object to the test addition, or not? If
> > > > the
On Apr 25, 2025, at 07:33, Christoph Berg wrote:
>
> Re: David E. Wheeler
>> +
>> +make install prefix=/etc/postgresql
>
> I'd use /usr/local/postgresql there. "/etc" is just wrong.
Thank you for the review. Here’s v3*.
Best,
David
* Also reviewable as a GitHub PR[1].
[1]: https://github.co
On Thu, Apr 24, 2025 at 3:16 PM Jelte Fennema-Nio wrote:
> Why is this dangerous? As long as we'd validate that the provided cert
> by the server is for example.com
I can't help but read this as "as long as everyone mitigates the
danger, what's the danger?" We won't be the only implementers of an
On Apr 25, 2025, at 09:25, Matheus Alcantara wrote:
> Yes, you are right. The problem was where I was asserting
> control->control_dir != NULL. I've moved the assert after the "if
> (!filename)" check that returns an error if the extension was not found.
>
> Attached v3 with this fix and also a
On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut wrote:
> Another detail to think about is how this affects psql -h localhost. In
> principle, this should require full SSL, but you're probably not going
> to have certificates that allow "localhost". And connections to
> localhost are the default
I wrote:
> Anybody have an idea about how to silence it more effectively?
> There are going to be more people seeing this as gcc 15 propagates.
Meh. I tried this:
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index bb99781c56e..ea489db89c9 100644
--- a/src/pl/plpgsql/s
On Fri, Apr 25, 2025 at 4:42 AM Amit Kapila wrote:
>
> On Fri, Apr 25, 2025 at 10:46 AM Masahiko Sawada
> wrote:
> >
> > What I'm concerned about is the back branches. With this approach all
> > back branches will have such degradations and it doesn't make sense to
> > me to optimize SnapBuildCo
Hi,
On Fri, Apr 25, 2025 at 9:10 AM Fujii Masao wrote:
>
> Hi,
>
> While reading the code of logicalrep_worker_launch(), I had two questions:
>
> (1)
> When the sync worker limit per subscription is reached,
> logicalrep_worker_launch()
> runs garbage collection to try to free up slots before ch
Andres Freund writes:
> It's kinda sad to not have any test that tests a larger
> io_combine_limit/io_max_combine_limit - as evidenced by this bug that'd be
> good. However, not all platforms have PG_IOV_MAX > 16, so it seems like it'd
> be somewhat painful to test?
Maybe just skip the test if th
Whilst poking at Erik Rijkers' nearby report, I found that
Fedora 42's gcc 15.0.1 will produce this complaint if you
select optimization level -O3:
In file included from ../../../../src/include/access/htup_details.h:22,
from pl_exec.c:21:
In function 'assign_simple_var',
inli
Hi,
On 2025-04-25 10:26:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > void
> > assign_io_max_combine_limit(int newval, void *extra)
> > {
> > io_max_combine_limit = newval;
> > io_combine_limit = Min(io_max_combine_limit, io_combine_limit_guc);
> > }
> > void
> > assign_io_combine
Sami Imseih wrote:
> > pgstat_progress_start_command() is called twice: First with
> > cmdtype=PROGRESS_COMMAND_CLUSTER, second with
> > PROGRESS_COMMAND_CREATE_INDEX. The first happens in cluster_rel() the second
> > in cluster_rel() -> rebuild_relation() -> finish_heap_swap() ->
> > reindex_rel
Erik Rijkers writes:
> Compiling gcc 15.1 utters these protests (at least, with
> --enable-cassert) that I don't think I saw with gcc 14:
Hmm, odd. I tried with gcc 15.0.1 from a fresh Fedora 42 install,
and I can reproduce your result:
jsonb_util.c: In function 'compareJsonbContainers':
jsonb
On Wed, Apr 9, 2025 at 2:47 PM Matthias van de Meent
wrote:
>
> Hi,
>
> With PG16, we got Index AM -level indications for summarizing indexes,
> improving HOT applicability.
>
> Given that these indexes explicitly never store TIDs and thus don't
> really need the cleanup part of vacuum's index cle
Hi,
On 2025-04-15 21:00:00 +0300, Alexander Lakhin wrote:
> Please take a look also at the simple reproducer for the crash inside
> pg_get_aios() I mentioned upthread:
> for i in {1..100}; do
> numjobs=12
> echo "iteration $i"
> date
> for ((j=1;j<=numjobs;j++)); do
> ( createdb db$j;
On Fri, Apr 25, 2025 at 3:43 AM Amit Kapila wrote:
>
> On Fri, Apr 25, 2025 at 6:02 AM Masahiko Sawada wrote:
> >
> > I realized that users who create a logical slot using
> > pg_create_logical_replication_slot() would not be able to enable both
> > options at slot creation, and there is no easy
Hi,
I’ve been trying to review this patch, and it struck me that we’re
currently grabbing the content lock exclusively just to flip a header bit:
if (!(buf_state & BM_DIRTY))
{
LWLockAcquire(BufferDescriptorGetContentLock(desc), LW_EXCLUSIVE);
MarkBufferDirty(buf);
LWLockRelease(Buffer
Hi,
While reading the code of logicalrep_worker_launch(), I had two questions:
(1)
When the sync worker limit per subscription is reached,
logicalrep_worker_launch()
runs garbage collection to try to free up slots before checking the limit again.
That makes sense.
But should we do the same whe
Hi!
I agree it is a good idea to shift the table list. Although vacuuming
larger tables first
is a questionable approach because smaller ones could wait a long time to
be vacuumed.
It looks like the most obvious and simple way is that the first table to be
vacuumed
should not be the first one from
Hi Michael,
Thanks for the suggestions. I agree that we should first solve the
“last–free-bit” problem in varattrib_4b compression bits before
layering on any features. Below is the approach I’ve prototyped to
keep the header compact yet fully extensible, followed by a sketch of
the plain-ZSTD(no
On 4/25/25 11:16, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-04-24 16:01:
On 3/28/25 09:19, Alexander Pyhalov wrote:
In the attachment, see the patch written according to the idea. There
are I introduced two new routines:
get_cheapest_path_for_pathkeys_ext
get_cheapest_fractional_p
Hi,
Compiling gcc 15.1 utters these protests (at least, with
--enable-cassert) that I don't think I saw with gcc 14:
jsonb_util.c: In function ‘compareJsonbContainers’:
jsonb_util.c:301:34: warning: ‘va.type’ may be used uninitialized
[-Wmaybe-uninitialized]
301 |
Hi，I like your idea，It would be even better if the weights could be taken
according to the larger tables
On Fri, 25 Apr 2025 at 22:03, Junwang Zhao wrote:
> Hi hackers,
>
> After watching Robert's talk[1] on autovacuum and participating in the
> related
> workshop yesterday, it appears that peop
Hi there,
There is an issue with the existing placement of `XACT_EVENT_COMMIT` in
`CommitTransaction()`. The place where it is called now (and has been
called for many versions before) is a bit too early – it occurs at a time
when other backends might not be able to see what this backend has
commi
Andres Freund writes:
> void
> assign_io_max_combine_limit(int newval, void *extra)
> {
> io_max_combine_limit = newval;
> io_combine_limit = Min(io_max_combine_limit, io_combine_limit_guc);
> }
> void
> assign_io_combine_limit(int newval, void *extra)
> {
> io_combine_limit_guc
Hi,
On 2025-03-18 16:18:17 +1300, Thomas Munro wrote:
> Here's a new version that also adjusts the code that just landed in
> da722699:
Something isn't quite right with this code. If I just add -c
io_combine_limit=32 to the options and do a seqscan, I get odd
failures. Mostly assertion failures
> On 25 Apr 2025, at 15:40, George MacKerron wrote:
>
>> On 25 Apr 2025, at 13:53, Daniel Gustafsson wrote:
>>>
(2) sslrootcert=system on Windows doesn’t do a thing that would be
extremely useful in some common situations. Namely: connecting securely to
servers that present a c
Hi hackers,
After watching Robert's talk[1] on autovacuum and participating in the related
workshop yesterday, it appears that people are inclined to use prioritization
to address the issues highlighted in Robert's presentation. Here I list two
of the failure modes that were discussed.
- Spinning
On 4/24/25 20:12, Michael Paquier wrote:
On Thu, Apr 24, 2025 at 03:34:29PM +, David Steele wrote:
Having said that, I think these tests are awfully expensive for a single
GUC. Unit tests would definitely be preferable but that's not an option for
GUCs, so far as I know.
On my laptop, 003
On Mon, Dec 16, 2024 at 7:50 PM Nishant Sharma
wrote:
>
>
> 1) The new switch logic does not look correct to me. It will pass for
> a failing scenario. I think you can use v3's logic instead with below
> changes:-
>
> a)
> while (HeapTupleIsValid(atup = systable_getnext(ascan))) -->
> while (HeapT
> On 25 Apr 2025, at 13:53, Daniel Gustafsson wrote:
>>
>>> (2) sslrootcert=system on Windows doesn’t do a thing that would be
>>> extremely useful in some common situations. Namely: connecting securely to
>>> servers that present a certificate signed by a public CA.
>>
>> Just to be clear, do
On Thu, Apr 24, 2025 at 7:27 PM David E. Wheeler wrote:
>
> On Apr 24, 2025, at 11:18, Matheus Alcantara wrote:
>
> > In v2 I've moved the logic to remove the /extension to
> > parse_extension_control_file(), do you think that this Assert on this
> > function would still be wrong? IIUC we should
> On 25 Apr 2025, at 00:16, Jelte Fennema-Nio wrote:
> Let me derail some more, while we're at it I think it would be good to
> add tls-prefixed aliases for all our ssl options. Like tlscert/tlskey.
> Since such a new postgress:// scheme would be totally new, maybe we
> can even disallow the ssl
> On 3 Apr 2025, at 16:26, Daniel Gustafsson wrote:
>
>> On 3 Apr 2025, at 14:41, George MacKerron wrote:
>
>> (2) sslrootcert=system on Windows doesn’t do a thing that would be extremely
>> useful in some common situations. Namely: connecting securely to servers
>> that present a certificate
On Sat, Mar 29, 2025 at 8:37 AM Srinath Reddy wrote:
> i have naive doubt $SUBJECT,AFAIK The reasoning would be this function is
> designed to silently filter out \n and \r while still producing a usable
> shell-safe argument. It informs the caller of the issue (false return value)
> but does n
Hi,
I've updated the patch set. See the attached v40 patch set.
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 23 Apr 2025 23:44:55 -0700,
Masahiko Sawada wrote:
>> Are the followings correct?
>>
>> 1. Move invalid input patterns in
>>src/test/mod
> On Fri, 25 Apr 2025 at 12:22, George MacKerron wrote:
>> I know the documentation has now been changed to reflect that ‘system’
>> actually means OpenSSL.
>
> I didn't realize that. I'm definitely not in favor of that doc change.
> It's describing behaviour that I believe is incorrect, as if
On Thu, Apr 24, 2025 at 3:57 PM shveta malik wrote:
>
> On Thu, Apr 24, 2025 at 2:54 PM Nisha Moond wrote:
> >
> > Please find the updated patch for Approach 3, which implements the
> > idea suggested by Swada-san above.
> >
>
> Thank You for the patch.
>
> 1)
>
> CreateDecodingContext:
>
> if
On Fri, 25 Apr 2025 at 12:22, George MacKerron wrote:
> I know the documentation has now been changed to reflect that ‘system’
> actually means OpenSSL.
I didn't realize that. I'm definitely not in favor of that doc change.
It's describing behaviour that I believe is incorrect, as if it's
actual
On Fri, Apr 25, 2025 at 10:46 AM Masahiko Sawada wrote:
>
> What I'm concerned about is the back branches. With this approach all
> back branches will have such degradations and it doesn't make sense to
> me to optimize SnapBuildCommitTxn() codes in back branches.
>
One possibility could be that
Re: David E. Wheeler
> +
> +make install prefix=/etc/postgresql
I'd use /usr/local/postgresql there. "/etc" is just wrong.
> +
> +This will install the control SQL files into
> +/etc/postgresql/share and shared modules into
> +/etc/postgresql/lib. If the prefix does not
> +include
> On Thu, 24 Apr 2025 at 23:52, Jelte Fennema-Nio wrote:
>
>> How about we add a *compile time*
>> option that allows the person that compiles libpq to choose which cert
>> store it should use if sslrootcert=system is provided. Something like
>> --system-cert-store=openssl and --system-cert-store
While reading the CREATE OPERATOR docs around prefix operators, I noticed
a few places that could be improved.
Christoph
>From 478aeea4fe44c9c3462aaf18dbf04a6ed6f74ebc Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri, 25 Apr 2025 12:46:36 +0200
Subject: [PATCH v1] doc: Some copy-editing ar
On Fri, Apr 25, 2025 at 6:02 AM Masahiko Sawada wrote:
>
> I realized that users who create a logical slot using
> pg_create_logical_replication_slot() would not be able to enable both
> options at slot creation, and there is no easy way to enable the
> failover after two_phase-enabled-slot creati
>
> Here is V30 patch set includes the following changes:
>
Thank You for the patch, please find few concerns:
1)
By looking at code of ApplyLauncherMain(), it appears that we stopped
advancing shared-slot's xmin if any of the subscriptions with
retain_conflict_info is disabled. If a subscription
> On 24 Apr 2025, at 18:45, Jacob Champion
> wrote:
>
> On Wed, Apr 23, 2025 at 8:47 AM George MacKerron
> wrote:
>> I’d suggest two new special sslrootcert values:
>>
>> (1) sslrootcert=openssl
>>
>> This does exactly what sslrootcert=system does now, but is less confusingly
>> named fo
On Thu, Apr 24, 2025 at 11:10 PM Tom Lane wrote:
>
> I think it's up to the user to rename subsidiary objects if
> they wish to do so.
>
I absolutely agree.
--
Best Wishes,
Ashutosh Bapat
Andrei Lepikhov писал(а) 2025-04-24 16:01:
On 3/28/25 09:19, Alexander Pyhalov wrote:
Andy Fan писал(а) 2024-10-17 03:33:
I've updated patch. One more interesting case which we found - when
fractional path is selected, it still can be more expensive than
sorted cheapest total path (as we look
On Fri, Apr 25, 2025 at 10:45 AM Shlok Kyal wrote:
>
> In the commits, I saw that the filenames are misspelled for files
> invalidation_distrubution.out and invalidation_distrubution.spec.
> This is present in branches from REL_13 to HEAD. I have attached
> patches to fix the same.
>
Thanks for s
Re: Jacob Champion
> I think the system is overconstrained at that point. If you want to
> support clients that delay-load the ABI they're compiled against,
> _and_ have them continue to work seamlessly after the system has
> upgraded the ABI underneath them, without restarting the client... is
> t
On 2025-Apr-23, Nathan Bossart wrote:
> This one was briefly discussed in an RMT meeting.
>
> On Wed, Apr 09, 2025 at 01:16:20PM +0800, jian he wrote:
> > attached patch is for address pg_dump inconsistency
> > when parent is "not null not valid" while child is "not null".
>
> I see an open item
65 matches
Mail list logo
