Hi
Our customer reported an issue related to quiet precision lost when ALTER
TABLE ALTER COLUMN was executed.
The ALTER TABLE ALTER COLUMN TYPE is sometimes safe
(2025-03-04 08:02:32) postgres=# create table t1(a varchar(10));
CREATE TABLE
(2025-03-04 08:02:43) postgres=# INSERT INTO t1 VALUES('
Hi Daniel,
Thanks for the rebase, a few mostly superficial comments from a first
> read-through.
>
Thank you for your comments.
> The documentation refers to attributes in the return row but the format of
> that
> row isn't displayed which makes following along hard. I think we should
> include
On Wed, Feb 26, 2025 at 11:50 PM Alex Friedman wrote:
> > We could add the proposed language on "can grow up to about 20GB" at
> > the end of this paragraph, which seems more natural -- first mention
> > the amount that triggers aggressive vacuum, then the maximum size.
>
> Yes, I believe this can
On Mon, 3 Mar 2025 at 16:41, Amit Kapila wrote:
>
> On Mon, Mar 3, 2025 at 2:30 PM vignesh C wrote:
> >
> > On Tue, 25 Feb 2025 at 15:32, vignesh C wrote:
> > >
> > > The attached script has the script that was used for testing. Here the
> > > NUM_RECORDS count should be changed accordingly for
Hi Yura,
On Sun, Mar 02, 2025 at 06:20:07PM +0300, Yura Sokolov wrote:
> Your forgot another one attempt discussion with patch [1] with alive
> commitfest entry [2]
>
> [1] https://postgr.es/m/flat/3766675.7eaCOWfIcx%40thinkpad-pgpro
> [2] https://commitfest.postgresql.org/patch/4688/
Thank you.
On Mon, Mar 3, 2025 at 11:21 PM Nathan Bossart wrote:
>
> On Mon, Mar 03, 2025 at 05:58:43PM +0700, John Naylor wrote:
> True. One small thing we could do is to require "found_objs" (the double
> pointer) to always be non-NULL, but that just compels some callers to
> provide otherwise-unused vari
On 2025/03/03 14:09, Ryo Kanbayashi wrote:
On Mon, Mar 3, 2025 at 12:23 PM Fujii Masao wrote:
On 2025/03/01 19:45, Ryo Kanbayashi wrote:
+program_help_ok('ecpg');
+program_version_ok('ecpg');
+program_options_handling_ok('ecpg');
+command_fails(['ecpg'], 'ecpg without arguments fails');
The
út 4. 3. 2025 v 0:04 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> >> po 24. 2. 2025 v 21:05 odesílatel Gilles Darold
> >> napsal:
> >>> I think it could be ready to be committed.
>
> Pushed with a docs/test correction: this also affects the syntax
> of FOR-over-cursor.
>
> >>> Note for
On Mon, Mar 3, 2025 at 5:59 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shubham,
>
> I did a quick check and have a comment in drop_publication().
>
> ```
> + /* For cleanup purposes */
> + dbinfos.dbinfo->made_publication = true;
> +
> ```
>
> Please do not modify randomly. Currently,
On Tue, Mar 4, 2025 at 5:41 AM Devulapalli, Raghuveer
wrote:
> Some feedback on v11:
>
> if ((exx[2] & (1 << 20)) != 0) /* SSE 4.2 */
> {
> pg_comp_crc32c = pg_comp_crc32c_sse42;
> #ifdef USE_PCLMUL_WITH_RUNTIME_CHECK
> if ((exx[2] & (1 << 1)) != 0) /* PCLMUL */
>
On Tue, Mar 4, 2025 at 2:11 AM Nathan Bossart wrote:
> I spent some time staring at pg_crc32.h with all these patches applied, and
> IIUC it leads to the following behavior:
>
> * For compiled-in SSE 4.2 builds, we branch based on the length. For
> smaller inputs, we are using an inlined versi
On Tue, Mar 4, 2025 at 6:25 AM Jeff Davis wrote:
>
> On Mon, 2025-03-03 at 22:04 +0530, Ashutosh Bapat wrote:
> > But while we have hold of reltuples wasting a chance to
> > update it in pg_class does not look right to me.
>
> To me, autovacuum=off is a pretty clear signal that the user doesn't
>
I implemented a LISTEN command that supports matching names in the LIKE
format.
Just like
LISTEN 'c%';
NOTIFY c1;NOTIFY c2;
Notifications are received for c1 and c2.
For grammatical reasons, LISTEN 'v_'; with LISTEN v_; It's weird.
Should it be defined in a way that makes it easier to distin
On 2025/03/01 7:52, Melanie Plageman wrote:
On Fri, Feb 28, 2025 at 12:54 AM Bertrand Drouvot
wrote:
On Thu, Feb 27, 2025 at 05:55:19PM -0500, Melanie Plageman wrote:
It still needs polishing (e.g. I need to figure out where to put the new guc
hook
functions and enums and such)
yeah, I
On Tue, Mar 4, 2025 at 1:07 PM Jacob Champion
wrote:
> # [libcurl] * getsockname() failed with errno 22: Invalid argument
Weird.
> Later, Curl reconnects via IPv6 -- this time succeeding -- but then
> the response gets mangled in some way. I assume headers are being
> truncated, based on Cur
On Mon, Mar 3, 2025 at 3:18 PM Fujii Masao wrote:
>
> On 2025/03/03 16:35, Jakub Wartak wrote:
> > Hi Amit,
> >
> > On Mon, Mar 3, 2025 at 6:26 AM Amit Kapila wrote:
> > [..]
> >
> > OK, sure.
> >
> >> How about something like: "Note that if the clock on standby is moved
> >> ahead or backward, t
On Mon, Mar 03, 2025 at 01:13:05PM +0900, Michael Paquier wrote:
> In short, LGTM. Will apply if there are no objections.
And applied as 40d3f8274499.
--
Michael
signature.asc
Description: PGP signature
On Wed, Feb 26, 2025 at 3:12 AM Dagfinn Ilmari Mannsåker
wrote:
>
> Masahiko Sawada writes:
>
> > On Tue, Feb 25, 2025 at 3:03 PM Dagfinn Ilmari Mannsåker
> > wrote:
> >>
> >> Hi,
> >>
> >> While working on another round of the long option and fat comma style
> >> cleanup, I noticed that the tes
On 2025-03-04 03:17, Fujii Masao wrote:
Agreed and I feel that a message suggesting something like "check if
there are any overflowing transactions on the primary side" would make
it useful.
I’m wondering if this message might still be confusing for users.
Would they immediately understand wh
(My previous message did not reach the lists, so re-sending with some
edits.)
On Fri, Feb 28, 2025 at 05:31:00PM +0100, Daniel Verite wrote:
> The following invocations don't respect the desired output destination
> and formats (ignoring them), when a pipeline is active:
>
> select ... \bind \g f
On Mon, 2025-03-03 at 22:04 +0530, Ashutosh Bapat wrote:
> But while we have hold of reltuples wasting a chance to
> update it in pg_class does not look right to me.
To me, autovacuum=off is a pretty clear signal that the user doesn't
want this kind of side-effect to happen. Am I missing something
On Mon, 17 Feb 2025 at 10:17, Jelte Fennema-Nio wrote:
>
> The next release of the commitfest app will take place March 4th.
>
> The user facing changes are:
> 1. The form for creating a commitfest entry now contains all the
> commitfest entry fields, instead of redirecting to the entries edit
> p
On Mon, Mar 3, 2025 at 9:40 AM Melanie Plageman
wrote:
>
> I'd certainly like to merge it in 18. The patch itself needs more
> work, which I'm planning on doing this week. I think we have a
> reasonable amount of consensus on using GUC_LIST_INPUT.
>
> I am less sure about merging log_disconnection
On Mon, Mar 03, 2025 at 09:17:30AM +, Bertrand Drouvot wrote:
> On Mon, Mar 03, 2025 at 10:48:23AM +0900, Michael Paquier wrote:
>> Something that's still not quite right is that the WAL receiver and
>> the WAL summarizer do not call pgstat_report_wal() at all, so we don't
>> report much data a
On Fri, Apr 26, 2024 at 12:02 AM Nazir Bilal Yavuz wrote:
> On Sat, 13 Apr 2024 at 05:12, Andres Freund wrote:
> > I propose that we instead run the task automatically if
> > $REPO_MINGW_TRIGGER_BY_DEFAULT is set, typically in cirrus' per-repository
> > configuration.
> >
> > Unfortunately that's
On Tue, Mar 4, 2025 at 11:39 AM Andres Freund wrote:
> On 2025-03-04 11:35:30 +1300, Thomas Munro wrote:
> > I propose to turn these on by default tomorrow, unless someone speaks
> > up with reasons why we shouldn't.
> I'm worried about enabling them by default eating up CI credits even
> faster.
On Fri, Feb 28, 2025 at 4:37 PM Thomas Munro wrote:
> In case it's relevant, it was green for me, but I also ran it in
> combination with my 3x-go-faster patch on that other thread. . o O {
> Timing/race stuff? Normally the build farm shakes that stuff out a
> bit more reliably than CI, but I dou
On Fri, Feb 28, 2025 at 1:44 PM Andy Alsup wrote:
>
> Masahiko,
>
> I like the change you've made.
Pushed.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Mon, Mar 3, 2025 at 11:14 AM Bertrand Drouvot
wrote:
>
>
> On Fri, Feb 28, 2025 at 05:52:35PM -0500, Melanie Plageman wrote:
>
> +bool
> +check_log_connections(char **newval, void **extra, GucSource source)
> +{
>
> This function is pretty close to check_debug_io_direct() for example and its
>
On Mon, Mar 3, 2025 at 9:00 AM Israel Barth Rubio wrote:
> > 2) Since it is a new file, "Copyright (c) 2021-2025" should be
> > "Copyright (c) 2025"
>
> Done!
For the record, this proposed change is not a project policy, AIUI. I
don't care very much what we do here, but -1 for kibitzing the range
On Mon, Mar 3, 2025 at 1:28 AM Masahiko Sawada wrote:
>
> On Tue, Feb 25, 2025 at 4:49 PM Masahiko Sawada wrote:
> >
> > On Tue, Feb 25, 2025 at 2:44 PM Melanie Plageman
> > wrote:
> > >
> > > On Tue, Feb 25, 2025 at 5:14 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > Given that we have only
On Mon, Mar 03, 2025 at 03:52:30PM -0500, Robert Haas wrote:
> On Mon, Mar 3, 2025 at 2:53 PM Tom Lane wrote:
> > Robert Haas writes:
> > > lapwing has been failing sepgsql-check for over a month, but there's
> > > no log file:
> >
> > I believe it hasn't been updated with the buildfarm client ch
Julien Rouhaud writes:
>> On Mon, Mar 3, 2025 at 2:53 PM Tom Lane wrote:
>>> I believe it hasn't been updated with the buildfarm client changes
>>> needed to run sepgsql-check since aeb8ea361.
> Well, AFAIK the usual habit when something is broken and a buildfarm cilent
> upgrade is needed is to
Pavel Stehule writes:
>> po 24. 2. 2025 v 21:05 odesílatel Gilles Darold
>> napsal:
>>> I think it could be ready to be committed.
Pushed with a docs/test correction: this also affects the syntax
of FOR-over-cursor.
>>> Note for the committer: does it make sense to mention in the
>>> documentat
On Wed, Feb 19, 2025 at 09:31:50AM +, chiranmoy.bhattacha...@fujitsu.com
wrote:
>> Hm. Any idea why that is? I wonder if the compiler isn't using as many
>> SVE registers as it could for this.
>
> Not sure, we tried forcing loop unrolling using the below line in the MakeFile
> but the resul
Hi John,
> You raised some interesting points, which deserve a thoughtful response. After
> sleeping on it, however I came to the conclusion that a sweeping change in
> runtime checks, with either of our approaches, has downsides and unresolved
> questions. Perhaps we can come back to it at a lat
Hi,
On 2025-03-04 11:35:30 +1300, Thomas Munro wrote:
> On Sun, Mar 2, 2025 at 1:37 AM Thomas Munro wrote:
> > On Sat, Mar 1, 2025 at 6:24 AM Nazir Bilal Yavuz wrote:
> > > I think I found the problem, sd0j's fstype is not a swap. It worked like
> > > that:
> > >
> > > $ disklabel -E sd0
> > >
On Mon, Mar 3, 2025 at 2:36 PM Thomas Munro wrote:
> One non-reason to hold off is a
> one-off report[1] from Jacob about an unexplained failure of the oauth
> tests on NetBSD, but I'd prefer to see it flap if it's going to so we
> can collect clues and tackle it.
Agreed.
--Jacob
On Sun, Mar 2, 2025 at 1:37 AM Thomas Munro wrote:
> On Sat, Mar 1, 2025 at 6:24 AM Nazir Bilal Yavuz wrote:
> > I think I found the problem, sd0j's fstype is not a swap. It worked like
> > that:
> >
> > $ disklabel -E sd0
> > $ umount /usr/obj
> > $ disklabel -E sd0 # prompts are: m -> j -> \n
Andres Freund writes:
> ../../../../../home/andres/src/postgresql/src/backend/nodes/nodeFuncs.c:2712:6:
> runtime error: call to function assign_query_collations_walker through
> pointer to incorrect function type 'bool (*)(struct Node *, void *)'
> /srv/dev/build/postgres/m-dev-assert-clang-san
Hi,
On 2025-03-03 16:49:09 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I wish the sanitizer treated mismatches of void * arguments against a "real
> > type" different from other mismatches, but ...
>
> Indeed. I think we have enough coverage of that via compile-time
> checks, though -- i
On Thu, Feb 27, 2025 at 7:58 PM Peter Geoghegan wrote:
> It's easy to produce an example that makes intuitive sense. For
> example, with skip scan that has a qual such as "WHERE a BETWEEN 1 and
> 5 AND b = 12345", it is likely that EXPLAIN ANALYZE will show "Index
> Searches: 5" -- one search per
On Mon, Mar 3, 2025 at 2:53 PM Tom Lane wrote:
> Robert Haas writes:
> > lapwing has been failing sepgsql-check for over a month, but there's
> > no log file:
>
> I believe it hasn't been updated with the buildfarm client changes
> needed to run sepgsql-check since aeb8ea361.
OK, thanks. The own
Hi,
On 2025-03-03 21:31:42 +0100, Tomas Vondra wrote:
> On 3/3/25 19:10, Andres Freund wrote:
> > On 2024-09-21 20:33:49 +0200, Tomas Vondra wrote:
> >> I've finally pushed this, after many rounds of careful testing to ensure
> >> no regressions, and polishing.
> >
> > One minor nit: I don't like
Hi,
On 2025-03-03 15:00:43 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I just upgraded buildfarm animal kestrel (a buildfarm animal running with
> > ubsan) to a newer version of clang. Unfortunately this causes it to fail.
> > ...
> > Tom, do you see any reason to not instead do the typec
On Tue, Mar 4, 2025 at 5:48 AM Andres Freund wrote:
> On 2025-02-24 11:26:56 +0100, Jelte Fennema-Nio wrote:
> > [1]: https://cirrus-ci.com/task/5571017969500160?logs=test_world#L256
>
> A possibly related test failure is:
>
> https://cirrus-ci.com/task/5005337046024192?logs=check_world#L259
They
On 3/3/25 19:10, Andres Freund wrote:
> Hi,
>
> On 2024-09-21 20:33:49 +0200, Tomas Vondra wrote:
>> I've finally pushed this, after many rounds of careful testing to ensure
>> no regressions, and polishing.
>
> One minor nit: I don't like that FP_LOCK_SLOTS_PER_BACKEND is now non-constant
> w
Hi Matheus,
On Mon, Mar 3, 2025 at 1:43 PM Matheus Alcantara
wrote:
> On Mon, Mar 3, 2025 at 4:16 PM Matheus Alcantara
> wrote:
> >
> > Hi Alex,
> >
> > The code comments and the commit messages help a lot when reviewing!
> Thanks for
> > the new version.
> >
> > The code LGTM and check-world i
On Mon, Mar 3, 2025 at 1:11 PM Nathan Bossart wrote:
>
> "fraction of unfrozen pages before insert vacuum"
>
> That more closely matches the other scale factor parameters. It's
> admittedly quite terse, but so are the vast majority of other descriptions
> in the sample file. I don't thin
Andres Freund writes:
> I just upgraded buildfarm animal kestrel (a buildfarm animal running with
> ubsan) to a newer version of clang. Unfortunately this causes it to fail.
> ...
> Tom, do you see any reason to not instead do the typecase inside
> string_compare()?
No. Have at it.
Robert Haas writes:
> lapwing has been failing sepgsql-check for over a month, but there's
> no log file:
I believe it hasn't been updated with the buildfarm client changes
needed to run sepgsql-check since aeb8ea361.
regards, tom lane
Hi,
I just upgraded buildfarm animal kestrel (a buildfarm animal running with
ubsan) to a newer version of clang. Unfortunately this causes it to fail.
The buildfarm output doesn't contain enough information to debug that
unfortunately. But I triggered it manually and meson-logs/testlog.txt did
Hi,
On Fri, Feb 28, 2025 at 05:52:35PM -0500, Melanie Plageman wrote:
> On Fri, Feb 28, 2025 at 12:54 AM Bertrand Drouvot
> wrote:
> >
> > On Thu, Feb 27, 2025 at 05:55:19PM -0500, Melanie Plageman wrote:
> > > It still needs polishing (e.g. I need to figure out where to put the new
> > > guc ho
On Mon, Mar 3, 2025 at 4:16 PM Matheus Alcantara
wrote:
>
> Hi Alex,
>
> The code comments and the commit messages help a lot when reviewing! Thanks
> for
> the new version.
>
> The code LGTM and check-world is happy. I've also performed some tests and
> everything looks good!
>
> Just some minor
lapwing has been failing sepgsql-check for over a month, but there's
no log file:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=lapwing&dt=2025-03-03%2016%3A29%3A50&stg=contrib-sepgsql-check
I feel like something must be broken with logfile collection in the
buildfarm client, beca
On Sun, Jan 19, 2025 at 9:12 PM Yura Sokolov wrote:
>
> 20.01.2025 07:36, Tom Lane пишет:
...
> > This has been discussed before, and we've felt that it wasn't worth
> > the additional code duplication. I would not favor approaching this
> > with the mindset of lets-copy-and-paste-all-the-code.
>
Hi Alex,
The code comments and the commit messages help a lot when reviewing! Thanks for
the new version.
The code LGTM and check-world is happy. I've also performed some tests and
everything looks good!
Just some minor points about this new version:
## v9-0005
Typo on commit message title
##
On Fri, Feb 28, 2025 at 07:11:29PM +0700, John Naylor wrote:
> 0002: For SSE4.2 builds, arrange so that constant input uses an
> inlined path so that the compiler can emit unrolled loops anywhere.
> This is particularly important for the WAL insertion lock, so this is
> possibly committable on its
Robert Haas writes:
> I wonder if we could drum up some support for not including any
> version of the password (even encrypted) in the query string. For
> instance, let's say that to change your password you have to use the
> new CHANGE PASSWORD command which can only be used at top level (not
>
On Sun, Mar 2, 2025 at 4:19 PM Sutou Kouhei wrote:
>
> Hi,
>
> In <3191030.1740932...@sss.pgh.pa.us>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Sun, 02 Mar 2025 11:27:20 -0500,
> Tom Lane wrote:
>
> >> While review another thread (Emitting JSON to file u
On Sat, Mar 1, 2025 at 4:23 PM Tom Lane wrote:
> That particular argument needs to be rejected vociferously.
Okay, I will concede that part of my argument. And for the record, I've
written pg_dump output parsing programs many times over the years, and seen
others in the wild. It's not uncommon
On Mon, Mar 3, 2025 at 1:47 PM Tom Lane wrote:
> Robert Haas writes:
> > I wonder if we could drum up some support for not including any
> > version of the password (even encrypted) in the query string. For
> > instance, let's say that to change your password you have to use the
> > new CHANGE PA
Alvaro Herrera wrote:
> On 2025-Feb-26, Antonin Houska wrote:
>
> > @@ -403,39 +381,38 @@ cluster_rel(Relation OldHeap, Oid indexOid,
> > ClusterParams *params)
> > * would work in most respects, but the index would only get marked as
> > * indisclustered in the current database, lead
Hi, attached a new v5 with some minor improvements on TAP tests:
- Add a proper test name for all test cases
- Add CREATE EXTENSION command execution
- Change the assert on pg_available_extensions and
pg_available_extension_versions to validate the row content
Also rebased with master
--
Math
I wrote:
> jian he writes:
>> within ATExecAddColumn, we can
>> if (!missingIsNull)
>> StoreAttrMissingVal(rel, attribute->attnum, missingval,
>> missingIsNull);
>> to save some cycles?
> Probably not really worth it: surely that's going to be a very
> infrequent edge case.
On secon
On 2025/03/04 0:20, torikoshia wrote:
On 2025-03-03 13:10, Fujii Masao wrote:
Thanks for your comments!
On 2025/02/03 22:35, torikoshia wrote:
Hi,
When a hot standby is restarted in a state where subtransactions have
overflowed, it may become inaccessible:
$ psql: error: connection t
On Mon, Mar 03, 2025 at 12:18:37PM -0500, Melanie Plageman wrote:
> I noticed the docs wording is kind of different than that in
> postgresql.conf.sample. The docs wording mentions that the scale
> factor gets added to the threshold and postgresql.conf.sample does not
> (in master as well). I just
On Mon, Mar 3, 2025 at 11:33 AM Nathan Bossart wrote:
> I think it would be good to hear some other opinions on whether we should
> consider sending clear-text passwords to the server as either 1) fully
> supported, 2) deprecated but with no intent to remove anytime soon, or 3)
> deprecated with t
Hi,
On 2024-09-21 20:33:49 +0200, Tomas Vondra wrote:
> I've finally pushed this, after many rounds of careful testing to ensure
> no regressions, and polishing.
One minor nit: I don't like that FP_LOCK_SLOTS_PER_BACKEND is now non-constant
while looking like a constant:
#define FP_LOCK_
Hi,
Thanks for sending these, the issues addressed here have been bugging me for a
long while.
On 2025-03-01 10:19:01 +0530, Rahila Syed wrote:
> The 0001* patch improved the accounting for the shared memory allocated for
> a hash table during hash_create. pg_shmem_allocations tracks the memory
On 2025-Feb-26, Antonin Houska wrote:
> @@ -403,39 +381,38 @@ cluster_rel(Relation OldHeap, Oid indexOid,
> ClusterParams *params)
>* would work in most respects, but the index would only get marked as
>* indisclustered in the current database, leading to unexpected
> behavior
>
On 28/02/2025 20:26, Robert Haas wrote:
Prior to PostgreSQL 10, EXPLAIN had just 2 options: VACUUM and
ANALYZE. Now, we're up to 12 options, which is already quite a lot,
and there's plenty more things that somebody might like to do.
However, not all of those things necessarily need to be part of
While working on the big interrupts refactoring, I noticed that
ExecAppendAsyncEventWait() doesn't include WL_LATCH_SET in the wait set.
As a result, it will not wake up on an interrupt like a query cancel
request or sinval catchup.
I'm surprised this has gone unnoticed for so long. It's prett
> > > It's not a question about whether it's possible to implement this,
> > > but about whether it makes sense. In case of plain constants it's
> > > straightforward -- they will not change anything meaningfully and
> > > hence could be squashed from the query. Now for a function, that
> > > might
Thanks for the update. This LGTM! and I will mark as RFC.
--
Sami
On Fri, Feb 28, 2025 at 12:54 PM Nathan Bossart
wrote:
>
> On Wed, Feb 26, 2025 at 04:48:20PM -0500, Melanie Plageman wrote:
> > Makes sense. Thanks Robert and Nathan. Attached v11 changes the docs
> > wording and is rebased.
>
> 0001 LGTM.
Cool. Corey checked over the stats import tests off-list
On 2025-Mar-01, Gurjeet Singh wrote:
> I propose the following change to the generation script,
> generate-lwlocknames.pl
>
> -print $h "#define ${lockname}Lock (&MainLWLockArray[$lockidx].lock)\n";
> +printf $h "#define %-30s %s\n", "${lockname}Lock",
> "(&MainLWLockArray[$lockidx].lock
On Mon, 3 Mar 2025 at 12:07, Greg Sabino Mullane wrote:
> On Mon, Mar 3, 2025 at 11:33 AM Nathan Bossart
> wrote:
>
>> I think it would be good to hear some other opinions on whether we should
>> consider sending clear-text passwords to the server as either 1) fully
>> supported, 2) deprecated b
On 2025/03/04 1:14, Bertrand Drouvot wrote:
=== 2
+/*
+ * Validate the input for the log_connections GUC.
+ */
+bool
+check_log_connections(char **newval, void **extra, GucSource source)
+{
This function is pretty close to check_debug_io_direct() for example and its
overall content, memory m
On Mon, Mar 3, 2025 at 11:33 AM Nathan Bossart
wrote:
> I think it would be good to hear some other opinions on whether we should
> consider sending clear-text passwords to the server as either 1) fully
> supported, 2) deprecated but with no intent to remove anytime soon, or 3)
> deprecated with
On Fri, Feb 21, 2025 at 6:48 AM Matheus Alcantara
wrote:
> Hi, thanks for all the reviews. Attached v3 with some fixes.
Thanks! I keep getting pulled away from my review of 0002, so I'll
just comment on 0001 to get things moving again; sorry for the delay.
> I agree, I've just declared outside o
Hi,
On 2025-02-24 11:26:56 +0100, Jelte Fennema-Nio wrote:
> The test introduced in bb86141 turns out to be flaky in CI[1] with the
> following error message:
>
> [03:40:43.047] stderr:
> [03:40:43.047] # Failed test 'connect : matches'
> [03:40:43.047] # at
> /tmp/cirrus-ci-build/src/test/postmas
On Sun, Mar 2, 2025 at 1:10 AM Gurjeet Singh wrote:
> I propose the following change to the generation script,
> generate-lwlocknames.pl
>
> -print $h "#define ${lockname}Lock (&MainLWLockArray[$lockidx].lock)\n";
> +printf $h "#define %-30s %s\n", "${lockname}Lock",
> "(&MainLWLockArray
On Mon, Mar 3, 2025 at 9:14 AM Matthias van de Meent
wrote:
> I think you meant "some time prior to PostgreSQL 10".
> PostgreSQL 9.0 had 5 options, of which COSTS, BUFFERS, and FORMAT were
> newly added, so only before 9.0 we had 2 options.
> PostgreSQL 9.2 then added TIMING on top of that, for a
jian he writes:
> within ATExecAddColumn, we can
> if (!missingIsNull)
>StoreAttrMissingVal(rel, attribute->attnum, missingval, missingIsNull);
> to save some cycles?
Probably not really worth it: surely that's going to be a very
infrequent edge case. We already eliminated cases with a simpl
On Sat, Mar 1, 2025 at 1:40 AM Jeff Davis wrote:
>
> On Fri, 2025-02-28 at 14:51 +0530, Ashutosh Bapat wrote:
> > 2. We aren't restoring the statistics faithfully - as mentioned in
> > Greg's reply. If users dump and restore with autovacuum turned off,
> > they will be surprised to see the statist
On 03.03.2025 14:17, Alena Rybakina wrote:
Hi! Thank you for your work on this subject.
I agree with your code but one phrase in commit message was confusing
for me:
"This change is dedicated to more active usage of IndexScan and
parameterised
NestLoop paths in partitioned cases under an App
On Tue, Feb 25, 2025 at 11:13:51AM -0500, Greg Sabino Mullane wrote:
> On Tue, Feb 25, 2025 at 10:34 AM Nathan Bossart
> wrote:
>> IMHO a WARNING would really only be appropriate if we are definitely going
>> to remove support in the future, and that feels like a bit of a stretch to
>> me due to t
On Mon, Mar 03, 2025 at 05:58:43PM +0700, John Naylor wrote:
> On Sat, Mar 1, 2025 at 3:42 AM Nathan Bossart
> wrote:
>> On Thu, Feb 27, 2025 at 04:36:04PM +0700, John Naylor wrote:
>> > I had to read it several times before I noticed the difference between
>> > "* found_objs" and "*found_objs".
I've pushed the first part of the series (0001 + the cleanup and
progress patch). That leaves the two smaller improvement parts
(compression + memory limit enforcement) - I intend to push those
sometime this week, if possible.
Here's a rebased version of the whole patch series, including the two
W
First, thanks to all who have said they like this idea. I wasn't
expecting this much enthusiasm, to be honest. Woohoo!
On Mon, Mar 3, 2025 at 8:27 AM Matheus Alcantara
wrote:
> It would make sense (or possible) to have some kind of validation that returns
> an error when using an option that is a
hi hackers,
When estimating the selectivity of an OR clause without extended
statistics, we assume that the conditions are independent. However, it
is quite common to see queries like (a = 1 OR a = 2). In such cases, the
assumption of independence can lead to a significant underestimation of
Ashutosh Bapat writes:
> On Sun, Mar 2, 2025 at 5:14 PM Etsuro Fujita wrote:
>> To avoid that, I would like to propose a server option,
>> inherit_read_only, to open the remote transactions in read-only mode
>> if the local transaction is read-only.
> Why do we need a server option. Either we sa
> On 28 Feb 2025, at 07:20, Abhishek Chanda wrote:
>
> Attached a v6 with O_NOFOLLOW removed, I noticed that it failed on
> windows. Please let me know if I should do this in any other way that
> is portable across platforms.
Not sure if there is a portable way to can support.
required v
On 2025-03-03 13:10, Fujii Masao wrote:
Thanks for your comments!
On 2025/02/03 22:35, torikoshia wrote:
Hi,
When a hot standby is restarted in a state where subtransactions have
overflowed, it may become inaccessible:
$ psql: error: connection to server at "localhost" (::1), port 5433
Dear Hackers,
Let me please introduce a new version of the patch.
Patch description:
The slot data is flushed to the disk at the beginning of checkpoint. If
an existing slot is advanced in the middle of checkpoint execution, its
advanced restart LSN is taken to calculate the oldest LSN for WAL
s
On Mar 3, 2025, at 10:05, David E. Wheeler wrote:
> Very nice writeup, thank you. Makes me wish for the bandwidth to get back to
> and start refining the PGXN OCI RFC
Forgot to link to the POC[1]. The RFC[2] is not OCI-specific, but the POC
demonstrates the “full content” version. Will likely
On Mar 3, 2025, at 08:39, Gabriele Bartolini
wrote:
> As promised, here is a blog article that provides more context and
> information about what this feature will mean in Kubernetes with
> CloudNativePG:
> https://www.gabrielebartolini.it/articles/2025/03/the-immutable-future-of-postgresql-e
On Mon, Mar 3, 2025 at 5:43 AM Sergey Dudoladov
wrote:
>
> I must admit I haven't seen the [1] either. Thank you for pointing that out,
> Bertrand.
> I agree the patch from Melanie is very close to this patch.
>
> Melanie, do you think it is realistic to merge the
> v8-0001-Modularize-log_connec
On Mon, Mar 3, 2025 at 4:45 PM jian he wrote:
>
> looking at DefineRelation comments:
> * We can set the atthasdef flags now in the tuple descriptor; this just
> * saves StoreAttrDefault from having to do an immediate update of the
> * pg_attribute rows.
> this seems not right?
> De
1 - 100 of 134 matches
Mail list logo
