On Tue, Jul 23, 2024 at 6:56 AM Joseph Koshakow wrote:
>
> The specific bug that this patch fixes is preventing the following
> statement:
>
> # INSERT INTO arroverflowtest(i[-2147483648:2147483647]) VALUES ('{1}');
>
> So we may want to add that test back in.
>
I agree with you.
also v13-0
Hi Fujii-san,
Thank you for your comment!
attach v5 fixed patch.
Using "postgres" as the default superuser name can cause instability.
This is why the Patch Tester reports now test failures again.
You should create and use a different superuser, such as
"regress_stats_superuser."
I understand
Here are some review comments for patch v20240720-0002.
==
1. Commit message:
1a.
The commit message is stale. It is still referring to functions and
views that have been moved to patch 0003.
1b.
"ALL SEQUENCES" is not a command. It is a clause of the CREATE
PUBLICATION command.
==
doc/
On 2024/07/23 10:40, kuroda.keis...@nttcom.co.jp wrote:
I agree.
The information of different userids is mixed up.
It is easier to understand if the role name is displayed.
Join with pg_roles (view of pg_authid) to output the role name.
+ rolname | queryid_bool |
On Tue, Jul 9, 2024 at 12:39 AM John H wrote:
>
> > Out of curiosity, did you compare with standby_slot_names_from_syncrep set
> > to off
> > and standby_slot_names not empty?
>
> I didn't think 'standby_slot_names' would impact TPS as much since
> it's not grabbing the SyncRepLock but here's a q
On 2024/07/22 21:37, torikoshia wrote:
On Fri, Jul 19, 2024 at 11:48 PM Junwang Zhao wrote:
Thanks for the comment.
In patch 0002, the ratio is calculated by the already skipped/processed
rows, but what if a user wants to copy 1000 rows, and he/she can tolerate
10 error rows, so he/she migh
On Mon, Jul 22, 2024 at 9:12 AM shveta malik wrote:
>
> On Fri, Jul 19, 2024 at 2:52 AM John H wrote:
> >
> > Hi Shveta,
> >
> > Thanks for taking a look at the patch.
> >
> > > > will leave user no option to unlink failover-enabled logical
> > > > subscribers from the wait on synchronous standby
>
> * pg_set_relation_stats(): the warning: "cannot export statistics
> prior to version 9.2" doesn't make sense because the function is for
> importing. Reword.
>
+1
> * I really think there should be a transactional option, just another
> boolean, and if it has a default it should be true.
drop table t3;
CREATE TABLE t3( b bigint, c int GENERATED ALWAYS AS (b * 2) VIRTUAL);
insert into t3 (b) values (22147483647);
ANALYZE t3;
for ANALYZE
since column c has no actual storage, so it's not analyzable?
we need to change the function examine_attribute accordingly?
For the above exampl
On Mon, Jul 22, 2024 at 07:01:41AM +, Bertrand Drouvot wrote:
> 1 ===
> Not related with your patch but this comment in the GetRedoRecPtr() function:
>
> * grabbed a WAL insertion lock to read the authoritative value in
> * Insert->RedoRecPtr
>
> sounds weird. Should'nt that be s/In
On Mon, Jul 22, 2024 at 8:16 PM Nathan Bossart wrote:
>
> On Mon, Jul 22, 2024 at 03:45:19PM +0530, Amit Kapila wrote:
> > On Mon, Jul 22, 2024 at 7:35 AM Michael Paquier wrote:
> >> On Sat, Jul 20, 2024 at 09:03:07PM -0500, Nathan Bossart wrote:
> >> >> This is an extremely expensive way to perf
Dear Amit, Michael,
> > I am not sure to get the reason why get_old_cluster_logical_slot_infos()
> > could not be optimized, TBH. LogicalReplicationSlotHasPendingWal()
> > uses the fast forward mode where no changes are generated, hence there
> > should be no need for a dependency to a connection
On Tue, Jul 23, 2024 at 4:33 AM Michael Paquier wrote:
>
> On Mon, Jul 22, 2024 at 09:46:29AM -0500, Nathan Bossart wrote:
> > On Mon, Jul 22, 2024 at 03:45:19PM +0530, Amit Kapila wrote:
> >>
> >> Unlike subscriptions, logical slots are database-specific objects. We
> >> have some checks in the c
On Mon, Jul 22, 2024 at 6:26 PM Melanie Plageman
wrote:
>
> On Mon, Jul 22, 2024 at 6:36 PM Tom Lane wrote:
> >
> > Melanie Plageman writes:
> > > We've only run tests with this commit on some of the back branches for
> > > some of these animals. Of those, I don't see any failures so far. So,
>
On Thu, Jul 18, 2024 at 11:08 AM Richard Guo wrote:
> On Thu, Jul 18, 2024 at 10:02 AM Richard Guo wrote:
> > I noticed this while reviewing patch [1], thinking that it might be
> > worth fixing. Any thoughts?
>
> Here is the patch.
This patch is quite straightforward to remove the redundant co
On Mon, Jul 22, 2024 at 4:46 PM Amit Langote wrote:
>
> On Thu, Jul 18, 2024 at 3:04 PM jian he wrote:
> > we still have problem in transformJsonBehavior
> >
> > currently transformJsonBehavior:
> > SELECT JSON_VALUE(jsonb '1234', '$' RETURNING bit(3) DEFAULT 010111 ON
> > ERROR);
> > ERROR: c
On Mon, Jul 22, 2024 at 5:55 PM Richard Guo wrote:
> Otherwise I think the v3 patch looks good to me.
>
> Attached is an updated version of this patch with cosmetic changes and
> comment updates. It also squishes the two patches together into one.
> I'm planning to push it soon, barring any objec
On Mon, Jul 22, 2024 at 03:23:50PM -0400, Greg Sabino Mullane wrote:
> I saw a database recently where some app was inserting the source port into
> the application_name field, which meant that pg_stat_statements.max was
> quickly reached and queries were simply pouring in and out of
> pg_stat_stat
Alvaro Herrera 于2024年7月19日周五 21:18写道：
>
> I find this pair of queries useful; they show which constraints exist
> and which triggers belong to each. We need to make the constraints and
> triggers match after a detach right as things would be if the
> just-detached partition were an individual ta
Andrew Dunstan writes:
> On 2024-07-22 Mo 12:46 PM, Tom Lane wrote:
>> Masahiko Sawada writes:
>>> Looking at dodo's failures, it seems that while it passes
>>> module-xid_wraparound-check, all failures happened only during
>>> testmodules-install-check-C. Can we check the server logs written
>>>
Hi,
I'm reviewing patches in commitfest 2024-07:
https://commitfest.postgresql.org/48/
This is the 5th patch:
https://commitfest.postgresql.org/48/5054/
FYI: https://commitfest.postgresql.org/48/4681/ is my patch.
In
"Re: Separate HEAP WAL replay logic into its own file" on Tue, 18 Jun 2024
Hi Michael-san,
Thank you for your reply and comment!
attach v4 fixed patch.
We have two entries here with the same query and the same query ID,
because they have a different userid. Shouldn't this query reflect
this information rather than have the reader guess it? This is going
to require a
On Mon, Jul 22, 2024 at 12:53 PM Andrew Dunstan wrote:
>
>
> On 2024-07-22 Mo 12:46 PM, Tom Lane wrote:
>
> Masahiko Sawada writes:
>
> Looking at dodo's failures, it seems that while it passes
> module-xid_wraparound-check, all failures happened only during
> testmodules-install-check-C. Can we
On Mon, Jul 22, 2024 at 6:36 PM Tom Lane wrote:
>
> Melanie Plageman writes:
> > We've only run tests with this commit on some of the back branches for
> > some of these animals. Of those, I don't see any failures so far. So,
> > it seems the test instability is just related to trying to get
> >
On Mon, Jul 22, 2024 at 2:04 PM Melanie Plageman
wrote:
>
> On Mon, Jul 22, 2024 at 2:17 PM Melanie Plageman
> wrote:
> >
> > So, I've just gone through all the test failures on master and 17 for
> > mamba, gull, mereswine, and copperhead. I wanted to confirm that the
> > test was always failing
On Mon, 2024-07-22 at 12:05 -0400, Corey Huinker wrote:
> Attached is v24, incorporating Jeff's feedback - looping an arg data
> structure rather than individually checking each param type being the
> biggest of them.
>
Thank you for splitting up the patches more finely.
v24-0001:
* pg_set_re
Michael Paquier writes:
> Sawada-san and John are the two ones in the best position to answer
> that. I'm not sure either how to force a second index pass, either.
Yeah, I think we've established that having some way to force that,
without using a huge test case, would be really desirable. Mayb
Hi Fujii-san,
Thank you for your reply and comment!
attach v3 fixed patch.
Shouldn't we also include calls and rows in the ORDER BY clause?
Without this, if there are multiple records with the same query
but different calls or rows, the query result might be unstable.
I believe this is causing
On Mon, Jul 22, 2024 at 10:37:17AM -0700, Andres Freund wrote:
> On 2024-07-22 13:16:49 -0400, Robert Haas wrote:
>> Laziness would have been not bothering to develop a TAP test for this
>> at all. Going to the trouble of creating one and not being able to
>> make it as fast or as stable as everybo
On Tue, Jul 23, 2024 at 01:51:19AM +0900, Fujii Masao wrote:
> +SELECT query, calls, rows FROM pg_stat_statements
> + WHERE queryid IS NULL ORDER BY query COLLATE "C";
>
> Shouldn't we also include calls and rows in the ORDER BY clause?
> Without this, if there are multiple records with the same
On Mon, Jul 22, 2024 at 03:07:46PM -0700, Masahiko Sawada wrote:
> I'm slightly concerned that users might not want to see the NOTICE
> message for every scan. Unlike COPY FROM, scanning a file via file_fdw
> could be frequent. An alternative idea of place to write the
> information of the number o
On Fri, Jul 19, 2024 at 4:01 PM Shlok Kyal wrote:
>
> On Thu, 18 Jul 2024 at 13:55, Peter Smith wrote:
> >
> > Hi, here are some review comments for v19-0002
> > ==
> > src/test/subscription/t/004_sync.pl
> >
> > 1.
> > This new test is not related to generated columns. IIRC, this is just
> >
On Tue, Jul 23, 2024 at 1:44 AM Andrew Dunstan wrote:
> I have an environment I can use for testing. But what exactly am I
> testing? :-) Install a few "problem" language/region settings, switch
> the system and ensure initdb runs ok?
I just want to know about any weird unexpected consequences of
On Mon, Jul 22, 2024 at 09:46:29AM -0500, Nathan Bossart wrote:
> On Mon, Jul 22, 2024 at 03:45:19PM +0530, Amit Kapila wrote:
>> On Mon, Jul 22, 2024 at 7:35 AM Michael Paquier wrote:
>>> A comment in get_db_rel_and_slot_infos() becomes incorrect where
>>> get_old_cluster_logical_slot_infos() is
On Mon, Jul 22, 2024 at 6:27 PM Nathan Bossart
wrote:
>
> Actually, I think my concerns about prohibiting more than necessary go
away
> if we do the subtraction first. If "upperIndx[i] - lowerIndx[i]"
> overflows, we know the array size is too big. Similarly, if adding one to
> that result overf
Isaac Morland writes:
> And for when this might be useful, the syntax for it already exists,
> although a spurious error message is generated:
> odyssey=> select (uw_term).*, count(*) from uw_term group by uw_term;
> ERROR: column "uw_term.term_id" must appear in the GROUP BY clause or be
> used
Melanie Plageman writes:
> We've only run tests with this commit on some of the back branches for
> some of these animals. Of those, I don't see any failures so far. So,
> it seems the test instability is just related to trying to get
> multiple passes of index vacuuming reliably with TIDStore.
>
"David G. Johnston" writes:
> On Mon, Jul 22, 2024 at 1:55 PM David Christensen wrote:
>> I see that there'd been some chatter but not a lot of discussion about
>> a GROUP BY ALL feature/functionality. There certainly is utility in
>> such a construct IMHO.
> I strongly dislike adding this feat
On Mon, Jul 22, 2024 at 04:36:33PM -0500, Nathan Bossart wrote:
> Okay. I'll plan on committing v13-0002 in the next couple of days, then.
Actually, I think my concerns about prohibiting more than necessary go away
if we do the subtraction first. If "upperIndx[i] - lowerIndx[i]"
overflows, we kn
Hi,
On Thu, Jul 18, 2024 at 6:38 PM torikoshia wrote:
>
> On 2024-07-05 00:27, torikoshia wrote:
> > Hi,
> >
> > With the current file_fdw, if even one line of data conversion fails,
> > the contents of the file cannot be referenced at all:
> >
> > =# \! cat data/test.data
> > 1,a
> > 2,b
>
>
> On Mon, Jul 22, 2024 at 5:52 PM Alexander Lakhin
> wrote:
>
> > Also there are several trap-producing cases with date types:
> > SELECT to_date('1', 'CC');
>
> Hi, I’ve attached a patch that fixes the to_date() overflow. Patches 1
> through 3 remain unchanged.
>
> Thank you,
> Matthew
>
Hi,
Thank you for addressing this issue!
The patch needs to be rebased as it doesn’t apply on master anymore, but here
are some thoughts on the patch in general without testing:
1. Regarding the approach to force a checkpoint on every restartpoint record, I
wonder if it has any performan
On Mon, 22 Jul 2024 at 17:34, David G. Johnston
wrote:
> On Mon, Jul 22, 2024 at 1:55 PM David Christensen
> wrote:
>
>> I see that there'd been some chatter but not a lot of discussion about
>> a GROUP BY ALL feature/functionality. There certainly is utility in
>> such a construct IMHO.
>>
>>
On Mon, Jul 22, 2024 at 05:20:15PM -0400, Joseph Koshakow wrote:
> On Mon, Jul 22, 2024 at 11:17 AM Nathan Bossart
> wrote:
>> Am I understanding correctly that the main
>> behavioral difference between these two approaches is that users will see
>> different error messages?
>
> Yes, you are unde
On Mon, Jul 22, 2024 at 1:55 PM David Christensen wrote:
> I see that there'd been some chatter but not a lot of discussion about
> a GROUP BY ALL feature/functionality. There certainly is utility in
> such a construct IMHO.
>
> Still need some docs; just throwing this out there and getting some
I have bench marked the two patches now and failed to measure any
speedup or slowdown from the first patch (removing return) but I think
it is a good idea anyway.
For the second patch (optimize strict) I managed to measure a ~1% speed
up for the following query "SELECT sum(x + y + 1) FROM t;"
On Mon, Jul 22, 2024 at 11:17 AM Nathan Bossart
wrote:
> On Fri, Jul 19, 2024 at 07:32:18PM -0400, Joseph Koshakow wrote:
>> On Fri, Jul 19, 2024 at 2:45 PM Nathan Bossart
>> wrote:
>>> +/* dim[i] = 1 + upperIndx[i] - lowerIndx[i]; */
>>> +if (pg_add_s32_overflow(1, upperI
Robert,
Iam pleasedthatyouare payingso muchattentionto thispatch.
On 19.07.2024 16:26, Robert Haas wrote:
Second, I think that the threshold question for this patch is: will
users, on average, be happier if this patch gets committed? If the
answer is yes, then the patch should be committed, and
On Mon, Jul 22, 2024 at 2:17 PM Melanie Plageman
wrote:
>
> So, I've just gone through all the test failures on master and 17 for
> mamba, gull, mereswine, and copperhead. I wanted to confirm that the
> test was always failing for the same reason and also if it had any
> failures pre-TIDStore.
>
>
On Mon, Jul 8, 2024 at 2:35 AM Anthonin Bonnefoy
wrote:
>
> Hi,
>
> Thanks for the review, I've updated the patches with the suggestions:
> - moved renaming of misses to reads to the first patch
> - added intermediate variables for total blks usage
>
Thank you for working on this. 0001 patch look
I see that there'd been some chatter but not a lot of discussion about
a GROUP BY ALL feature/functionality. There certainly is utility in
such a construct IMHO.
The grammar is unambiguous, so can support this construct in lieu of
the traditional GROUP BY clause. Enclosed is a patch which adds t
On Fri, Jul 19, 2024 at 04:21:37PM -0500, Nathan Bossart wrote:
> However, while looking into this, I noticed that only one get_query
> callback (get_db_subscription_count()) actually customizes the generated
> query using information in the provided DbInfo. AFAICT we can do this
> particular step
On 2024-07-22 Mo 12:46 PM, Tom Lane wrote:
Masahiko Sawada writes:
Looking at dodo's failures, it seems that while it passes
module-xid_wraparound-check, all failures happened only during
testmodules-install-check-C. Can we check the server logs written
during xid_wraparound test in testmodule
Hi,
On 2024-07-22 08:46:03 -0400, Joe Conway wrote:
> On 7/21/24 17:26, Thomas Munro wrote:
> > On Mon, Jul 22, 2024 at 8:34 AM Joe Conway wrote:
> > > Hmmm, maybe nevermind? I rebooted the mac mini and now it seems to be
> > > working. Maybe someone can confirm. There ought to be plenty of space
I saw a database recently where some app was inserting the source port into
the application_name field, which meant that pg_stat_statements.max was
quickly reached and queries were simply pouring in and out of
pg_stat_statements, dominated by some "SET application_name = 'myapp
10.0.0.1:1234'" call
On 28/09/2023 12:58, Heikki Linnakangas wrote:
On 28/10/2022 06:56, Thomas Munro wrote:
One example is heavyweight lock wakeups. If you run BEGIN; LOCK TABLE
t; ... and then N other sessions wait in SELECT * FROM t;, and then
you run ... COMMIT;, you'll see the first session wake all the others
On Mon, Jul 22, 2024 at 9:46 AM Tom Lane wrote:
>
> Masahiko Sawada writes:
> > Looking at dodo's failures, it seems that while it passes
> > module-xid_wraparound-check, all failures happened only during
> > testmodules-install-check-C. Can we check the server logs written
> > during xid_wraparo
On Mon, Jul 22, 2024 at 2:13 PM Andres Freund wrote:
> It's hard by now (i.e. 17+) because you need substantial amounts of rows to be
> able to trigger it which makes it a hard fight to introduce.
I didn't think that it was particularly hard when I tested the test
that Melanie committed.
> And t
On Mon, Jul 22, 2024 at 1:17 PM Robert Haas wrote:
>
> On Mon, Jul 22, 2024 at 11:48 AM Tom Lane wrote:
> > I'm a little suspicious
> > of using it for tests that merely take an unreasonable amount of
> > time --- to me, that indicates laziness on the part of the test
> > author.
>
> Laziness wou
On 2024-07-22 12:00:51 -0400, Peter Geoghegan wrote:
> On Mon, Jul 22, 2024 at 11:49 AM Tom Lane wrote:
> > >> Andres has suggested in the past that we allow maintenance_work_mem be
> > >> set to a lower value or introduce some kind of development GUC so that
> > >> we can more easily test multipl
On Mon, Jul 22, 2024 at 1:18 PM Laurenz Albe wrote:
> I understand the difficulty (madness) of discussing every Unicode
> change. If that's unworkable, my preference would be to stick with some
> Unicode version and never modify it, ever.
I think that's a completely non-viable way forward. Even
On Wed, Jul 3, 2024 at 9:20 AM Daniel Gustafsson wrote:
> It's essentially just polish and adding comments with the functional
> changes that a) it parses the entire list of curves so all errors can be
> reported instead of giving up at the first error; b) leaving the cipher suite
> GUC blank will
On Mon, 22 Jul 2024 at 13:51, Jeff Davis wrote:
> > Are you proposing a switch that would make PostgreSQL error out if
> > somebody wants to use an unassigned code point? That would be an
> > option.
>
> You can use a CHECK(UNICODE_ASSIGNED(t)) in version 17, and in version
> 18 I have a propos
On Mon, 2024-07-22 at 19:18 +0200, Laurenz Albe wrote:
> I understand the difficulty (madness) of discussing every Unicode
> change. If that's unworkable, my preference would be to stick with
> some
> Unicode version and never modify it, ever.
Among all the ways that IMMUTABLE and indexes can go
On Mon, Jul 22, 2024 at 2:20 PM Robert Haas wrote:
> On Mon, Jul 22, 2024 at 1:00 PM Ahmed Yarub Hani Al Nuaimi
> wrote:
> > That is a very useful thread and I'll keep on following it but it is not
> exactly what I'm trying to achieve here.
> > You see, there is a great difference between VACUUM
On Mon, Jul 22, 2024 at 1:05 PM Laurenz Albe wrote:
> Before I write a v2, a small question for clarification:
> I believe I remember that during my experiments, I ran CHECKPOINT
> on the standby server between the first backup and the incremental
> backup, and that was not enough to make it work.
On 2024-07-22 13:16:49 -0400, Robert Haas wrote:
> On Mon, Jul 22, 2024 at 11:48 AM Tom Lane wrote:
> > I'm a little suspicious
> > of using it for tests that merely take an unreasonable amount of
> > time --- to me, that indicates laziness on the part of the test
> > author.
>
> Laziness would h
On Jul 22, 2024, at 03:12, Jeevan Chalke wrote:
> I agree with David that we need to set the tz explicitly as the JsonbValue
> struct maintains that separately.
>
> However, in the attached version, I have added some comments and also, fixed
> some indentation.
Thank you for the review. I cha
On Mon, Jul 22, 2024 at 1:00 PM Ahmed Yarub Hani Al Nuaimi
wrote:
> That is a very useful thread and I'll keep on following it but it is not
> exactly what I'm trying to achieve here.
> You see, there is a great difference between VACUUM FULL CONCURRENTLY and
> adding compaction to lazy vacuumin
On Mon, 2024-07-22 at 16:26 +0200, Peter Eisentraut wrote:
> I propose that, going forward, we take more care with Unicode updates:
> > assess the impact, provide time for comments, and consider possible
> > mitigations. In other words, it would be reviewed like any other
> > change.
>
> I disagre
On Mon, Jul 22, 2024 at 11:48 AM Tom Lane wrote:
> I'm a little suspicious
> of using it for tests that merely take an unreasonable amount of
> time --- to me, that indicates laziness on the part of the test
> author.
Laziness would have been not bothering to develop a TAP test for this
at all. G
On Fri, Jul 12, 2024 at 1:03 PM Daniel Gustafsson wrote:
> The original author added the string parsing in order to provide a good error
> message in case of an error in the list, and since that seemed like a nice
> idea
> I kept in my review revision. With what you said above I agree it's not w
Hi! Nice feature.
Few comments:
> + When a positive integer value is specified, COPY
> limits
> + the maximum tolerable number of errors while converting a column's
> input
> + value into its data type.
If nothing is specified, then the maximum tolerable number of errors
is one,
On Mon, 2024-07-22 at 09:37 -0400, Robert Haas wrote:
> How about something like this:
>
> An incremental backup is only possible if replay would begin from a
> later checkpoint than for the previous backup upon which it depends.
> On the primary, this condition is always satisfied, because each
>
That is a very useful thread and I'll keep on following it but it is not
exactly what I'm trying to achieve here.
You see, there is a great difference between VACUUM FULL CONCURRENTLY and
adding compaction to lazy vacuuming. The main factor here is resource
utilization: a lot of companies have enou
On 2024/07/22 15:23, kuroda.keis...@nttcom.co.jp wrote:
Hi Fujii-san,
Thank you for your reply and comment!
attach v2 fixed patch.
Thanks for updating the patch!
+SELECT query, calls, rows FROM pg_stat_statements
+ WHERE queryid IS NULL ORDER BY query COLLATE "C";
Shouldn't we also inclu
Hi,
On 2024-07-21 12:51:51 -0400, Tom Lane wrote:
> Melanie Plageman writes:
> > When I run it on my machine with some added logging, the space taken
> > by dead items is about 330 kB more than maintenance_work_mem (which is
> > set to 1 MB). I could roughly double the excess by increasing the
>
Masahiko Sawada writes:
> Looking at dodo's failures, it seems that while it passes
> module-xid_wraparound-check, all failures happened only during
> testmodules-install-check-C. Can we check the server logs written
> during xid_wraparound test in testmodules-install-check-C?
Oooh, that is indee
On Mon, 2024-07-22 at 11:14 -0400, Robert Haas wrote:
> On Mon, Jul 22, 2024 at 10:26 AM Peter Eisentraut
> wrote:
> > I disagree with that. We should put ourselves into the position to
> > adopt new Unicode versions without fear. Similar to updates to
> > time
> > zones, snowball, etc.
> >
> >
On Fri, May 24, 2024 at 01:15:13PM -0400, Robert Haas wrote:
> + /* Note that filename was already canonicalized */
>
> I see that this comment is copied from load_libraries(), but I don't
> immediately see where the canonicalization actually happens. Do you
> know, or can you find out? Because th
On Sun, Jul 21, 2024 at 2:36 PM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > On 2024-07-21 Su 1:34 PM, Tom Lane wrote:
> >> Locally, I've not managed to reproduce the failure yet; so perhaps
> >> there is some platform dependency. What are you testing on?
>
> > Linux ub22arm 5.15.0-116-generic
On Mon, Jul 22, 2024 at 11:49 AM Tom Lane wrote:
> >> Andres has suggested in the past that we allow maintenance_work_mem be
> >> set to a lower value or introduce some kind of development GUC so that
> >> we can more easily test multiple pass index vacuuming. Do you think
> >> this would be worth
Alvaro Herrera writes:
> I think it's a bad idea to require buildfarm owners to edit their config
> files as we add tests that depend on PG_TEST_EXTRA. AFAIR we invented
> that setting so that tests that had security implications could be made
> opt-in instead of opt-out; I think this was a sensi
On 2024-07-19 Fr 9:46 AM, Thomas Simpson wrote:
Hi Scott,
I realize some of the background was snipped on what I sent to the
hacker list, I'll try to fill in the details.
Short background is very large database ran out of space during vacuum
full taking down the server. There is a replic
Peter Geoghegan writes:
> On Mon, Jul 22, 2024 at 9:32 AM Melanie Plageman
> wrote:
>> Andres has suggested in the past that we allow maintenance_work_mem be
>> set to a lower value or introduce some kind of development GUC so that
>> we can more easily test multiple pass index vacuuming. Do you
Melanie Plageman writes:
> On Sun, Jul 21, 2024 at 5:04 PM Tom Lane wrote:
>> I note also that the PG_TEST_EXTRA approach has caused xid_wraparound
>> to get next-to-zero buildfarm coverage. If that test is actually
>> capable of revealing problems, we're unlikely to find out under the
>> status
On Mon, 2024-07-22 at 16:26 +0200, Peter Eisentraut wrote:
> Unless I missed something here, all the problem examples involve
> unassigned code points that were later assigned.
For normalization and case mapping that's right.
For regexes, a character property could change. But that's mostly a
th
On Fri, Jul 19, 2024 at 07:32:18PM -0400, Joseph Koshakow wrote:
> On Fri, Jul 19, 2024 at 2:45 PM Nathan Bossart
> wrote:
>> +/* dim[i] = 1 + upperIndx[i] - lowerIndx[i]; */
>> +if (pg_add_s32_overflow(1, upperIndx[i], &dim[i]))
>> +ereport(ERROR,
>> +
On Mon, Jul 22, 2024 at 9:32 AM Melanie Plageman
wrote:
> Andres has suggested in the past that we allow maintenance_work_mem be
> set to a lower value or introduce some kind of development GUC so that
> we can more easily test multiple pass index vacuuming. Do you think
> this would be worth it?
On Mon, Jul 22, 2024 at 10:26 AM Peter Eisentraut wrote:
> I disagree with that. We should put ourselves into the position to
> adopt new Unicode versions without fear. Similar to updates to time
> zones, snowball, etc.
>
> We can't be discussing the merits of the Unicode update every year.
> Th
Hi
po 22. 7. 2024 v 17:08 odesílatel Konstantin Knizhnik
napsal:
>
> On 16/01/2024 5:38 pm, Tomas Vondra wrote:
>
> By "broken" you mean that you prefetch items only from a single leaf
>
> page, so immediately after reading the next one nothing is prefetched.
> Correct?
>
>
> Yes, exactly. It me
I went ahead and committed 0001, which is pretty trivial. Hopefully,
at least, it's trivial enough that I didn't mess it up.
Here's a rebase of 0002 and 0003, now 0001 and 0002, with one minor
fix to hopefully avoid annoying CI.
I'm still hoping for some review/feedback/testing of these before I
On Mon, Jul 22, 2024 at 03:45:19PM +0530, Amit Kapila wrote:
> On Mon, Jul 22, 2024 at 7:35 AM Michael Paquier wrote:
>> On Sat, Jul 20, 2024 at 09:03:07PM -0500, Nathan Bossart wrote:
>> >> This is an extremely expensive way to perform that check, and so I'm
>> >> wondering why we don't just do
>
On 14.07.24 16:51, Tom Lane wrote:
Peter Eisentraut writes:
On 04.07.24 03:55, Thomas Munro wrote:
Personally, I find "PRId64" pretty unreadable. "INT64_MODIFIER" wasn't
nice either, though, and following standards is good, so I'm sure I'll
get used to it.
Using PRId64 would be very benefic
On Fri, 12 Jul 2024 at 15:58, Greg Sabino Mullane
wrote:
> On Thu, Jul 11, 2024 at 6:47 AM Alastair Turner
> wrote:
>
>> The other category of logging which would benefit from a separate file
>> is audit. It also can create massive volumes of log content. Splitting
>> audit information off into
On 19.07.24 21:41, Jeff Davis wrote:
On Fri, 2024-07-19 at 21:06 +0200, Laurenz Albe wrote:
Perhaps I should moderate my statement: if a change affects only a
newly
introduced code point (which is unlikely to be used in a database),
and we
think that the change is very important, we could consid
Do you actually have 100G networking between the nodes? Because if not, a
single CPU should be able to saturate 10G.
Likewise the receiving end would need disk capable of keeping up. Which brings
up the question, why not write to disk, but directly to the destination rather
than write locally
On 2024-Jul-22, Melanie Plageman wrote:
> On Sun, Jul 21, 2024 at 5:04 PM Tom Lane wrote:
> > I note also that the PG_TEST_EXTRA approach has caused xid_wraparound
> > to get next-to-zero buildfarm coverage. If that test is actually
> > capable of revealing problems, we're unlikely to find out
On 19.07.24 12:40, Aleksander Alekseev wrote:
It seems to me that the patch is not going to become any better and it
doesn't need any more attention from the reviewers. Thus I changed the
status of the CF entry to "Ready for Committer".
I'm happy to commit this patch.
I checked that for non-LT
Andrew Dunstan , 22 Tem 2024 Pzt, 16:44 tarihinde şunu
yazdı:
> I have an environment I can use for testing. But what exactly am I
> testing? :-) Install a few "problem" language/region settings, switch
> the system and ensure initdb runs ok?
>
> Other than Turkish, which locales should I install?
1 - 100 of 143 matches
Mail list logo
