Here is a new function which could produce an array of numbers with a
controllable array length and duplicated elements in these arrays. I
used it when working with gin index, and I think it would be helpful for
others as well, so here it is.
select * from normal_rand_array(5, 10, 1.8::numeric, 3
On Sat, Jun 8, 2024 at 4:12 AM Tom Lane wrote:
>
> jian he writes:
> >> * in TryReuseForeignKey, we can pass the information that our primary
> >> key old collation is nondeterministic
> >> and old collation != new collation to the foreign key constraint.
>
> I have a basic question about this: w
Hello Bertrand and Michael,
23.01.2024 11:07, Bertrand Drouvot wrote:
On Tue, Jan 23, 2024 at 02:50:06PM +0900, Michael Paquier wrote:
Anyway, that's not the end of it. What should we do for snapshot
snapshot records coming from the bgwriter?
What about?
3) depending on how stabilized this
On Sat, Jun 8, 2024 at 12:47 AM Robert Haas wrote:
>
> On Fri, Jun 7, 2024 at 4:05 AM Alvaro Herrera wrote:
> > > static void
> > > -ZeroBuffer(Buffer buffer, ReadBufferMode mode)
> > > +ZeroBuffer(Buffer buffer, ReadBufferMode mode, bool zero)
> >
> > This change makes the API very strange. Sh
On Fri, Jun 07, 2024 at 08:30:06AM -0700, Andres Freund wrote:
> Yes, makes sense. Looks we changed direction during development a bunch of
> times...q
Thanks for looking, Andres! I guess I'll just apply that once v18
opens up.
--
Michael
signature.asc
Description: PGP signature
jian he writes:
>> * in TryReuseForeignKey, we can pass the information that our primary
>> key old collation is nondeterministic
>> and old collation != new collation to the foreign key constraint.
I have a basic question about this: why are we allowing FKs to be
based on nondeterministic collat
On Thu, Jun 6, 2024 at 3:27 PM Jelte Fennema-Nio wrote:
> Of course there's always the possibility to review more. But I don't
> really agree with this summary of my review activity.
Nonetheless, I need to take a break from this to work on some of my
own stuff. I'll circle back around to it.
--
Hello all.
I am interested in the proposed patch and would like to propose some
additional changes that would complement it. My changes would introduce
similar optimizations when working with a list of integers or object
identifiers. Additionally, my patch includes an extension for benchmarking,
w
On Fri, Jun 7, 2024 at 7:59 PM Andres Freund wrote:
> Hi,
>
> On 2024-06-06 15:25:25 +0300, Radu Radutiu wrote:
> > I have a query that forces an out of memory error, where the OS will kill
> > the postgresql process.
>
> FWIW, it can be useful to configure the OS with strict memory overcommit.
>
On Wed, Jun 5, 2024 at 3:05 PM Nathan Bossart
wrote:
> For pg_lfind32(), we ended up using an overlapping approach for the
> vectorized case (see commit 7644a73). That appeared to help more than it
> harmed in the many (admittedly branch predictor friendly) tests I ran. I
> wonder if you could
Hi,
After looking into parallel builds for BRIN and GIN indexes, I was
wondering if there's a way to do parallel builds for GiST too. I knew
next to nothing about how GiST works, but I gave it a shot and here's
what I have - the attached patch allows parallel GiST builds for the
"unsorted" case (i
On Fri, Jun 7, 2024 at 3:02 AM Erica Zhang wrote:
>
> For some security consideration, we prefer to use TLS1.3 cipher suites in our
> product with some customization values instead of default value
> "HIGH:MEDIUM:+3DES:!aNULL". Moreover we prefer to set a group of ecdh keys
> instead of a singl
Hi,
On 2024-06-06 13:58:24 +0100, Pantelis Theodosiou wrote:
> I am not qualified to answer on the OOM issue but why are you joining the
> same table (outputrequest) 4 times (using an identical join condition)?
The conditions aren't actually the same
rpl_rec_tro. input_sequence = r.input
Hi,
On 2024-06-06 15:25:25 +0300, Radu Radutiu wrote:
> I have a query that forces an out of memory error, where the OS will kill
> the postgresql process.
FWIW, it can be useful to configure the OS with strict memory overcommit. That
causes postgres to fail more gracefully, because the OOM kille
Hi,
On 2024-06-07 11:19:40 -0400, Tom Lane wrote:
> Xiaoran Wang writes:
> > I found that in enum XactEvent, there is 'XACT_EVENT_PREPARE' for
> > 'prepare transaction', but there is no event for 'commit prepared' or
> > 'rollback prepared'.
>
> On the whole, it seems like a good idea to me th
Hi Team, We are pursuing to trim the changes wrt AIX. As of now we trimmed
the changes with respect to XLC and currently with trimmed changes the
buildfarm script passed (build and all the regression tests)
The XLC changes were trimmed only in the below file
modified: configure
modified: co
Hi,
On 2024-06-07 14:07:33 +0900, Michael Paquier wrote:
> While hacking on the area of pgstat_*.c, I have noticed the existence
> of named_on_disk in PgStat_KindInfo, that is here to track the fact
> that replication slots are a particular case in the PgStat_HashKey for
> the dshash table of the
Xiaoran Wang writes:
> I found that in enum XactEvent, there is 'XACT_EVENT_PREPARE' for
> 'prepare transaction', but there is no event for 'commit prepared' or
> 'rollback prepared'.
On the whole, it seems like a good idea to me that those commands
don't invoke event triggers. It is a core pr
>
>
>
>> The planner should recognize this situation and avoid use of hash
>> join in such cases, but maybe the statistics aren't reflecting the
>> problem, or maybe there's something wrong with the logic specific
>> to parallel hash join. You've not really provided enough information
>> to diagno
Andrew Dunstan writes:
> On 2024-06-06 Th 18:02, Jelte Fennema-Nio wrote:
>> For the PgBouncer test suite we do something similar as the PG its
>> perl tests do, but there we allocate a port between 10200 and 32768:
>> https://github.com/pgbouncer/pgbouncer/blob/master/test/utils.py#L192-L215
> M
On Jun 7, 2024, at 10:23, David E. Wheeler wrote:
> Rebased and moved the new tests to the end of the file.
Bah, sorry, that was the previous patch. Here’s v3.
D
v3-0001-Add-tests-for-jsonpath-.-on-arrays.patch
Description: Binary data
On Jun 4, 2024, at 20:45, David E. Wheeler wrote:
> Oh FFS, unwrapping still breaks my brain. You’re right, of course. Here’s a
> new patch that demonstrates that behavior, since that code path is not
> currently represented in tests AFAICT (I would have expected to have broken
> it with this
To be accurate, "multi-key sort" includes both "multi-key quick sort"
and "multi-key heap sort". This patch includes code change related to
only "multi-key quick sort" which is used to replace standard quick
sort for tuplesort. The "multi-key heap sort" is about an implementation
of multi-key heap
On 2024-06-06 Th 18:02, Jelte Fennema-Nio wrote:
On Wed, 5 Jun 2024 at 23:37, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-06-05 We 16:00, Alexander Lakhin wrote:
That is, psql from the test instance 001_ssltests_34 opened a
connection to
the test server with the client port 50072 and it
On Thu, Jun 6, 2024 at 11:17 PM Andres Freund wrote:
> If we just want to keep prior stats upon arelation rewrite, we can just copy
> the stats from the old relfilenode. Or we can decide that those stats don't
> really make sense anymore, and start from scratch.
I think we need to think carefull
Le ven. 7 juin 2024 à 05:59, Tomas Vondra
a écrit :
>
> On 6/6/24 12:58, Julien Tachoires wrote:
> > ...
> >
> > When compiled with LZ4 support (--with-lz4), this patch enables data
> > compression/decompression of these temporary files. Each transaction
> > change that must be written on disk (Re
On Thu, Jun 6, 2024 at 7:20 PM Michael Paquier wrote:
> On Thu, Jun 06, 2024 at 09:48:51AM -0400, Robert Haas wrote:
> > It's not this patch set's fault, but I'm not very pleased to see that
> > the injection point wait events have been shoehorned into the
> > "Extension" category - which they are
On 6/6/24 12:58, Julien Tachoires wrote:
> ...
>
> When compiled with LZ4 support (--with-lz4), this patch enables data
> compression/decompression of these temporary files. Each transaction
> change that must be written on disk (ReorderBufferDiskChange) is now
> compressed and encapsulated in a ne
On 6/6/24 16:24, Alvaro Herrera wrote:
> On 2024-Jun-06, Amit Kapila wrote:
>
>> On Thu, Jun 6, 2024 at 4:28 PM Julien Tachoires wrote:
>>>
>>> When the content of a large transaction (size exceeding
>>> logical_decoding_work_mem) and its sub-transactions has to be
>>> reordered during logical de
On 6/3/24 09:30, Amit Kapila wrote:
> On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
> wrote:
>>
>> On 5/23/24 08:36, shveta malik wrote:
>>>
>>> Conflict Resolution
>>>
>>> a) latest_timestamp_wins:The change with later commit timestamp wins.
>>> b) earliest_timestamp_wins:
On Fri, Jun 7, 2024 at 4:05 AM Alvaro Herrera wrote:
> > static void
> > -ZeroBuffer(Buffer buffer, ReadBufferMode mode)
> > +ZeroBuffer(Buffer buffer, ReadBufferMode mode, bool zero)
>
> This change makes the API very strange. Should the function be called
> ZeroAndLockBuffer() instead? Then t
On Thu, Jun 6, 2024 at 10:04 PM Tom Lane wrote:
> > I added them here with minimal copy editing an no attempt to organize or
> > sort into groups:
> > https://wiki.postgresql.org/wiki/Committing_checklist#Policies
> > If someone has thoughts on how to improve I am happy to make more changes.
>
> T
On 5/28/24 11:17, Nisha Moond wrote:
> On Mon, May 27, 2024 at 11:19 AM shveta malik wrote:
>>
>> On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
>> wrote:
>>>
>>> ...
>>>
>>> I don't understand the why should update_missing or update_deleted be
>>> different, especially considering it's not detecte
On 5/27/24 07:48, shveta malik wrote:
> On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
> wrote:
>>
>> On 5/23/24 08:36, shveta malik wrote:
>>> Hello hackers,
>>>
>>> Please find the proposal for Conflict Detection and Resolution (CDR)
>>> for Logical replication.
>>> >> below details.>
>>>
>>> Intr
On Thu, Jun 6, 2024 at 5:10 PM Pavel Luzanov wrote:
> Agree.
> There is an additional technical argument for removing this replacement.
> I don't like explicit cast to text of the "Connection limit" column.
> Without 'Not allowed' it is no longer required.
> Value -1 can be replaced by NULL with a
On Thu, Jun 6, 2024 at 5:16 PM Nisha Moond wrote:
> >
>
> Here are more use cases of the "earliest_timestamp_wins" resolution method:
> 1) Applications where the record of first occurrence of an event is
> important. For example, sensor based applications like earthquake
> detection systems, capt
On Fri, Jun 07, 2024 at 06:02:37PM +0800, Erica Zhang wrote:
> I see the https://commitfest.postgresql.org/48/ is still open, could
> it be possible to target for PG17? As I know PG17 is going to be
> release this year so that we can upgrade our instances to this new
> version accodingly.
Echoing
On Fri, Jun 7, 2024 at 7:55 AM Masahiko Sawada wrote:
>
> On Thu, Jun 6, 2024 at 6:40 PM Amit Kapila wrote:
> >
> > On Thu, Jun 6, 2024 at 11:10 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jun 5, 2024 at 9:30 PM Amit Kapila
> > > wrote:
> > > >
> > >
> > > > To achieve this, we can allo
On Tue, 19 Mar 2024 at 11:53, Daniel Gustafsson wrote:
>
> I did notice a few mistakes in the --filter
> documentation portion for other keywords but that's unrelated to this patch,
> will fix them once this is in to avoid conflicts.
>
Attached is a patch for the --filter docs, covering the omiss
Hi Peter,
Thanks a lot for the quick response. We are using Postgres instance in our
product. For some security consideration, we prefer to use TLS1.3 cipher suites
in our product with some customization values instead of default value
"HIGH:MEDIUM:+3DES:!aNULL". Moreover we prefer to set a grou
On Mon, Feb 5, 2024 at 11:18 AM Richard Guo wrote:
> cfbot reminds that this patch does not apply any more. So I've rebased
> it on master, and also adjusted the test cases a bit.
This patch does not apply any more, so here is a new rebase, with some
tweaks to the comments.
Thanks
Richard
v3-
On Fri, Jun 7, 2024 at 2:08 PM Dilip Kumar wrote:
>
> I think the compression option should be supported at the CREATE
> SUBSCRIPTION level instead of being controlled by a GUC. This way, we
> can decide on compression for each subscription individually rather
> than applying it to all subscribers
On Thu, Jun 6, 2024 at 7:54 PM Alvaro Herrera wrote:
>
> On 2024-Jun-06, Amit Kapila wrote:
>
> > On Thu, Jun 6, 2024 at 4:28 PM Julien Tachoires wrote:
> > >
> > > When the content of a large transaction (size exceeding
> > > logical_decoding_work_mem) and its sub-transactions has to be
> > > re
Hi,
On Thu, Jun 06, 2024 at 08:17:36PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-06-06 12:27:49 -0400, Robert Haas wrote:
> > On Wed, Jun 5, 2024 at 1:52 AM Bertrand Drouvot
> > wrote:
> > > I think we should keep the stats in the relation during relfilenode
> > > changes.
> > > As a POC, v
Dear Euler,
Thanks for making the follow-up patch! I was looking forward to your updates.
I think this patch set is the solution for the found buildfarm error. However,
there are remained claims raised by others. You should reply what you think for
them. At least:
1) There are some misleading mes
On Fri, Jun 7, 2024 at 2:40 PM Matthias van de Meent
wrote:
>
> On Fri, 7 Jun 2024 at 10:28, Dilip Kumar wrote:
> >
> > On Fri, Jun 7, 2024 at 11:57 AM Matthias van de Meent
> > wrote:
> >>
> >> On Fri, 7 Jun 2024 at 07:18, Dilip Kumar wrote:
> >>>
> >>> On Wed, Jun 5, 2024 at 10:59 PM Matthias
On Fri, Jun 7, 2024 at 2:39 PM Alvaro Herrera wrote:
>
> On 2024-Jun-07, Dilip Kumar wrote:
>
> > I think the compression option should be supported at the CREATE
> > SUBSCRIPTION level instead of being controlled by a GUC. This way, we
> > can decide on compression for each subscription individua
Hi hackers,
I found that in enum XactEvent, there is 'XACT_EVENT_PREPARE' for
'prepare transaction', but there is no event for 'commit prepared' or
'rollback prepared'.
For the following SQL:
begin;
create table test(a int);
PREPARE TRANSACTION '
On Fri, 7 Jun 2024 at 10:28, Dilip Kumar wrote:
>
> On Fri, Jun 7, 2024 at 11:57 AM Matthias van de Meent
> wrote:
>>
>> On Fri, 7 Jun 2024 at 07:18, Dilip Kumar wrote:
>>>
>>> On Wed, Jun 5, 2024 at 10:59 PM Matthias van de Meent
>>> wrote:
>>>
>>> I agree with you that we introduced the WAL_L
On 2024-Jun-07, Dilip Kumar wrote:
> I think the compression option should be supported at the CREATE
> SUBSCRIPTION level instead of being controlled by a GUC. This way, we
> can decide on compression for each subscription individually rather
> than applying it to all subscribers. It makes more s
On Fri, Jun 7, 2024 at 7:57 AM Zhijie Hou (Fujitsu)
wrote:
>
> Thanks for the comments! Here is the V6 patch that addressed the these.
>
I have pushed this after making minor changes in the wording. I have
also changed one of the queries in docs to ignore the NULL slot_name
values.
--
With Rega
Hi,
On Thu, Jun 06, 2024 at 08:38:06PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-06-03 11:11:46 +, Bertrand Drouvot wrote:
> > The main argument is that we currently don’t have writes counters for
> > relations.
> > The reason is that we don’t have the relation OID when writing buffers o
Hello Thomas,
07.06.2024 09:06, Thomas Munro wrote:
On Fri, Jun 7, 2024 at 3:06 PM Thomas Munro wrote:
On Fri, Jun 7, 2024 at 3:00 PM Alexander Lakhin wrote:
My bisect run ended with:
210622c60e1a9db2e2730140b8106ab57d259d15 is the first bad commit
Author: Thomas Munro
Date: Wed Apr 3 00
On 07.06.24 08:10, Erica Zhang wrote:
I’m a Postgres user and I’m looking into restricting the set of allowed
ciphers on Postgres and configure a concrete set of curves on our
postgres instances.
Out of curiosity, why is this needed in practice?
Could you please help to review to see if you a
Hi,
On Thu, Jun 06, 2024 at 04:00:23PM -0400, Robert Haas wrote:
> On Thu, Jun 6, 2024 at 1:56 AM Bertrand Drouvot
> wrote:
> > v9 is more invasive (as it changes code in much more places) than v8 but it
> > is
> > easier to follow (as it is now clear where the new lock is acquired).
>
> Hmm, t
On Thu, Jun 6, 2024 at 7:54 PM Alvaro Herrera wrote:
>
> On 2024-Jun-06, Amit Kapila wrote:
>
> > On Thu, Jun 6, 2024 at 4:28 PM Julien Tachoires wrote:
> > >
> > > When the content of a large transaction (size exceeding
> > > logical_decoding_work_mem) and its sub-transactions has to be
> > > re
On Fri, Jun 7, 2024 at 4:28 PM Alvaro Herrera wrote:
>
> On 2024-Jun-07, jian he wrote:
>
> > so when it actually happens, it cannot quickly locate which function
> > where the error has happened.
> > maybe under certain conditions (e.g. certain build type or certain
> > log_min_messages),
> > we
# I'm sorry for my late response.
I confirmed that the error of regression is caused by my code inserting
setlocale() into ecpglib of local branch.
No other tests occur error in non-C locale.
The following is about other topics.
1. About regression test
We should test the followings:
- PGTYPE
On 2024-Jun-07, jian he wrote:
> so when it actually happens, it cannot quickly locate which function
> where the error has happened.
> maybe under certain conditions (e.g. certain build type or certain
> log_min_messages),
> we can also print out the function name by using gcc __func__.
That inf
On Fri, Jun 7, 2024 at 11:57 AM Matthias van de Meent
wrote:
>
> On Fri, 7 Jun 2024 at 07:18, Dilip Kumar wrote:
> >
> > On Wed, Jun 5, 2024 at 10:59 PM Matthias van de Meent
> > wrote:
> >>
> >> On Wed, 5 Jun 2024 at 18:47, Ranier Vilela wrote:
> >>>
> >>> Why not use it too, if not binary_upg
hi.
we have 450 appearance of
`cache lookup failed .*`
we have 141 appearance of
`could not open file .*`
so when it actually happens, it cannot quickly locate which function
where the error has happened.
maybe under certain conditions (e.g. certain build type or certain
log_min_messages),
we ca
On 2024-Jun-07, Thomas Munro wrote:
> static void
> -ZeroBuffer(Buffer buffer, ReadBufferMode mode)
> +ZeroBuffer(Buffer buffer, ReadBufferMode mode, bool zero)
This change makes the API very strange. Should the function be called
ZeroAndLockBuffer() instead? Then the addition of a "bool zero"
On 29.05.24 08:47, Sutou Kouhei wrote:
In <4707d4ed-f268-43c0-b4dd-cdbc7520f...@eisentraut.org>
"Re: meson: Specify -Wformat as a common warning flag for extensions" on
Tue, 28 May 2024 23:31:05 -0700,
Peter Eisentraut wrote:
On 07.04.24 18:01, Sutou Kouhei wrote:
+# We don't have "war
63 matches
Mail list logo
