On Tue, 18 Mar 2025 19:33:00 -0700
Jeff Davis wrote:
> If we compare the following two problems:
>
> A. With glibc or ICU, every text index, including primary keys, are
> highly vulnerable to inconsistencies after an OS upgrade, even if
> there's no Postgres upgrade; vs.
>
> B. With the bui
Hi,
On Wed, Mar 19, 2025 at 08:19:42AM +0900, Michael Paquier wrote:
>
> Done that part for now.
Thanks!
> It will be possible to look at the bug fix
> after the release freeze as it impacts stable branches as well.
Yes, let's do that. Adding a reminder on my side.
Regards,
--
Bertrand Drou
On Wed, Mar 19, 2025 at 09:53:16AM +0800, Xuneng Zhou wrote:
> I think these two conditions are good too. In a busy system, they are met
> frequently, so the flush routine will be executed at least once every
> second. Conversely, when WAL generation is low, there's simply less data to
> record, an
On Mon, Feb 10, 2025 at 8:12 PM Bertrand Drouvot
wrote:
>
> Please find attached a patch to $SUBJECT.
>
> In rare circumstances (and on slow machines) it is possible that a
> xl_running_xacts
> is emitted and that the catalog_xmin of a logical slot on the standby advances
> past the conflict poin
On Tue, 18 Mar 2025 at 17:34, Shubham Khanna
wrote:
>
> I have added an additional test case to 040_pg_createsubscriber.pl as
> suggested.
>
> The attached patch contains the suggested changes.
How about we change the below code:
+# Verify that user databases (postgres, $db1, $db2) got subscript
Hi,
On Wed, Mar 19, 2025 at 02:26:47PM +0900, Michael Paquier wrote:
> On Wed, Mar 19, 2025 at 09:53:16AM +0800, Xuneng Zhou wrote:
> > I think these two conditions are good too. In a busy system, they are met
> > frequently, so the flush routine will be executed at least once every
> > second. Co
On Tue, Mar 18, 2025 at 8:02 AM Andrei Lepikhov wrote:
> Some questions:
> 1. I think, hooks ExplainOneQuery_hook_type, explain_per_plan_hook_type,
> explain_per_node_hook_type deserve to be moved to explain_format.h
> At least, inside the hook, we usually use functions like ExplainProperty.
-1,
Hi,
On 2025-03-18 16:35:29 -0400, Bruce Momjian wrote:
> Uh, the random_page_cost = 4 assumes caching, so it is assuming actual
> random I/O to be 40x slower, which I doubt is true for SSDs:
Uh, huh:
>
> https://www.postgresql.org/docs/current/runtime-config-query.html#RUNTIME-CONFIG-QUER
On Wed, Mar 12, 2025 at 01:51:08PM +0700, John Naylor wrote:
> On Wed, Mar 12, 2025 at 12:46 AM Devulapalli, Raghuveer
> wrote:
> >
> > I am happy to submit a patch with a C fallback version that leverages the
> > specific algorithm/technique mentioned in the white paper to make it clear
> > tha
> On 18 Mar 2025, at 20:37, Melanie Plageman wrote:
>
> I've reviewed 0001
Thanks!
I've added all suggested fixes as a separate patch step.
Except I did not rename injection points... I can't figure out descriptive
names.
And delay point is now after the page is processed, not before.
FWIW I
On Tue, Mar 18, 2025 at 11:12 AM Melanie Plageman
wrote:
>
> I'm looking at 0001 with the intent of committing it soon. Today I've
> just been studying the test with the injection points.
>
> My main thought is that you should rename the injection points to
> something more descriptive. We want to
On Tue, Mar 18, 2025 at 10:31 AM Andrew Dunstan wrote:
> > On Mar 18, 2025, at 9:34 AM, Robert Haas wrote:
> > On Tue, Mar 18, 2025 at 9:27 AM Andrew Dunstan wrote:
> >> Maybe we could have a TAP test module that would run it but only if you
> >> have "code-indent" in your PG_TEST_EXTRA.
> > Wh
Hi,
On 2025-03-18 12:29:02 -0500, Nathan Bossart wrote:
> Here is a first sketch at a test that cycles through all the transfer modes
> and makes sure they succeed or fail with an error along the lines of "not
> supported on this platform." Each test verifies that some very simple
> objects make
Hi
I am playing with new features in Postgres 18.
Maybe I found a bug
(2025-03-18 19:28:06) postgres=# create table foo(a int constraint gzero
check(a > 10) NOT ENFORCED);
CREATE TABLE
(2025-03-18 19:29:37) postgres=# insert into foo values(0);
INSERT 0 1
(2025-03-18 19:29:49) postgres=# insert
Em seg., 17 de mar. de 2025 às 16:17, Ranier Vilela
escreveu:
> Em sex., 7 de mar. de 2025 às 16:14, Ranier Vilela
> escreveu:
>
>>
>>
>> Em sex., 7 de mar. de 2025 às 16:01, Álvaro Herrera <
>> alvhe...@alvh.no-ip.org> escreveu:
>>
>>> On 2025-Mar-07, Álvaro Herrera wrote:
>>>
>>> > Anyway, my
Reliably fails tests on windows, due to what looks to be a null pointer
dereference.
E.g. https://cirrus-ci.com/task/6178371937239040
That's likely related to EXEC_BACKEND.
The new status of this patch is: Waiting on Author
On Tue, Mar 18, 2025 at 04:27:18PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-03-18 16:22:45 -0400, Bruce Momjian wrote:
> > On Tue, Mar 18, 2025 at 04:13:26PM -0400, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2025-03-18 16:08:22 -0400, Bruce Momjian wrote:
> > > > This commit makes our def
On Tue, Mar 18, 2025 at 3:50 PM Tom Lane wrote:
> That approach works only if you sit on Unicode 15.1 *forever*.
> The impracticality of that seems obvious to me. Sooner or later
> you will need to update, and then you are going to suffer pain.
I completely agree.
> The short answer is that "im
On Tue, Mar 18, 2025 at 11:12 AM Melanie Plageman
wrote:
>
> I'm looking at 0001 with the intent of committing it soon. Today I've
> just been studying the test with the injection points.
Now, I've reviewed 0001. I manually validated it does read combining etc.
Few comments:
I know I was the on
On 2025-Mar-18, Pavel Stehule wrote:
> Maybe I found a bug
>
> (2025-03-18 19:28:06) postgres=# create table foo(a int constraint gzero
> check(a > 10) NOT ENFORCED);
> CREATE TABLE
> (2025-03-18 19:29:37) postgres=# insert into foo values(0);
> INSERT 0 1
> (2025-03-18 19:29:49) postgres=# inser
On Tue, 2025-03-18 at 14:45 -0400, Robert Haas wrote:
> I think Joe has the right idea. The way to actually provide the
> stability that people want here is to continue supporting old
> versions
> while adding support for new versions. Anything else we do works
> subject to assumptions: you can eit
On Tue, Mar 18, 2025 at 05:04:46PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-03-18 16:35:29 -0400, Bruce Momjian wrote:
> > Uh, the random_page_cost = 4 assumes caching, so it is assuming actual
> > random I/O to be 40x slower, which I doubt is true for SSDs:
>
> Uh, huh:
>
> >
> > http
I kept stress-testing this, and while the frequency massively increased
on PG18, I managed to reproduce this all the way back to PG14. I see
~100x more corefiles on PG18.
That is not a proof the issue was introduced in PG14, maybe it's just
the assert that was added there or something. Or maybe th
Hi,
On 2025-03-17 19:52:02 -0400, Andres Freund wrote:
> On 2025-03-14 12:57:51 +1300, Thomas Munro wrote:
> > On Fri, Mar 14, 2025 at 12:23 PM Andres Freund wrote:
> >
> > > > 3. Considering errfinish()'s stated goal, a sort of backstop to help
> > > > you cancel looping message-spewing code o
On Tue, Mar 18, 2025 at 10:27:38AM +0100, Jelte Fennema-Nio wrote:
> One thing that comes to mind that I think would be quite useful and
> pretty easy to implement if we have this functionality within a
> pipeline: An \extended command. That puts psql in "extended protocol
> mode" (without enabling
Dear Fujii-san,
> It looks like commit 0c013e08cfb introduced a bug that causes "pg_recvlogical
> --drop-slot"
> without --dbname to check whether it's connected to a specific database and
> fail
> if it's not.
>
> This commit was added before 9.5, while pg_recvlogical was introduced in 9.4.
>
On Mon, Mar 17, 2025 at 5:47 PM Ashutosh Bapat
wrote:
> On Fri, Mar 14, 2025 at 5:36 PM Amit Langote wrote:
> > Thanks for the patch and the extensive benchmarking.
> >
> > Would you please also share a simple, self-contained example that I
> > can use to reproduce and verify the performance impr
On Mon, Mar 17, 2025 at 8:26 PM Jacob Champion
wrote:
> > > I was referring to the discussion upthread [1]; you'd mentioned that
> > > the only reason that get_connect_string() didn't call GetUserMapping()
> > > itself was because we needed that mapping later on for
> > > UseScramPassthrough(). Bu
Hi,
On Tue, 18 Mar 2025 at 15:47, Ranier Vilela wrote:
>
> Sorry, I couldn't find the email in this thread, linked to the commit:
> a051e71
>
> I think it left an oversight.
> Copy and past thinko?
Thanks for the report! Yes, it is an oversight on my part.
> Attached a trivial patch.
LGTM.
--
Alexander Korotkov писал(а) 2025-03-18 14:19:
Hi, Alexander!
On Tue, Mar 18, 2025 at 1:13 PM Alexander Pyhalov
wrote:
Alexander Korotkov писал(а) 2025-03-18 03:27:
> Hi, Robins!
>
> On Tue, Mar 18, 2025 at 2:20 AM Robins Tharakan
> wrote:
>> On Mon, 4 Dec 2023 at 07:22, Alexander Korotkov
>>
On Sat, 2025-03-15 at 10:14 -0400, Joe Conway wrote:
> In the long term I think we should figure out how to support newer
> versions of unicode for the builtin, but in my mind that might
> involve
> the necessity of supporting multiple versions of unicode such that
> the
> choice remains to rema
Em seg., 17 de mar. de 2025 às 16:17, Ranier Vilela
escreveu:
> Em sex., 7 de mar. de 2025 às 16:14, Ranier Vilela
> escreveu:
>
>>
>>
>> Em sex., 7 de mar. de 2025 às 16:01, Álvaro Herrera <
>> alvhe...@alvh.no-ip.org> escreveu:
>>
>>> On 2025-Mar-07, Álvaro Herrera wrote:
>>>
>>> > Anyway, my
Robert Haas writes:
> I'm not quite sure what the best thing is to do is for the pg_upgrade
> tests in particular, and it may well be best to do as you propose for
> now and figure that out later. But I question whether just rerunning
> all of those tests with several different mode flags is the r
On 3/18/25 14:33, Robert Haas wrote:
On Tue, Mar 18, 2025 at 8:02 AM Andrei Lepikhov wrote:
Some questions:
1. I think, hooks ExplainOneQuery_hook_type, explain_per_plan_hook_type,
explain_per_node_hook_type deserve to be moved to explain_format.h
At least, inside the hook, we usually use funct
On Tue, Mar 18, 2025 at 12:13 AM Tomas Vondra wrote:
> On 3/15/25 11:40, Alexander Korotkov wrote:
> > On Sun, Jan 5, 2025 at 1:43 AM Filip Janus wrote:
> >>
> >> I apologize for multiple messages, but I found a small bug in the previous
> >> version.
> >>
> >> -Filip-
> >
> > Great, thank y
Alexander Korotkov писал(а) 2025-03-18 03:27:
Hi, Robins!
On Tue, Mar 18, 2025 at 2:20 AM Robins Tharakan
wrote:
On Mon, 4 Dec 2023 at 07:22, Alexander Korotkov
wrote:
>
>
> Now, I think this looks good. I'm going to push this if no objections.
After this commit, I began seeing an unexpec
Dear Fujii-san, David,
> > BTW, I'm curious why --dbname isn't required for the --drop-slot action.
>
> I'm analyzing around here...
>
Actually, replication slots can be dropped from another database where it
created,
or even from the streaming replication connection.
I forked the new thread wh
On 3/7/25 16:05, Robert Haas wrote:
I have attempted to use hooks, proposed in 0002, in my extensions.
At first, it worked great. My patch reduced a lot, and the only things
that I need in the planner to improve its predictions are the
selectivity hook and the create_plan hook - the last one nee
On Tue, Mar 18, 2025 at 4:25 PM vignesh C wrote:
>
> On Mon, 17 Mar 2025 at 16:51, Ashutosh Bapat
> wrote:
> >
> > On Mon, Mar 17, 2025 at 4:02 PM vignesh C wrote:
> > >
> > > On Mon, 17 Mar 2025 at 11:28, Shubham Khanna
> > > wrote:
> > > >
> > > > On Fri, Mar 14, 2025 at 5:43 PM Nisha Moond
On Tue, Mar 18, 2025 at 4:25 PM vignesh C wrote:
>
> On Mon, 17 Mar 2025 at 16:51, Ashutosh Bapat
> wrote:
> >
> > On Mon, Mar 17, 2025 at 4:02 PM vignesh C wrote:
> > >
> > > On Mon, 17 Mar 2025 at 11:28, Shubham Khanna
> > > wrote:
> > > >
> > > > On Fri, Mar 14, 2025 at 5:43 PM Nisha Moond
On 18.03.2025 14:46, Ilia Evdokimov wrote:
However, I have a question: what value should planid have when we
execute the standard planner without using a planner_hook? For
example, if pg_stat_statementsis disabled, would planid default to
zero? If zero is the expected default, should we exp
В письме от пятница, 14 марта 2025 г. 11:35:15 MSK пользователь Álvaro Herrera
написал:
> > 1. `isnull` variable is actually needed in a very narrow scope, so
> > it is better to keep it in that scope, not keeping it in mind in while
> > dealing with the rest of the code.
> >
> > 2. Toast table
On Mon, Mar 17, 2025 at 4:30 PM Nathan Bossart wrote:
> On Mon, Mar 17, 2025 at 04:04:45PM -0400, Robert Haas wrote:
> > On Mon, Mar 17, 2025 at 3:34 PM Nathan Bossart
> > wrote:
> >> * Once committed, I should update one of my buildfarm animals to use
> >> PG_TEST_PG_UPGRADE_MODE=--swap.
> >
On 17.03.25 17:49, Jacob Champion wrote:
If we implement this, it needs to check that the keys were actually
sent during scram_exchange(). Having them set on the PGconn doesn't
mean that we used them for authentication.
We use the client key and server key on calculate_client_proof and
verify_s
On Tue, Mar 18, 2025 at 9:37 AM Alena Rybakina
wrote:
> Sorry, I figured it out. The Assert was added to avoid misuse of the function
> to reinitialize memory and to ensure that it happens when parallel_aware is
> positive.
Yeah. The assertion is supposed to suggest "don't worry, I didn't
forge
On Tue, Mar 18, 2025 at 9:58 AM Andrei Lepikhov wrote:
> I agree with him, too. But, as you can see, I proposed not changing the
> first string or adding something there but just putting extension data
> under that line. Extra information about workers' state (not so
> important most of the time,
On Tue, Mar 18, 2025 at 9:35 AM Peter Eisentraut wrote:
> So the way I understand this is that the options are:
>
> (1) We add a libpq function like PQconnectionUsedScramKeys() in the
> style of PQconnectionUsedPassword() and call that function during the
> checks.
>
> (2) We make use_scram_passth
On Tue, 18 Mar 2025 at 09:55, Anthonin Bonnefoy
wrote:
> I've added additional tests when piping queries with ';':
> - I've reused the same scenario with \sendpipeline: single query,
> multiple queries, flushes, syncs, using COPY...
> - Using ';' will replace the unnamed prepared statement. It's a
On Mon, 17 Mar 2025 at 22:57, Masahiko Sawada wrote:
>
> On Sun, Mar 9, 2025 at 11:16 PM Shlok Kyal wrote:
> >
> > On Fri, 28 Feb 2025 at 08:56, Amit Kapila wrote:
> > >
> > > On Fri, Feb 28, 2025 at 5:10 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Thu, Feb 27, 2025 at 12:52 AM Amit Kap
On Tue, Mar 18, 2025 at 1:50 AM Michael Paquier wrote:
> - count
>
> - 4
> -(1 row)
>
> This removal done in the regression tests was not intentional.
Yes, thanks for fixing that.
> How about adding a check on PIPELINE_COMMAND_COUNT when sending a
> query through this path? Should
On Thu, 27 Feb 2025 at 11:42, vignesh C wrote:
>
> On Thu, 6 Feb 2025 at 16:29, Umar Hayat wrote:
>
> This will include "ONLY" also when we display the tables too:
> + else if (HeadMatches("ANALYZE"))
> +
> COMPLETE_WITH_SCHEMA_QUERY_PLUS(Query_for_list_of_analyzables,
> "ONLY");
>
> like b
On 2025-Mar-18, Robert Haas wrote:
> The background here is that I'm kind of on the warpath against weird
> configurations that we only test on certain buildfarm animals at the
> moment, because the result of that is that CI is clean and then the
> buildfarm turns red when you commit. That's an un
On 2025-03-17 Mo 4:07 PM, Robert Haas wrote:
On Mon, Mar 17, 2025 at 2:17 PM Nathan Bossart wrote:
I think koel might complain. pgindent on my machine yields the following:
Indeed, it did. I still think it's a mistake to have testing for this
in the buildfarm and not in 'meson test' or CI.
On Tue, 2025-03-18 at 11:11 -0400, Tom Lane wrote:
> It's not apparent to me why that table needs to be in a header
> file and not in the sole user .c file?
Thank you, fixed.
> Also, probably better to make it const:
>
> -static const pg_wchar *casekind_map[NCaseKind] =
> +static const pg_wchar
> On 17 Mar 2025, at 16:48, Jacob Champion
> wrote:
>
> On Sun, Mar 16, 2025 at 6:49 AM Daniel Gustafsson wrote:
>> IIRC the reasoning has been that if a rogue user can inject an environment
>> variable into your session and read your files it's probably game over
>> anyways.
>
> (Personally
On Tue, 18 Mar 2025 at 13:43, Daniel Gustafsson wrote:
> Since there is disagreement over this, we should either 1) go ahead with the
> latest patch without an env var and revisit the discussion during v19; 2)
> adding the env var back into the patch as PGSSLKEYLOGFILE or; 3) postponing
> all
> o
On Mon, 17 Mar 2025 at 23:51, Matthias van de Meent
wrote:
>
> On Tue, 11 Mar 2025 at 16:53, Peter Geoghegan wrote:
> >
> > On Sat, Mar 8, 2025 at 11:43 AM Peter Geoghegan wrote:
> > > I plan on committing this one soon. It's obviously pretty pointless to
> > > make the BTMaxItemSize operate off
Re: Michael Paquier
> This is OK on its own, still feels a bit incomplete, as the relid also
> includes an assumption about the namespace. I would suggested to add
> a hardcoded "pg_temp" here, to keep track of this assumption, at
> least.
I had thought about it, but figured that integers and str
On Mon, 10 Mar 2025 at 16:26, Peter Eisentraut wrote:
>
> On 26.02.25 06:15, Paul Jungwirth wrote:
> > > ON DELETE RESTRICT must be specified when PERIOD BUSINESS_TIME is
> > also specified.
> >
> > Here are some patches removing support for RESTRICT
>
> I have committed this.
>
> I think this is
Hi,
On Tue, Mar 18, 2025 at 05:11:02PM +0900, Michael Paquier wrote:
> On Thu, Mar 13, 2025 at 01:18:45PM +, Bertrand Drouvot wrote:
> > This particular sub-patch needs a rebase though, done in the attached. 0001
> > remains unchanged as compared to the v4 one just shared up-thread. If 0001
>
> On Mon, Mar 17, 2025 at 08:14:16PM GMT, Álvaro Herrera wrote:
> On 2025-Mar-17, Álvaro Herrera wrote:
>
> > You can see my patch on top of yours here:
> > https://github.com/alvherre/postgres/commits/query_id_squash_values/
> > and the CI run here:
> > https://cirrus-ci.com/build/5660053472018432
On Mon, 17 Mar 2025 at 16:51, Ashutosh Bapat
wrote:
>
> On Mon, Mar 17, 2025 at 4:02 PM vignesh C wrote:
> >
> > On Mon, 17 Mar 2025 at 11:28, Shubham Khanna
> > wrote:
> > >
> > > On Fri, Mar 14, 2025 at 5:43 PM Nisha Moond
> > > wrote:
> > >
> > > Fixed.
> > >
> > > The attached patch contai
On Thu, Mar 13, 2025 at 12:50 AM Devulapalli, Raghuveer
wrote:
>
> > > Intel has contributed SSE4.2 CRC32C [1] and AVX-512 CRC32C [2] based on
> > similar techniques to postgres.
> >
> > ...this is a restatement of facts we already know. I'm guessing the intended
> > takeaway is "since Intel submi
On Tue, Mar 18, 2025 at 4:01 PM Shubham Khanna
wrote:
>
> On Tue, Mar 18, 2025 at 12:07 PM David G. Johnston
> wrote:
> >
>
> > It would be good if we could get this to play nicely with —dry-run; maybe
> > connecting to the source for the queries instead of the target. That would
> > help alle
On 18.03.2025 17:57, Ilia Evdokimov wrote:
Hi,
Thank you for the patch. However, Is it ok if I can't tab 'ONLY' in
VACUUM ANALYZE command?
CREATE TABLE only_parted (a int, b text) PARTITION BY LIST (a);
CREATE TABLE only_parted1 PARTITION OF only_parted FOR VALUES IN (1);
INSERT INTO only_p
Hi,
On commit 122a9af I can't see any problem with query:
explain analyze select * from t1 left join (select a, max(b) from t2
group by a) t2 on t1.a = t2.a;
QUERY PLAN
On 2025/03/18 18:17, Hayato Kuroda (Fujitsu) wrote:
Dear Fujii-san, David,
BTW, I'm curious why --dbname isn't required for the --drop-slot action.
I'm analyzing around here...
Actually, replication slots can be dropped from another database where it
created,
or even from the streaming
On Mon, Mar 17, 2025 at 10:46 PM Melanie Plageman
wrote:
>
> On Mon, Mar 17, 2025 at 2:55 PM Andres Freund wrote:
> >
> > On 2025-03-17 14:52:02 -0400, Melanie Plageman wrote:
> > > I don't feel strongly that we need to be as rigorous for
> > > maintenance_io_concurrency, but I'm also not sure 16
On 2025/03/12 14:59, David G. Johnston wrote:
On Monday, February 24, 2025, Hayato Kuroda (Fujitsu) mailto:kuroda.hay...@fujitsu.com>> wrote:
OK, so I will exclude the point in the thread. The patch I've posted
contains all of fixes
which is required.
The patch fixes the synopsis a
On Mon, 17 Mar 2025 at 12:18, Amit Kapila wrote:
>
> On Mon, Mar 10, 2025 at 11:46 AM Shlok Kyal wrote:
> >
> >
> > I tried to reproduce the scenario described using the following steps:
> >
> > Here are the steps:
> >
> > 1. set max_replication_slots = 2
> >
> > 2. create two logical replication
One more thing: I observe that headerscheck is now unhappy:
$ src/tools/pginclude/headerscheck
In file included from /tmp/headerscheck.yOpahZ/test.c:2:
./src/include/common/unicode_case_table.h:8598:24: warning: 'casekind_map'
defined but not used [-Wunused-variable]
static const pg_wchar *case
Dear hackers,
While considering another thread, I found the $SUBJECT. Attached patch fixes it.
Documentation says:
```
pg_drop_replication_slot ( slot_name name ) → void
Drops the physical or logical replication slot named slot_name. Same as
replication protocol command DROP_REPLICATION_SLOT.
On Tue, Feb 18, 2025 at 6:13 AM David G. Johnston
wrote:
>
> Table 9.9 limits itself to those functions defined in the SQL standard; which
> are basically the ones that use keywords instead of commas.
>
> The substring(string, start, count) function you note is already covered in
> Table 9.10 bu
On 3/18/25 08:31, Michael Paquier wrote:
On Thu, Feb 13, 2025 at 10:44:33AM -0600, Sami Imseih wrote:
The reason for the change is because "query jumble" will no longer
make sense if the jumble code can now be used for other types of
trees, such as Plan.
I do agree that this needs a single-thre
Hi,
On 2025-03-18 10:04:41 -0400, Tom Lane wrote:
> Robert Haas writes:
> > I'm not quite sure what the best thing is to do is for the pg_upgrade
> > tests in particular, and it may well be best to do as you propose for
> > now and figure that out later. But I question whether just rerunning
> >
> On Mar 18, 2025, at 9:34 AM, Robert Haas wrote:
>
> On Tue, Mar 18, 2025 at 9:27 AM Andrew Dunstan wrote:
>> Maybe we could have a TAP test module that would run it but only if you
>> have "code-indent" in your PG_TEST_EXTRA.
>
> What is the argument against always testing this?
>
>
Ju
Hi,
On Tue, Mar 18, 2025 at 11:19:32AM +0100, Jakub Wartak wrote:
> On Mon, Mar 17, 2025 at 5:11 PM Bertrand Drouvot
> wrote:
>
> > Thanks for v13!
>
> Rebased and fixes inside in the attached v14 (it passes CI too):
Thanks!
> > === 9
> >
> > + max_zones = pg_numa_get_max_node();
> >
>
On 18.03.2025 13:54, Alena Rybakina wrote:
On 12.03.2025 23:50, Peter Geoghegan wrote:
On Wed, Mar 12, 2025 at 4:28 PM Alena Rybakina
wrote:
Thank you for the explanation!
Now I see why these changes were made.
After your additional explanations, everything really became clear and I
full
Hi, Alexander!
On Tue, Mar 18, 2025 at 1:13 PM Alexander Pyhalov
wrote:
> Alexander Korotkov писал(а) 2025-03-18 03:27:
> > Hi, Robins!
> >
> > On Tue, Mar 18, 2025 at 2:20 AM Robins Tharakan
> > wrote:
> >> On Mon, 4 Dec 2023 at 07:22, Alexander Korotkov
> >> wrote:
> >> >
> >> >
> >> > Now, I
On Tue, Mar 18, 2025 at 9:27 AM Andrew Dunstan wrote:
> Maybe we could have a TAP test module that would run it but only if you
> have "code-indent" in your PG_TEST_EXTRA.
What is the argument against always testing this?
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
I performed some tests using elog(no so sure whether this is the proper way
to do it) to monitor the new method. Here are the findings:
• With PGSTAT_MIN_INTERVAL set to 1000ms, the number of flush reports was
reduced to approximately 40–50 during the installcheck test suite.
• With PGSTAT_I
On Fri, Mar 7, 2025 at 7:43 AM Vladlen Popolitov
wrote:
> >
> >> Updated patch rebased to the current master. Also I resolved the
> >> problems
> >> with the lookup of the compiled expressions.
> >> Cached jit compiles only expressions from cached plan - they are
> >> recognized by memory context
On 18.03.2025 15:25, vignesh C wrote:
On Thu, 27 Feb 2025 at 11:42, vignesh C wrote:
On Thu, 6 Feb 2025 at 16:29, Umar Hayat wrote:
This will include "ONLY" also when we display the tables too:
+ else if (HeadMatches("ANALYZE"))
+
COMPLETE_WITH_SCHEMA_QUERY_PLUS(Query_for_list_of_anal
Hi,
On 2025-03-18 10:45:41 +0100, Daniel Gustafsson wrote:
> Thanks for doing that, I'll try to get this in during a break in todays
> conference.
Thanks to both of you for fixing this!
I wonder how we could make it easier to find stuff like this and 274bbced853,
it's pretty painful right now.
On 2025/03/18 17:46, Hayato Kuroda (Fujitsu) wrote:
Dear hackers,
While considering another thread, I found the $SUBJECT. Attached patch fixes it.
Thanks for the patch!
Documentation says:
```
pg_drop_replication_slot ( slot_name name ) → void
Drops the physical or logical replication
On Tue, 18 Mar 2025 at 19:34, Masahiko Sawada wrote:
> I've attached the updated patch.
Looks good to me.
David
On Tue, 18 Mar 2025 at 21:00, Michael Paquier wrote:
> If we make the whole cheaper with only extra entropy added for NULLs
> in nodes and strings, I'd rather have an insurance policy for the
> custom functions. Something like that:
> - Forbid a size of 0 in AppendJumble().
> - When dealing with
On Thu, Feb 13, 2025 at 10:44:33AM -0600, Sami Imseih wrote:
> The reason for the change is because "query jumble" will no longer
> make sense if the jumble code can now be used for other types of
> trees, such as Plan.
>
> I do agree that this needs a single-threaded discussion to achieve a
> con
Dear David, Fujii-san,
> I think this is too:
> set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("pg_basebackup"));
I think it is intentional. IIUC, it accepts the directory which the file exists.
Please see commits fc995bfdbf.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
Dear Fujii-san,
Thanks for giving comments and sorry for missing replies.
> I agree that the synopsis doesn't need to be updated. Attached patch clarifies
> the required options for each action in the documentation. Thought?
So, the policy David said is not to modify the synopsis part here, beca
On 2025-Mar-18, Ranier Vilela wrote:
> Thanks Álvaro, for the commit.
Thank you for the impetus.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
On Tue, Mar 18, 2025 at 01:37:02PM -0400, Andres Freund wrote:
> I'd add a few more complications:
>
> - Create and test a relation that was rewritten, to ensure we test the
> relfilenode != oid case and one that isn't rewritten.
+1
> - Perhaps create a tablespace?
+1, I don't think we have m
On Tue, Mar 18, 2025 at 1:55 PM Tom Lane wrote:
> 10s added to every check-world run doesn't sound "cheap" to me.
Really? If you're sensitive to the time the tests take to run, maybe
use 'meson test' rather than 'make check-world'? I do that locally
with MESON_TESTTHREADS=8 and the entire test su
On Tue, Mar 18, 2025 at 03:03:52PM -0400, Andres Freund wrote:
> Subject: [PATCH v1] meson: Flush stdout in testwrap
>
> Otherwise the progress won't reliably be displayed during a test.
> ---
> src/tools/testwrap | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/tools/testwrap b/src/
On Tue, Mar 18, 2025 at 5:04 PM Andres Freund wrote:
> Is that actually a good description of what we assume? I don't know where
> that
> 90% is coming from?
That one's all my fault. It was an attempt to curve-fit backwards why the
4.0 number Tom set with his initial commit worked as well as i
On Tue, 2025-03-18 at 21:34 -0400, Robert Haas wrote:
> But I could not disagree more strongly with the idea that this
> problem
> is 99% solved. That doesn't seem remotely true to me. I'm not sure
> the
> problem is 1% solved.
If we compare the following two problems:
A. With glibc or ICU, eve
On Tue, Mar 18, 2025 at 10:16:20PM -0400, Bruce Momjian wrote:
> With the last commitfest underway:
>
> https://commitfest.postgresql.org/52/
>
> the release team has decided that the feature freeze deadline will be
> April 8, 2025, time zone Anywhere on Earth (AoE) (UTC-12):
>
> htt
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 17 Mar 2025 13:50:03 -0700,
Masahiko Sawada wrote:
> I think that built-in formats also need to have their handler
> functions. This seems to be a conventional way for customizable
> features such as t
On Tue, Mar 18, 2025 at 10:12:51AM -0400, Andres Freund wrote:
> On 2025-03-18 10:04:41 -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > I'm not quite sure what the best thing is to do is for the pg_upgrade
>> > tests in particular, and it may well be best to do as you propose for
>> > now and f
On Tue, Mar 18, 2025 at 02:08:42PM -0500, Nathan Bossart wrote:
> For now, here's a new version of the test with a rewritten table. I also
> tried to fix the expected error regex to handle some of the other error
> messages for unsupported modes (as revealed by cfbot).
And here is a new version o
1 - 100 of 186 matches
Mail list logo
