Hi,
On Wed, Dec 18, 2024 at 02:56:24PM -0600, Nathan Bossart wrote:
> Here is what I have staged for commit.
Thanks!
A few comments:
=== 1
+ if (pwdlen < min_password_length)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("pa
I have reviewed v21-0001 again.
v21-0001-Introduce-CopyFormat-and-replace-csv_mode-and-binary.patch
is a good refactor.
overall looks good to me.
On Thu, 12 Dec 2024 at 19:20, RECHTÉ Marc wrote:
>
> Hi,
>
> Thanks for sharing the test case.
> Unfortunately I donot have a powerful machine which would generate
> such large number of spill files. But I created a patch as per your
> suggestion in point(2) in thread [1]. Can you test with this p
On Thu, 19 Dec 2024 at 15:44, Tom Lane wrote:
>
> With David's recent fixes to allow telling BuildTupleHashTableExt
> what input slot type to expect, it's possible to remove the per-row
> slot type conversions I was doing before. So here's an updated
> patchset with that done.
>
> The common_resu
On Thu, Dec 19, 2024 at 1:00 AM Masahiko Sawada wrote:
>
> On Tue, Dec 17, 2024 at 11:12 PM John Naylor wrote:
> > +1 in general, but I wonder if instead the iter_context should be
> > created within RT_BEGIN_ITERATE -- I imagine that would have less
> > duplication and would be as safe, but I ha
hi.
generally COPY TO``COPY table`` is faster than ``COPY (select * from table)``.
in BeginCopyTo. we have
"""
else if (rel->rd_rel->relkind == RELKIND_MATVIEW)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot copy fro
Hi,
On Thu, Dec 19, 2024 at 01:21:54PM +0900, Michael Paquier wrote:
>
> While doing more tests with backends exiting concurrently with their
> stats scanned, I have detected one path in pg_stat_get_backend_io()
> after calling pgstat_get_beentry_by_proc_number() where we should also
> check that
Hi,
On Wed, Dec 18, 2024 at 11:55:11AM -0500, Andres Freund wrote:
> Yea, i think it's fine to just call it unnecessarily. Particularly because we
> do want to actually report IO stats for walwriter eventually.
Yeah, better to spend time and energy on making it "necessary" instead: I'll
try to ha
On Tue, Dec 17, 2024 at 06:01:39PM +0100, Tomas Vondra wrote:
> I also considered introducing pg_stat_statements-style versioning, but
> it's too late to do that in backbranches, and I don't think we expect
> the function to change very often to justify this.
Sounds good to me, thanks!
--
Michael
On Wed, Dec 18, 2024 at 08:51:20PM -0500, Andres Freund wrote:
> I don't think the issue is actually quite as unlikely to be hit as reasoned in
> the commit message. The crash has indeed to happen between the link() and
> unlink() - but at the end of a checkpoint we do that operations hundreds of
On Wed, Dec 18, 2024 at 08:11:55AM +, Bertrand Drouvot wrote:
> I think I prefer pg_stat_io_build_tuples() and used that name in v11
> attached.
I'll rely to your naming sense than mine, then :D
> I think that this comment is now confusing since the extra loop would be
> done in pg_stat_io_bu
On Wed, 18 Dec 2024 at 00:15, Euler Taveira wrote:
>
> Hi,
>
> Sometimes you need to inspect some debug messages from autovacuum worker but
> you cannot apply the same setting for backends (that could rapidly fill the
> log
> file). This proposal aims to change log_min_messages to have different
On Wed, 18 Dec 2024 at 23:42, John Naylor wrote:
> The difference is small enough that normally I'd say it's likely
> unrelated to the patch, but on the other hand it's consistent with
> saving (3 * 10 * 10 million) cycles because of 1 less multiplication
> each, which is not nothing, but for shov
On Thu, Dec 19, 2024 at 7:10 AM Anton A. Melnikov
wrote:
> Found that
> https://github.com/postgres/postgres/commit/0aba2554409ee3251d7558567edd114d8ed36dcc
> produces a valgrind error in initdb.
What architecture and valgrind version is this? We've been bitten
before by different results on Arm
On Thu, Dec 19, 2024 at 8:18 AM Melanie Plageman
wrote:
> I pushed the straightforward option for now so that it's fixed.
I think this binary search code now has a risk of underflow. If 'mid'
is calculated as zero, the second 'if' branch will cause 'end' to
underflow.
Maybe we need to do someth
With David's recent fixes to allow telling BuildTupleHashTableExt
what input slot type to expect, it's possible to remove the per-row
slot type conversions I was doing before. So here's an updated
patchset with that done.
The common_result_slot_type() function I wrote here perhaps
should be made
On Tue, Dec 17, 2024 at 04:47:31PM -0500, Andres Freund wrote:
> On 2024-12-17 15:32:06 -0600, Nathan Bossart wrote:
>> Committed.
>
> Thanks!
Thanks, Nathan!
--
Michael
signature.asc
Description: PGP signature
On Thu, Dec 19, 2024 at 07:50:57AM +0530, Amit Kapila wrote:
> The difference between fix_memory_leak_v2 and fix_memory_leak_v3 is
> that the earlier one resets the pubctx to NULL along with freeing the
> context memory. Resetting a file-level global variable is a good idea,
> similar to what we do
On Wed, Dec 18, 2024 at 12:32 PM Masahiko Sawada wrote:
>
> On Tue, Dec 17, 2024 at 2:48 AM Amit Kapila wrote:
> >
> >
> > Will fix_memory_leak_v3.patch avoid the leak in case of an ERROR in
> > SQL API? If so, how?
>
> The pubctx is created as a child of LogicalDecodingContext->context.
> On an
Hi,
On 2024-12-18 10:38:19 -0600, Nathan Bossart wrote:
> On Tue, Dec 17, 2024 at 04:50:16PM -0800, Robert Pang wrote:
> > We recently observed a few cases where Postgres running on Linux
> > encountered an issue with WAL segment files. Specifically, two WAL
> > segments were linked to the same ph
On Mon, Dec 9, 2024 at 9:09 PM Amit Kapila wrote:
>
> On Tue, Nov 26, 2024 at 3:03 AM Masahiko Sawada wrote:
> >
> > I've attached a new version patch that incorporates all comments I got so
> > far.
> >
>
> Review comments:
Thank you for reviewing the patch!
> ===
> 1.
> + * The g
Richard Guo writes:
> I see. I didn't notice any real issues with that; I was just flagged
> by the XXX comment there, which raises the question of whether it's
> worth working harder to determine the inputOps.
I was intending to add some code to my nodeSetop patch to see if
both input plan node
On Thu, Dec 19, 2024 at 8:10 AM Tom Lane wrote:
> David Rowley writes:
> > I propose to quickly do a master-only follow-up commit to use the
> > inputOps instead of NULL in BuildTupleHashTableExt (Basically Tom's
> > patch from [1])
>
> LGTM.
+1.
Thanks
Richard
On Wed, Dec 18, 2024 at 7:45 PM David Rowley wrote:
> On Wed, 18 Dec 2024 at 22:29, Richard Guo wrote:
> > Should we be concerned about passing a NULL TupleTableSlotOps in
> > nodeRecursiveUnion.c?
>
> I made it pass NULL on purpose because the slot type on the recursive
> union can be different
Hi!
Found that
https://github.com/postgres/postgres/commit/0aba2554409ee3251d7558567edd114d8ed36dcc
produces a valgrind error in initdb.
Such a steps:
CPPFLAGS="-DUSE_VALGRIND -Og" ./configure --enable-debug --enable-tap-tests
--enable-cassert --with-icu
make ...
valgrind --quiet --exit-on-fir
Hi Vignesh,
Here are some review comments for the patch v20241211-0003.
==
src/backend/replication/logical/syncutils.c
1.
+typedef enum
+{
+ SYNC_RELATIONS_STATE_NEEDS_REBUILD,
+ SYNC_RELATIONS_STATE_REBUILD_STARTED,
+ SYNC_RELATIONS_STATE_VALID,
+} SyncingRelationsState;
+
Even though the
On Wed, Dec 18, 2024 at 3:13 PM Melanie Plageman
wrote:
>
> option 1:
> most straightforward fix
>
> diff --git a/src/backend/access/heap/heapam_handler.c
> b/src/backend/access/heap/heapam_handler.c
> index d0e5922eed7..fa03bedd4b8 100644
> --- a/src/backend/access/heap/heapam_handler.c
> +++ b/s
David Rowley writes:
> On Wed, 18 Dec 2024 at 23:45, David Rowley wrote:
>> Maybe we need to backpatch passing NULL instead of &TTSOpsMinimalTuple
>> to ExecBuildGroupingEqual() in BuildTupleHashTableExt(). Something
>> like the attached patch.
> I've attached a more formal patch for this and I'
BTW, I did a little bit of performance testing using current OpenBSD
(7.6), and it looks like they partially fixed the performance issues
I saw with their named POSIX semaphores back in 2021. "pgbench -S"
seems to show TPS rates right about on par with a SysV-sema build.
There is still a measurabl
On Wed, 18 Dec 2024 at 23:45, David Rowley wrote:
> Maybe we need to backpatch passing NULL instead of &TTSOpsMinimalTuple
> to ExecBuildGroupingEqual() in BuildTupleHashTableExt(). Something
> like the attached patch.
I've attached a more formal patch for this and I've also now done a
bit more r
On Tue, Dec 17, 2024 at 5:54 PM Melanie Plageman
wrote:
> Makes sense. I've attempted to clarify as you suggest in v3.
I would just commit 0001. There's nothing to be gained by waiting around.
I don't care about 0002 much. It doesn't seem particularly better or
worse. I would suggest that if you
Here is what I have staged for commit.
--
nathan
>From 537260d0492ad3bda2c2fcbfd00c6b0511f5e1b5 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 18 Dec 2024 14:49:20 -0600
Subject: [PATCH v10 1/1] Add passwordcheck.min_password_length.
This new parameter can be used to change the minimu
On Wed, 2024-12-18 at 14:55 -0500, Tom Lane wrote:
> It would not actually be too
> hard I think to build the right regex, if we had the information
> available as to what all the case-variants are. The problem at the
> moment is that the existing code assumes that pg_wc_tolower and
> pg_wc_toupper
Michel Pelletier writes:
> My bad, sorry for the long confusing email, I figured out that I was
> calling the wrong macro when getting my matrix datum and inadvertently
> expanding RO pointers as well, I've fixed that issue, and everything is
> working great! No extra expansions and my support fu
Attached test case shows a wrong answer bug affecting Postgres 17 and
the master branch/18 devel. My nbtree SAOP commit (commit 5bf748b8) is
to blame. The conditions under which the bug can produce incorrect
behavior are rather narrow (more on those details below).
Attached fix addresses the issue
On Wed, Dec 18, 2024 at 1:23 PM Ranier Vilela wrote:
>
> Hi.
>
> Em qua., 18 de dez. de 2024 às 14:01, Melanie Plageman
> escreveu:
>>
>> For now, I've committed the version of the patch I proposed above (v3).
>
> What happens if *rs_tuples* equal to zero in function
> *SampleHeapTupleVisible*?
Jeff Davis writes:
> On Mon, 2024-12-16 at 17:16 -0500, Tom Lane wrote:
>> The existing logic in the regex engine for case-insensitive matching
>> is to convert every letter to a bracket expression containing all
>> its case variants. For example, "a" becomes "[aA]" and "[xY1]"
>> becomes "[xXyY1
On Wed, 2024-12-18 at 08:26 +0100, Laurenz Albe wrote:
> Yes, that approach seems strange.
My thought was it would be more like a client option than anything
else: a way for the application to request the same result in a more
convenient order. A bit strange, but depending on how you look at it,
i
On 12/18/24 10:42 AM, Peter Eisentraut wrote:
I can fix that with the attached patch.
The symbol YY_TYPEDEF_YY_SCANNER_T isn't documented, but we already use
it elsewhere in the code.
Note that in replication/syncrep.h and replication/walsender_private.h
we have to have an #ifndef wrapper be
On Mon, 2024-12-16 at 16:27 -0500, Joe Conway wrote:
>
> SQL 2023 seems to include the NORMALIZE syntax, but the only case
> folding considered is UPPER and LOWER. As such, I think it ought to
> be a
> function but not part of the grammar.
Should the standard support something like the Unicode
On Mon, 2024-12-16 at 17:16 -0500, Tom Lane wrote:
> Yeah, there is some set of collations for which that would work.
> But I think it requires nontrivial assumptions both about how
> comparison works in the collation, and whether the available
> case-folding logic matches that. An important point
On Wed, 18 Dec 2024 at 16:34, Artur Zakirov wrote:
>
> On Tue, 17 Dec 2024 at 10:43, vignesh C wrote:
> > > If I understand your suggestion correctly I think this will break the
> > > "--exclude-schema" option of pg_dump. That change will dump all
> > > mappings between publications and schemas f
Hi.
Em qua., 18 de dez. de 2024 às 14:01, Melanie Plageman <
melanieplage...@gmail.com> escreveu:
> On Mon, Oct 28, 2024 at 2:27 AM Dilip Kumar wrote:
> >
> > On Sat, Oct 26, 2024 at 5:30 PM Melanie Plageman <
> melanieplage...@gmail.com> wrote:
> >>
> >> Yes, so in the case of backwards scan, i
On Tue, Dec 17, 2024 at 11:12 PM John Naylor wrote:
>
> On Wed, Dec 18, 2024 at 12:49 AM Masahiko Sawada
> wrote:
> >
> > Hi,
> >
> > I found that a server crashes due to a null-pointer-dereference if a
> > process attached to the shared radix tree begins an iteration on it,
> > because we don't
Andres Freund writes:
> On 2024-12-18 12:00:48 -0500, Tom Lane wrote:
>> NetBSD does, but they consume an FD per sema, which is actually worse
>> because the default max-open-files-per-process is none too large either.
> Doesn't seem that bad on netbsd 10. Via Bilal's netbsd CI patch, I get:
> #
Peter Eisentraut writes:
> I started committing the cube and seg pieces. There were a couple of
> complaints from the buildfarm, like
> segscan.c:348:15: error: redefinition of typedef 'yyscan_t' is a C11
> feature [-Werror,-Wtypedef-redefinition]
> typedef void* yyscan_t;
> ...
> (Also, we sho
Hi,
On 2024-12-18 12:00:48 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Maybe we should consider switching those platforms to unnamed posix
> > semaphores?
>
> I already looked into that. OpenBSD still doesn't have cross-process
> posix semaphores, at least according to its man page.
Ugh
On Mon, Oct 28, 2024 at 2:27 AM Dilip Kumar wrote:
>
> On Sat, Oct 26, 2024 at 5:30 PM Melanie Plageman
> wrote:
>>
>> Yes, so in the case of backwards scan, if scan->rs_cindex is 0, when
>> dir is -1, lineindex will wrap around, but we don't use it in that
>> case because linesleft will be 0 an
Andres Freund writes:
> Maybe we should consider switching those platforms to unnamed posix
> semaphores?
I already looked into that. OpenBSD still doesn't have cross-process
posix semaphores, at least according to its man page. NetBSD does,
but they consume an FD per sema, which is actually wo
Hi,
On 2024-12-18 15:53:39 +, Bertrand Drouvot wrote:
> On Wed, Dec 18, 2024 at 10:35:45AM -0500, Andres Freund wrote:
> > Hi,
> >
> > On 2024-12-18 15:14:07 +, Bertrand Drouvot wrote:
> > > While working on [1], it has been noticed that pgstat_flush_io() is
> > > called for
> > > the wal
Hi,
On 2024-12-18 11:23:23 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> >> After some testing and searching for documentation, it seems that at
> >> least the BSD platforms have a very low default semmns setting
> >> (apparently 60, which leads to max_connections=30).
>
> > The low semaph
On Tue, Dec 17, 2024 at 04:50:16PM -0800, Robert Pang wrote:
> We recently observed a few cases where Postgres running on Linux
> encountered an issue with WAL segment files. Specifically, two WAL
> segments were linked to the same physical file after Postgres ran out
> of memory and the OOM killer
Peter Eisentraut writes:
>>> * Why in the world is the default value of max_wal_senders 10?
> Here is where this change was originally discussed:
> https://www.postgresql.org/message-id/flat/CABUevEy4PR_EAvZEzsbF5s%2BV0eEvw7shJ2t-AUwbHOjT%2ByRb3A%40mail.gmail.com
Hmm. There was not a lot in th
Hi,
On Wed, Dec 18, 2024 at 10:35:45AM -0500, Andres Freund wrote:
> Hi,
>
> On 2024-12-18 15:14:07 +, Bertrand Drouvot wrote:
> > While working on [1], it has been noticed that pgstat_flush_io() is called
> > for
> > the walwriter. Indeed, it's coming from the pgstat_report_wal() call in
>
Hi,
On 2024-12-18 15:14:07 +, Bertrand Drouvot wrote:
> While working on [1], it has been noticed that pgstat_flush_io() is called for
> the walwriter. Indeed, it's coming from the pgstat_report_wal() call in
> WalWriterMain(). That can not report any I/O stats activity (as the
> walwriter is
Hi hackers,
While working on [1], it has been noticed that pgstat_flush_io() is called for
the walwriter. Indeed, it's coming from the pgstat_report_wal() call in
WalWriterMain(). That can not report any I/O stats activity (as the
walwriter is not part of the I/O stats tracking, see pgstat_tracks_
> On 18 Dec 2024, at 12:28, Ashutosh Bapat wrote:
In general I think it's fine to have such an expensive test gated behind a
PG_TEST_EXTRA flag, and since it's only run on demand we might as well run it
for all formats while at it. If this ran just once per week in the buildfarm
it would still a
On Thu, Nov 14, 2024 at 4:16 PM Ashutosh Bapat
wrote:
>
> > But see next
> >
> > >
> > > What's the advantage of testing all the formats? Would that stuff
> > > have been able to catch up more issues related to specific format(s)
> > > when it came to the compression improvements with inheritance
On Tue, 17 Dec 2024 at 10:43, vignesh C wrote:
> > If I understand your suggestion correctly I think this will break the
> > "--exclude-schema" option of pg_dump. That change will dump all
> > mappings between publications and schemas for publications which are
> > dumped.
> >
> > That solves the
On Thu, Feb 8, 2024 at 9:57 AM Laurenz Albe wrote:
>
> On Thu, 2024-02-08 at 13:40 +1100, Peter Smith wrote:
> > - how to set the replica identity. If a table without a replica identity
> > is
> > + how to set the replica identity. If a table without a replica identity
> > + (or with repl
On Thu, Feb 8, 2024 at 7:24 PM James Coleman wrote:
>
> On Thu, Feb 8, 2024 at 4:47 AM Ashutosh Bapat
> wrote:
> >
> > On Thu, Feb 8, 2024 at 9:57 AM Laurenz Albe
> > wrote:
> > >
> > > On Thu, 2024-02-08 at 13:40 +1100, Peter Smith wrote:
> > > > - how to set the replica identity. If a tabl
On Wed, 18 Dec 2024 at 22:29, Richard Guo wrote:
> Should we be concerned about passing a NULL TupleTableSlotOps in
> nodeRecursiveUnion.c?
I made it pass NULL on purpose because the slot type on the recursive
union can be different on the inner and outer sides. Do you see issues
with that?
> Th
On Thu, Oct 31, 2024 at 3:14 AM David Rowley wrote:
>
> On Thu, 31 Oct 2024 at 09:02, David Fetter wrote:
> > This testing was basically just sending a bunch of appropriately sized
> > pseudo-random uints in a previously created array sent through a tight
> > loop that called the ilog10s and gett
Ryohei Takahashi (Fujitsu) писал(а) 2024-12-16 15:10:
Hi
Please use the "test.sh" in the following e-mail.
https://www.postgresql.org/message-id/flat/TY3PR01MB11891C0FD066F069B113A2376823E2%40TY3PR01MB11891.jpnprd01.prod.outlook.com#8455c9f7b66780a356511f5cfe029d57
I cannot reproduce your results
Title: Transaction Priority Management
Description:
I would like to propose a feature that allows assigning priority levels to
transactions in PostgreSQL. This feature would help manage locks and prevent
deadlocks by ensuring that higher-priority transactions are given precedence
over lower-prio
On Wed, Dec 18, 2024 at 5:36 PM Heikki Linnakangas wrote:
> I don't know how that can happen, but I suspect commit 3c0fd64fec
> because it changed things in that area. If you can find a way to
> reproduce that even sporadically, that would be very helpful!
Thank you for the information. I'll try
I started committing the cube and seg pieces. There were a couple of
complaints from the buildfarm, like
ccache clang -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla
-Werror=unguarded-availability-new -Wendif-labels
-Wmissing-format-attribute -
On Thu, Dec 5, 2024 at 3:14 PM Jakub Wartak
wrote:
>
> One of our customers ran into a very odd case, where hot standby feedback
> backend_xmin propagation stopped working due to major (hours/days) clock time
> shifts on hypervisor-managed VMs. This happens (and is fully reproducible)
> e.g. in
On Wed, Dec 18, 2024 at 7:05 AM Tom Lane wrote:
> David Rowley writes:
> > The slightly annoying thing here is that the attached patch passes the
> > TupleTableSlotOps as NULL in nodeSetOp.c. Per nodeAppend.c line 186,
> > Append does not go to much effort to setting a fixed
> > TupleTableSlotOps
ing a new GUC or extending the existing one
(e.g., log_lock_waits)
is debatable, but I prefer the latter. I'm considering extending
log_lock_waits
to accept a value like "fail". If set to "on" (the current behavior),
detailed logs are generated when the lock wait time exceeds
deadlock_timeout.
On 18/12/2024 08:17, Richard Guo wrote:
Recently, I've encountered a core dump several times on master, with a
backtrace like the one below. This one happened on 0f23dedc9. I was
running some fuzz testing and had started around 20 sessions
concurrently.
(gdb) bt
#0 in GrantLockLocal at lock.c
On Wed, Dec 18, 2024 at 08:11:55AM +, Bertrand Drouvot wrote:
> Yeah, I also had something like this in mind (see R2 in [1]). So, +1 for it.
[1] being:
https://www.postgresql.org/message-id/Zy4bmvgHqGjcK1pI%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Drouvot
PostgreSQL
Hi,
On Wed, Dec 18, 2024 at 01:57:53PM +0900, Michael Paquier wrote:
> On Tue, Dec 17, 2024 at 09:35:37AM +, Bertrand Drouvot wrote:
> > Agree, we may need to add parameters to it but we'll see when the time
> > comes.
>
> Another thing that's been itching me: the loop in
> pg_stat_get_backe
73 matches
Mail list logo
