Hi All,
We propose enabling SIMD-based sort for list_sort using the x86-simd-sort
library (https://github.com/intel/x86-simd-sort).
The existing list_sort takes a comparator function to compare pairs of
ListCell. On the other hand, x86-simd-sort requires an array of numeric values
to sort, and
Hi,
On Fri, Nov 22, 2024 at 10:36:29AM +0900, Michael Paquier wrote:
> On Thu, Nov 21, 2024 at 05:23:42PM +, Bertrand Drouvot wrote:
> > So, given that:
> >
> > - the end result would be the same
> > - the code changes would be non negligible (unless we have a better idea
> > than
> > pgstat
On Wed, Nov 20, 2024 at 12:07 AM Michael Paquier wrote:
> On Tue, Nov 19, 2024 at 09:39:21AM -0500, Greg Sabino Mullane wrote:
> > Oh, and a +1 in general to the patch, OP, although it would also be nice to
> > start finding the bottlenecks that cause such performance issues.
>
> FWIW, I'm not eag
Hello,
On 2024-11-21 22:59, Andres Freund wrote:
What's the problem with the current approach? It's hard to believe the
build
time of these modules is meaningful in any sort of way.
Thank you for your question! There are no real problems except my own
small trouble with checksums of installe
On Thu, Nov 21, 2024 at 10:50:41PM +0300, Pavel Luzanov wrote:
> I found that the help for \pset command missed xheader_width option.
> Please, consider this small correction.
Good catch. This is a mistake from a45388d6e098. The patch should
have used HELP0() as this is a single variable, and th
On Thu, Nov 21, 2024 at 12:57:18PM -0500, Yogesh Sharma wrote:
> Thanks for patch. I have tested both patches and they work as per design.
I've missed your message, sorry about that.
--
Michael
signature.asc
Description: PGP signature
Thanks for the review, Nitin! Attached v3 addresses your review feedback.
On Sat, Nov 2, 2024 at 7:05 AM Nitin Jadhav
wrote:
>
> 1.
> > + BlockNumber vm_page_freezes;/* # pages newly set all-frozen in VM */
> > + BlockNumber vm_page_visibles; /* # pages newly set all-visible in the
> >
On Thu, Nov 21, 2024 at 05:23:42PM +, Bertrand Drouvot wrote:
> So, given that:
>
> - the end result would be the same
> - the code changes would be non negligible (unless we have a better idea than
> pgstat_get_entry_ref() returning a NULL value).
Hmm. created_entry only matters for pgstat_
On Thu, Nov 21, 2024 at 08:49:13AM +, Bertrand Drouvot wrote:
> On Thu, Nov 21, 2024 at 10:38:28AM +0300, Nazir Bilal Yavuz wrote:
>> -if (!info || !info->fixed_amount)
>> +/* skip if not fixed or this kind does not want to write to the
>> file */
>> +if (!info || !info
Jelte Fennema-Nio writes:
> On Thu, 21 Nov 2024 at 02:31, Tom Lane wrote:
>> This seems to fix the problem here. Thoughts?
> Overall, a good approach to fix issue number 1. I think it would be
> best if this was integrated into libpqsrv_cancel instead though. That
> way the dblink would benefit
On Thu, 21 Nov 2024, 17:18 Erik Nordström, wrote:
> Hello,
>
> I've noticed a change in behavior of the heap rewrite functionality in
> PostgreSQL 17, used by, e.g., CLUSTER. I've been experimenting with the
> functionality to implement a way to merge partitions in TimescaleDB. I am
> using table
On Wed, Nov 20, 2024 at 07:45:40AM +0900, Michael Paquier wrote:
> On Tue, Nov 12, 2024 at 02:48:28PM +0100, Tomas Vondra wrote:
>> Thanks for the patch, seems like a useful feature. Please add the patch
>> to the next commitfest (2025-01) at https://commitfest.postgresql.org/
>
> FYI, I have a la
On Wed, 2024-11-20 at 06:41 +0100, Laurenz Albe wrote:
> That looks like a nice idea, since it obviates the need to build
> PostgreSQL yourself if you want to use a non-standard copy of - say -
> the ICU library. You still have to build your own ICU library,
> though.
It would work with the built
> I think it is in pretty good shape. After a read-through, the only thing
> that stands
> out to me is the difference in configure tests between autoconf and meson. I
> think we should consider picking one approach, although I'm not sure I have a
> strong preference.
Thanks for the review! We
On 11/21/24 14:59, Tomas Vondra wrote:
>
> ...
>
> But then there's the SQL API - pg_logical_slot_get_changes(). And it
> turns out it ends up syncing the slot to disk pretty often, because for
> RUNNING_XACTS we call LogicalDecodingProcessRecord() + standby_decode(),
> which ends up calling SaveS
On 11/21/24 15:43, Robert Haas wrote:
On Thu, Nov 21, 2024 at 2:06 PM Joe Conway wrote:
Because that idea was rejected earlier in the thread by multiple people
other than me?
¯\_(ツ)_/¯
I actually don't see that in the thread anywhere. Which messages are
you talking about?
Well there is
On 2024-11-21 19:18 +0100, Thomas Simpson wrote:
> Looking through the archives, around 20 years ago someone asked about
> getting a list of points from a polygon [15 AUG 2004] and the reply was this
> was not available but something like point(polygon, n) could be added
> relatively easily as a ne
On Wed, Nov 20, 2024 at 05:37:33PM +, Devulapalli, Raghuveer wrote:
> Anymore feedback on this patch? Hoping this is a straightforward one.
I think it is in pretty good shape. After a read-through, the only thing
that stands out to me is the difference in configure tests between autoconf
and
On 2024-11-21 Th 3:52 PM, Alexandra Wang wrote:
Hi,
On Tue, Nov 19, 2024 at 6:06 PM Nikita Glukhov wrote:
Hi, hackers.
I have implemented dot notation for jsonb using type subscripting back
in April 2023, but failed post it because I left Postgres Professional
company soon after and have no
On Fri, Nov 1, 2024 at 5:39 PM Masahiko Sawada wrote:
>
> I think we agreed with what the patches proposed by Melanie do, so
> let's focus on these patches on this thread. We can add other
> information later if we need.
Thanks for the feedback and input.
So, currently what I have is a line for u
Hi,
On 2024-11-21 23:52:52 +0300, Andrey M. Borodin wrote:
> I suspect that protection of temp tables was broken by 00d1e02be249.
I think we might have broken this in multiple ways in recent releases. In 17
one can even read the data from the other relation when using a sequential
scan, because t
There may be something wrong with my previous description, "Should nhtids be
less than or equal to IndexTupleSize(oposting)?
Why is nhtids larger than IndexTupleSize(oposting) " Here nhtids should be
nmovebytes.
It is normal whether nhtids is larger than IndexTupleSize(oposting) or smaller
tha
On Thu, 21 Nov 2024 at 02:31, Tom Lane wrote:
> Anyway, given that info, Jelte's unapplied 0002 patch earlier in the
> thread is not the answer, because this is about dropping a query
> cancel not about losing a timeout interrupt.
Agreed that 0002 does not fix the issue re-reported by Andres (let
> On 21 Nov 2024, at 02:24, Masahiko Sawada wrote:
>
> But does replacing the least significant 2 bits
> with random 2 bits really not affect monotonicity?
You are right. We have to take into account this when calculating monotonicity.
PFA another version.
Best regards, Andrey Borodin.
v
Hi,
On Tue, Nov 19, 2024 at 6:06 PM Nikita Glukhov wrote:
>
> Hi, hackers.
>
> I have implemented dot notation for jsonb using type subscripting back
> in April 2023, but failed post it because I left Postgres Professional
> company soon after and have not worked anywhere since, not even had
> an
> On 14 Nov 2024, at 11:55, Daniil Davydov <3daniss...@gmail.com> wrote:
>
> On Wed, Oct 30, 2024 at 7:32 PM Rafia Sabih wrote:
>
>> Good catch. I agree with this being an unwarranted behaviour.
>> A minor comment from my end is the wording of the error message.
>> Based on the Postgresql err
On Thu, Nov 21, 2024 at 2:06 PM Joe Conway wrote:
> Because that idea was rejected earlier in the thread by multiple people
> other than me?
>
>¯\_(ツ)_/¯
I actually don't see that in the thread anywhere. Which messages are
you talking about?
--
Robert Haas
EDB: http://www.enterprisedb.com
New patch series attached.
* a few cleanup patches, but 0001 and 0004 can affect initial hash
table sizing
* also pack AggStatePerGroupData (to 10 bytes)
* put additional data in the same chunk as firstTuple to avoid an
extra pointer an an extra allocation
On Tue, 2024-11-19 at 01:30 +0200
On Fri, Nov 22, 2024 at 8:59 AM Jacob Champion
wrote:
> On Thu, Nov 21, 2024 at 5:53 AM Thomas Munro wrote:
> > The lseek() is suspicious too,
> > and might need to be redirected to _lseeki64().
>
> There's a call to ftruncate() in there too. Looks like its Windows
> definition is also 32-bit:
>
> On Fri, Jun 21, 2024 at 10:35:30AM GMT, Richard Guo wrote:
> On Mon, Jan 15, 2024 at 1:50 PM Richard Guo wrote:
> > Updated this patch over 29f114b6ff, which indicates that we should apply
> > the same rules for PHVs.
>
> Here is a new rebase of this patch, with some tweaks to comments. I've
>
I found that the help for \pset command missed xheader_width option.
Please, consider this small correction.
--
Pavel Luzanov
Postgres Professional:https://postgrespro.com
From a5f59e77f3caf5b6bbbfc441393da68999e9e9fc Mon Sep 17 00:00:00 2001
From: Pavel Luzanov
Date: Thu, 21 Nov 2024 22:32:44 +
On Thu, Nov 21, 2024 at 5:53 AM Thomas Munro wrote:
> The lseek() is suspicious too,
> and might need to be redirected to _lseeki64().
There's a call to ftruncate() in there too. Looks like its Windows
definition is also 32-bit:
#define ftruncate(a,b) chsize(a,b)
--Jacob
On 11/20/24 12:14, Daniel Gustafsson wrote:
On 19 Nov 2024, at 18:30, Joe Conway wrote:
Any other opinions out there?
Couldn't installations who would be satisfied with a GUC gate revoke privileges
from the relevant functions already today and achieve almost the same result?
I think that
On 11/19/24 18:12, Robert Haas wrote:
On Tue, Nov 19, 2024 at 12:30 PM Joe Conway wrote:
Any other opinions out there?
Why should we accept your patch (which adds a legacy_crypto_enabled
GUC) instead of adopting the approach originally proposed (i.e. use
the OpenSSL version of the functions)?
On Tue, Nov 19, 2024 at 3:05 AM Peter Eisentraut wrote:
> Personally, I'm not even a fan of the -Dssl/--with-ssl system. I'm more
> attached to --with-openssl. But if you want to stick with that, a more
> suitable naming would be something like, say, --with-httplib=curl, which
> means, use curl
Hi
Looking through the archives, around 20 years ago someone asked about
getting a list of points from a polygon [15 AUG 2004] and the reply was
this was not available but something like point(polygon, n) could be
added relatively easily as a new feature to extract points.
I'm hitting an iss
On Thu, Nov 21, 2024 at 01:56:36PM +0100, Peter Eisentraut wrote:
> Ok, I have committed the fix for this, and I'll continue working through the
> rest of the patches.
nitpick: I think this one needs a pgindent [0].
[0]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=koel&dt=2024-11-21%2
Em qui., 21 de nov. de 2024 às 12:02, Marcos Pegoraro
escreveu:
Well, all comparisons with JSONs runs differently with null values, so
maybe an example would help
select f1 = f2 "JS Object Equal - Right",
f1->'a' = f2->'a' "JS Value Equal - Right",
f1->>'a' = f2->>'a' "Text Equal -
In light of CVE-2024-10976, which was fixed by commit cd7ab57, I'd like to
propose a bigger change to this area of the code that aims to future-proof
it a bit. Instead of requiring hackers to carefully cart around whether a
query references a table with RLS enabled, I think we should instead
accum
Hi,
Thanks for patch. I have tested both patches and they work as per design.
My +1 for v1, it is much cleaner approach and has properly named
functions whereas in v2 it is not.
Injection points is documented, if so, doc patch is missing.
Regards,
Yogesh
On 11/20/24 12:13, Bertrand Drouvot
Hi,
On Thu, Nov 21, 2024 at 07:18:24AM +0900, Michael Paquier wrote:
> On Wed, Nov 20, 2024 at 02:20:18PM +, Bertrand Drouvot wrote:
> > Right. I did not had in mind to go that far here (for the per backend stats
> > needs). My idea was "just" to move the new pgstat_create_backend_stat()
> >
On Fri, Jun 28, 2024 at 1:39 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> The attached are complete and ready for review. I did some file structure
> reformatting at the end and left that as the second patch. The first
> contains all of the content.
>
To help manage this fairly l
On 2024-Nov-21, Alexander Kukushkin wrote:
> Oh, nice catch.
Yeah, sharp eyes there.
> The attached patch should address it.
Thanks, pushed.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"The Gord often wonders why people threaten never to come back after th
Hi.
Em qui., 21 de nov. de 2024 às 12:46, Sanjay Khatri <
sanjaykhatri...@gmail.com> escreveu:
> Yes...I have myself installed pgAmdin more than 50 times so far. But this,
> for the first time ever I have faced this issue. Just try deleting the
> pgAdmin.bak file for the pg15.8 on a Windows serve
Hello,
I've noticed a change in behavior of the heap rewrite functionality in
PostgreSQL 17, used by, e.g., CLUSTER. I've been experimenting with the
functionality to implement a way to merge partitions in TimescaleDB. I am
using table_relation_copy_for_cluster() to write the data of several table
On Thursday, November 21, 2024 17:56 MSK, "Vitaly Davydov"
wrote:
> I'm trying to create a perl test to reproduce it. Please, give me some time
> to create the test script.
Attached is the test script which reproduces my problem. It should be run on a
patched postgresql with the following cha
On 2024-Nov-19, Will Mortensen wrote:
> Sounds good to me. :-)
Pushed, thanks for reporting this.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Entristecido, Wutra (canción de Las Barreras)
echa a Freyr a rodar
y a nosotros al mar"
Hi,
On 2024-11-21 13:40:18 +0700, Zharkov Roman wrote:
> What do you think?
What's the problem with the current approach? It's hard to believe the build
time of these modules is meaningful in any sort of way.
Greetings,
Andres Freund
On Thu, Nov 21, 2024 at 10:03 AM yuansong wrote:
> Should nhtids be less than or equal to IndexTupleSize(oposting)?
> Why is nhtids larger than IndexTupleSize(oposting) ? I think there should be
> an error in the master host writing the wal log.
> Does anyone know when this will happen?
It'll h
> On 20 Nov 2024, at 23:35, Mikhail Gribkov wrote:
>
> Now, in the second session we will try to insert couple of rows into this
> table:
Recently I saw a report and proposed fix here [0]. I did not dig into, just
connection internets. Thanks!
Best regards, Andrey Borodin.
[0]
https://w
Yes...I have myself installed pgAmdin more than 50 times so far. But this,
for the first time ever I have faced this issue. Just try deleting the
pgAdmin.bak file for the pg15.8 on a Windows server 2016.
Try doing that, lets see.
On Thu, 21 Nov 2024, 21:13 Dave Page, wrote:
>
>
> On Thu, 21 Nov
I know its hard to believe this. But you can try doing this from your side
and respond here back again.
On Thu, 21 Nov 2024, 20:49 Robert Haas, wrote:
> On Thu, Nov 21, 2024 at 9:53 AM Dave Page wrote:
> > Speaking as a pgAdmin dev, and someone with a fair amount of Windows
> experience over th
On Thu, 21 Nov 2024 at 15:35, Sanjay Khatri
wrote:
> I know its hard to believe this. But you can try doing this from your side
> and respond here back again.
>
I can't speak for Robert, but I've installed and run pgAdmin literally
hundreds of times on Windows, Mac, and Linux, and have never see
On Thu, Nov 21, 2024 at 6:50 AM Marcos Pegoraro wrote:
> About JSONB_PATH, you said that "JSON null value is considered equal to
> other JSON null values", but didn't say anything about IS DISTINCT FROM
> at jsonb_path level. Wouldn't be good to mention something about it ?
>
> select '{1,2}'::in
On Thu, Nov 21, 2024 at 9:53 AM Dave Page wrote:
> Speaking as a pgAdmin dev, and someone with a fair amount of Windows
> experience over the years, I'd say there is approximately zero chance that
> deleting a file from a user's roaming profile directory would brick a server,
> especially a bac
On Wed, Nov 20, 2024 at 5:47 PM Tom Lane wrote:
>
> Mikhail Gribkov writes:
> > What do you think?
>
> I think this will break cases we don't want to break.
>
> Accessing the metadata of other temp tables is fine, and indeed
> necessary for operations like dropping them. It's access to
> the tab
Em qui., 21 de nov. de 2024 às 11:42, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
>
> I'm not following your train of thought here. Since null == null in
> json-land there isn't a need for or concept of "is distinct from". We tend
> to not expend space on pointing out things that d
On Wed, Nov 20, 2024 at 7:24 PM jian he wrote:
> On Wed, Nov 20, 2024 at 11:57 PM David G. Johnston
> wrote:
> >
> >> -
> >> in doc/src/sgml/nullvalues.sgml
> >> see the attached for one example output
> >>
> >> in doc/src/sgml/nullval
My database version is Postgresql 13.2 , backup server core when redo a
btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
#0 0x2aab66695d86inmemmove ssse3 krom /lib64/libc.so.6
#1
0x004f5574in_bt_swap_posting(newitem=0x125d998,oposting=0x2aabcd55dcc8ostingoff=13)
at nbt
Hi Tomas,
Thank you for the reply and your interest to the investigation.
On Wednesday, November 20, 2024 20:24 MSK, Tomas Vondra wrote:
> If an existing physical slot is advanced in the middle of checkpoint
> execution, WAL segments, which are related to saved on disk restart LSN
> may be r
On Thu, 21 Nov 2024 at 14:19, Tomas Vondra wrote:
>
>
> On 11/21/24 15:03, Daniel Gustafsson wrote:
> >> On Thu, 21 Nov 2024, 17:46 Daniel Gustafsson, wrote:
> >>> On 21 Nov 2024, at 04:22, Sanjay Khatri
> wrote:
> >>>
> >>> We tried it on another server with similar configurations.
> >>> Just
On 11/21/24 15:03, Daniel Gustafsson wrote:
>> On Thu, 21 Nov 2024, 17:46 Daniel Gustafsson, wrote:
>>> On 21 Nov 2024, at 04:22, Sanjay Khatri wrote:
>>>
>>> We tried it on another server with similar configurations.
>>> Just installed the Postgres 15 and its PgAdmin.
>>> Kept the server ONN
But my concern is it occured only after deleting the pgAdmin.bak file.
On Thu, 21 Nov 2024, 19:54 Sanjay Khatri, wrote:
> Yeah maybe, we contacted a Hardware Engineer, he told to clean the RAM,
> etc. If still does not works, then some issue with the motherboard.
>
> On Thu, 21 Nov 2024, 19:49 T
Yeah maybe, we contacted a Hardware Engineer, he told to clean the RAM,
etc. If still does not works, then some issue with the motherboard.
On Thu, 21 Nov 2024, 19:49 Tomas Vondra, wrote:
>
>
> On 11/21/24 15:03, Daniel Gustafsson wrote:
> >> On Thu, 21 Nov 2024, 17:46 Daniel Gustafsson, wrote:
> On Thu, 21 Nov 2024, 17:46 Daniel Gustafsson, wrote:
> > On 21 Nov 2024, at 04:22, Sanjay Khatri wrote:
> >
> > We tried it on another server with similar configurations.
> > Just installed the Postgres 15 and its PgAdmin.
> > Kept the server ONN for the whole day, the server was okay.
> > But
On 11/20/24 23:19, Tomas Vondra wrote:
> On 11/20/24 18:24, Tomas Vondra wrote:
>>
>> ...
>>
>> What confuses me a bit is that we update the restart_lsn (and call
>> ReplicationSlotsComputeRequiredLSN() to recalculate the global value)
>> all the time. Walsender does that in PhysicalConfirmRecei
On Tue, Dec 5, 2023 at 12:45 AM Matthias van de Meent
wrote:
>
> On Mon, 31 Oct 2022 at 15:56, Michel Pelletier
> wrote:
> > On Mon, Oct 31, 2022 at 6:15 AM Matthias van de Meent
> > wrote:
> >> On Mon, 31 Oct 2022 at 13:46, Alexander Korotkov
> >> wrote:
> >>> On Fri, Oct 28, 2022 at 4:27 PM
> On 19 Nov 2024, at 17:39, Greg Sabino Mullane wrote:
>
> I'm curious what "using it wrong" means exactly?
Here's an example. pgSCV is querying pgss for every database separately every
minute. It makes sense for the project. But when you have ~1000 databases, you
have a lot of traffic to p
On Thu, Nov 21, 2024 at 11:44 PM Jakub Wartak
wrote:
> This literally looks like something like off_t/size_t would be limited to
> 2^31 somewhere.
off_t is 32 bits on Windows. I'd be quite suspicious of the
arithmetic involving 'currpos'. What happens if you change all the
off_t in walmethods.
Matthias van de Meent writes:
> On Thu, 21 Nov 2024 at 13:03, Toto guyoyg wrote:
>>
>> Offending O(n²) query:
> I disagree with the O(n^2) claims.
I think these cases actually are O(n^2). But I'm finding it hard
to care. What we have here is a straightforward way to write a
query versus a mu
Yes we are talking about same thing.
But this time a different server with Similar configuration.
On deleting the pgAdmin.bak file after which I restarted pgAdmin. But after
an hour or two, the machine crashed and refuses to boot.
And yes these machines have enough firewall protection.
On Thu, 21
About JSONB_PATH, you said that "JSON null value is considered equal to
other JSON null values", but didn't say anything about IS DISTINCT FROM at
jsonb_path level. Wouldn't be good to mention something about it ?
select '{1,2}'::integer[] is distinct from null::integer[]
select jsonb_path_exists(
Yes...I willbut in case someone could provide help it would be good.
Rest I will contact the Hardware Support.
On Wed, 20 Nov 2024, 19:11 Daniel Gustafsson, wrote:
> > On 20 Nov 2024, at 14:34, Sanjay Khatri
> wrote:
> >
> > These are the errors from the logs of iDrac M630.
> > I uninstalle
> On 21 Nov 2024, at 04:22, Sanjay Khatri wrote:
>
> We tried it on another server with similar configurations.
> Just installed the Postgres 15 and its PgAdmin.
> Kept the server ONN for the whole day, the server was okay.
> But then we tried the pgAdmin workaround by deleting the pgAdmin.bak fi
On Thu, 21 Nov 2024 at 13:03, Toto guyoyg wrote:
>
> Offending O(n²) query:
I disagree with the O(n^2) claims. The number of live matched rows in
a single table's bitmap scan may be anywhere from 0 (leading to O(1)
complexity in the rescan) to 970_662_608_670 (= 226 tuples per page *
(2^32 - 1) p
On 14.11.24 18:25, Paul Jungwirth wrote:
On 11/13/24 02:11, Peter Eisentraut wrote:
I have committed the documentation patches
v43-0001-Add-WITHOUT-OVERLAPS-and-PERIOD-to-ALTER-TABLE-r.patch
v43-0002-Update-conexclop-docs-for-WITHOUT-OVERLAPS.patch
Thanks!
For the logical replication fixes
Re: To Thomas Munro
> It is (was?) weird. The PG13 build for bullseye on apt.pg.o worked
> normally, but when I built for bullseye-security (Debian LTS), I had
> to remove the patch that removed the 039_end_of_wal.pl file because
> you had changed the file. The build then failed and I put the
> rem
On Thu, 21 Nov 2024 at 06:43, Antonin Houska wrote:
> When doing some unrelated work I noticed that in the new test
> 010_keep_recycled_wals.pl the server fails to reload the configuration
> file. The line it complains about is
>
> archive_command = '/usr/bin/perl -e 'exit(1)''
>
> The test still
I ran `make headerscheck` after these patches and it reported a few
problems:
/pgsql/source/master/src/tools/pginclude/headerscheck /pgsql/source/master
/pgsql/build/master
In file included from /tmp/headerscheck.xdG40Y/test.c:2:
/pgsql/source/master/src/include/commands/copyapi.h:76:44: error: u
On Wed, Nov 20, 2024 at 1:29 PM vignesh C wrote:
>
> On Tue, 19 Nov 2024 at 12:43, Nisha Moond wrote:
> >
> > Attached is the v49 patch set:
> > - Fixed the bug reported in [1].
> > - Addressed comments in [2] and [3].
> >
> > I've split the patch into two, implementing the suggested idea in
> >
We tried it on another server with similar configurations.
Just installed the Postgres 15 and its PgAdmin.
Kept the server ONN for the whole day, the server was okay.
But then we tried the pgAdmin workaround by deleting the pgAdmin.bak file
in 'AppData/Roaming/pgAdmin' and restarted the PgAdmin.
S
Offending O(n²) query:
```sql
SELECT id FROM indexed_table WHERE indexed_value = ANY (ARRAY[1,2,...])
```
I'm not posting this on the `pgsql-performance` mailing list because this is
about fixing the issue, not working around it.
I'm not posting this on the `pgsql-bugs` mailing list because docu
On Thu, 21 Nov 2024 at 15:26, vignesh C wrote:
>
> On Tue, 19 Nov 2024 at 19:12, Shlok Kyal wrote:
> >
> > On Tue, 19 Nov 2024 at 14:39, Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Tuesday, November 19, 2024 3:15 PM Shlok Kyal
> > > wrote:
> > >
> > > >
> > > > I noticed that we can add 'pu
On Tue, 19 Nov 2024 at 19:12, Shlok Kyal wrote:
>
> On Tue, 19 Nov 2024 at 14:39, Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Tuesday, November 19, 2024 3:15 PM Shlok Kyal
> > wrote:
> >
> > >
> > > I noticed that we can add 'publish_generated_columns = true' for the case
> > > of
> > > generated
Re: Thomas Munro
> Also why only this branch, when they all have it? Reproducible or
> one-off? Do you have any more clues?
It is (was?) weird. The PG13 build for bullseye on apt.pg.o worked
normally, but when I built for bullseye-security (Debian LTS), I had
to remove the patch that removed the
On 20.11.2024 01:07, Michael Paquier wrote:
On Tue, Nov 19, 2024 at 09:39:21AM -0500, Greg Sabino Mullane wrote:
Oh, and a +1 in general to the patch, OP, although it would also be nice to
start finding the bottlenecks that cause such performance issues.
FWIW, I'm not eager to integrate this p
Hi,
On Thu, Nov 21, 2024 at 10:01:07AM +0900, Michael Paquier wrote:
> On Wed, Nov 20, 2024 at 05:13:18PM +, Bertrand Drouvot wrote:
> > I don't have a strong opinion for this particular case here (I think the
> > code
> > is harder to read but yeah there is some code reduction): so I'm fine
Hi,
On Thu, Nov 21, 2024 at 04:26:47PM +0900, Michael Paquier wrote:
> On Thu, Nov 21, 2024 at 06:32:03AM +, Bertrand Drouvot wrote:
> > That was in fact the main reason why I added this test. But well, just
> > adding the "write_to_file" in the injection test is enough to "show" that
> > th
Hi,
On Thu, Nov 21, 2024 at 10:38:28AM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> On Thu, 21 Nov 2024 at 09:32, Bertrand Drouvot
> wrote:
> > That was in fact the main reason why I added this test. But well, just
> > adding the "write_to_file" in the injection test is enough to "show" that
> > t
On 2024-11-21 04:40, Peter Geoghegan wrote:
On Wed, Nov 20, 2024 at 4:04 AM Masahiro Ikeda
wrote:
Thanks for your quick response!
Attached is v16. This is similar to v15, but the new
v16-0003-Fix-regressions* patch to fix the regressions is much less
buggy, and easier to understand.
Unlike v
On 20.11.24 10:00, Thomas Munro wrote:
On Fri, Nov 15, 2024 at 1:53 AM Peter Eisentraut wrote:
On 14.11.24 08:48, Thomas Munro wrote:
The three MinGW environments we test today are using ucrt, and
configure detects the symbol on all. Namely: fairwren
(msys2/mingw64), the CI mingw64 task and t
On Wed, Nov 20, 2024 at 10:41:50AM +, by Yang wrote:
> I apologize for the obvious error in the previous patch. I have corrected it
> in the new patch(v3) and pass the regression testing.
It took me quite a bit of time to evaluate the amount of the damage,
and indeed sysbench has been quite go
On 19.11.24 14:29, Dmitry Dolgov wrote:
I see that memfd_create() has a MFD_HUGETLB flag. It's not very clear how
that interacts with the MAP_HUGETLB flag for mmap(). Do you need to specify
both of them if you want huge pages?
Correct, both (one flag in memfd_create and one for mmap) are neede
93 matches
Mail list logo
