Andrew Dunstan writes:
> On 2024-06-08 Sa 06:22, Imran Zaheer wrote:
>> Now this can either be solved by just just undefine the macro defined
>> by wincrypt.h as done here [3]
>> Or we should rearrange our headers. Openssl header should be at the
>> bottom (after the gssapi includes).
> Let's be
On Fri, Jun 7, 2024 at 8:05 PM Alvaro Herrera wrote:
> In passing, I noticed that WaitReadBuffers has zero comments, which
> seems an insufficient number of them.
Ack. Here is a patch for that. I guess I hadn't put a comment there
because it's hard to write anything without sort of duplicating
New version. Same code as v2, but comments improved to explain the
reasoning, with reference to README's buffer access rules. I'm
planning to push this soon if there are no objections.
From 1fa26f407622cd69d82f3b4ea68fddf2c357cf06 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Fri, 7 Jun
the table.
> Here is a patch that fixes this problem by keeping track of the
current role in the AfterTriggerSharedData.
I skimmed the code and haven't looked at in depth. Whichever direction
we go, I think it's worth updating the documentation to make the
behavior around triggers and roles clea
On 2024-06-08 Sa 06:22, Imran Zaheer wrote:
I was able to reproduce the gssapi & openssl error on windows. I tried
on PG16 with msvc build system and on PG17 with meson build system.
The error was reproducible when enabling both openssl and gssapi from
the configurations. Turns out that it was
On 2024-06-08 Sa 10:00, Alexander Lakhin wrote:
Hello,
30.05.2024 18:00, Alexander Lakhin wrote:
While reviewing recent buildfarm failures, I came across this one:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake=2024-05-23%2004%3A11%3A03
Michael Paquier writes:
> On Fri, Jun 07, 2024 at 11:32:14AM +0800, jian he wrote:
>> in deleteObjectsInList, under certain conditions trying to sort the to
>> be deleted object list
>> by just using sort_object_addresses seems to work,
>> but it looks like a hack.
>> maybe the proper fix would
> Attached is a patch for the --filter docs, covering the omissions I can
see.
Thanks Dean for working on this.
I have reviewed the changes and they look good to me.
Regards,
Ayush Vatsa
Amazon Web services (AWS)
On Fri, 7 Jun 2024 at 15:50, Dean Rasheed wrote:
> On Tue, 19 Mar 2024 at 11:53,
On Sat, Jun 8, 2024 at 10:02 AM Pavel Luzanov wrote:
> Therefore, I think the current patch offers a better version of the \du
> command.
> However, I admit that these improvements are not enough to accept the patch.
> I would like to hear other opinions.
Hmm, I don't think I quite agree with
On 07.06.2024 15:35, Robert Haas wrote:
This seems unobjectionable to me. I am not sure whether it is better
than the current verison, or whether it is what we want. But it seems
reasonable.
I consider this patch as a continuation of the work on \drg command,
when it was decided to remove the
Hello,
30.05.2024 18:00, Alexander Lakhin wrote:
While reviewing recent buildfarm failures, I came across this one:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake=2024-05-23%2004%3A11%3A03
upgrade.crake/REL_16_STABLE/REL9_5_STABLE-ctl4.log
waiting for server to shut
Hi Bharath,
I spent some time examining the patch. Here are my observations from the review.
- I believe there’s no need for an extra variable ‘nbytes’ in this
context. We can repurpose the ‘count’ variable for the same function.
If necessary, we might think about renaming ‘count’ to ‘nbytes’.
> On 7 Jun 2024, at 04:38, Michael Paquier wrote:
Thanks Michael! Tests of injection points with injection points are neat :)
Alvaro, here’s the test for multixact CV sleep that I was talking about on
PGConf.
It is needed to test [0]. It is based on loaded injection points. This
technique
I was able to reproduce the gssapi & openssl error on windows. I tried
on PG16 with msvc build system and on PG17 with meson build system.
The error was reproducible when enabling both openssl and gssapi from
the configurations. Turns out that it was due to the conflicting
macros.
On Fri, Jun 7, 2024 at 5:39 PM Ashutosh Bapat
wrote:
>
> 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,
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:
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.
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
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,
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
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
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 =
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
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
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:
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
>
>
>
>> 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
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
>
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
t; > Results:
> >
> > MKsort:
> > 12374.427 ms
> > 12528.068 ms
> > 12554.718 ms
> >
> > qsort:
> > 12251.422 ms
> > 12279.938 ms
> > 12280.254 ms
> >
> > MKsort is a bit slower than qsort, which can be explained by extra
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
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
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
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
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
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
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
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.
>
>
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
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.>
>>>
>>>
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
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,
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
rote:
> > > >
> > >
> > > > To achieve this, we can allow sequences to be copied during
> > > > the initial CREATE SUBSCRIPTION command similar to what we do for
> > > > tables. And then later by new/existing command, we re-copy the
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
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
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
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
> > >
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,
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
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
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
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
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
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
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
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
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
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,
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
> > >
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:
-
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
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
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
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:
On Thu, May 30, 2024 at 11:57 PM Alena Rybakina
wrote:
>
> On 30.05.2024 10:33, Alena Rybakina wrote:
> >
> > I suggest gathering information about vacuum resource consumption for
> > processing indexes and tables and storing it in the table and index
> > relationships (for example,
On Fri, Jun 7, 2024 at 11:53 AM Ashutosh Sharma wrote:
>
> On Fri, Jun 7, 2024 at 10:06 AM Dilip Kumar wrote:
> >
> > On Thu, Jun 6, 2024 at 7:39 PM Ashutosh Sharma
> > wrote:
> > >
> > > On Thu, Jun 6, 2024 at 6:20 PM Dilip Kumar wrote:
> > >>
> > >> On Thu, Jun 6, 2024 at 5:59 PM Ashutosh
oll(RelationGetRelid(tab->rel), attnum,
+ , , _collid);
+ /*
+ * All deterministic collations use bitwise equality to resolve
+ * PK-FK ties. But if the primary key (source) collation was indeterministic,
+ * and ALTER COLUMN .. SET DATA TYPE changes the primary key collation, then
+
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_upgrade?
>>
>> Because in the normal case (not during binary_upgrade) you don't
On Fri, Jun 7, 2024 at 10:06 AM Dilip Kumar wrote:
>
> On Thu, Jun 6, 2024 at 7:39 PM Ashutosh Sharma wrote:
> >
> > On Thu, Jun 6, 2024 at 6:20 PM Dilip Kumar wrote:
> >>
> >> On Thu, Jun 6, 2024 at 5:59 PM Ashutosh Sharma
> >> wrote:
> >> >
> >> > Hello everyone,
> >> >
> >> > At present,
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:03:08 2024 +1300
> >
> >
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:
> >
> > Em ter., 4 de jun. de 2024 às 16:39, Nathan Bossart
> > escreveu:
> >>
> >> I noticed that the "Restoring database schemas in the new cluster" part of
> >> pg_upgrade can
On Fri, Jun 07, 2024 at 11:32:14AM +0800, jian he wrote:
> in deleteObjectsInList, under certain conditions trying to sort the to
> be deleted object list
> by just using sort_object_addresses seems to work,
> but it looks like a hack.
> maybe the proper fix would be in findDependentObjects.
@@
On Thu, Jun 6, 2024 at 7:39 PM Ashutosh Sharma wrote:
>
> On Thu, Jun 6, 2024 at 6:20 PM Dilip Kumar wrote:
>>
>> On Thu, Jun 6, 2024 at 5:59 PM Ashutosh Sharma wrote:
>> >
>> > Hello everyone,
>> >
>> > At present, we use MVCC snapshots to identify dependent objects. This
>> > implies that if
On Wed, May 22, 2024, at 12:16 PM, Euler Taveira wrote:
> I'll summarize all issues as soon as I finish the review of sync slot
> support. I
> think we should avoid new development if we judge that the item can be
> documented as a limitation for this version. Nevertheless, I will share
>
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 out.
> Tracking writes per relfilenode would allow us to track/consolidate
On Mon, Jun 3, 2024 at 12:14 PM jian he wrote:
>
> hi.
>
> setup
> drop table if exist test__int cascade;
> create extension intarray;
>
> CREATE TABLE test__int( a int[] );
> CREATE INDEX text_idx on test__int using gist (a gist__intbig_ops(siglen =
> 1));
> drop extension intarray
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, v1 implemented a way to do so during TRUNCATE (see the changes in
> >
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:03:08 2024 +1300
>
> Provide vectored variant of ReadBuffer().
>
> Other buildfarm failures
Hello Noah,
06.06.2024 22:07, Noah Misch wrote:
I don't know, but if the locks are really missing now, I feel like the
first question is "which commit got rid of them?". It's a little hard
to believe that they've never been there and somehow nobody has
noticed.
Then again, maybe we have; see
On Thursday, June 6, 2024 12:21 PM Peter Smith
>
> Hi, here are some review comments for the docs patch v5-0001.
Thanks for the comments! Here is the V6 patch that addressed the these.
Best Regards,
Hou zj
v6-0001-Document-the-steps-to-check-if-the-standby-is-rea.patch
Description:
; > > the initial CREATE SUBSCRIPTION command similar to what we do for
> > > tables. And then later by new/existing command, we re-copy the already
> > > existing sequences on the subscriber.
> > >
> > > The options for the new command could be:
> >
Joe Conway writes:
> On 6/6/24 14:12, Tom Lane wrote:
>> To get a sense of how much of a problem we have, I grepped the git
>> history for comments mentioning project policies. Ignoring ones
>> that are really talking about very localized issues, what I found
>> is attached. It seems like it's
On Wed, Jun 5, 2024 at 7:19 PM Andrey M. Borodin wrote:
>
>
>
> > On 4 Jun 2024, at 00:26, Masahiko Sawada wrote:
>
> Thank you! Vacuum enhancement is a really good step forward, and this small
> change would help a lot of observability tools.
>
>
> > On 4 Jun 2024, at 00:49, Peter Geoghegan
On Thu, 2024-06-06 at 16:34 +0200, Peter Eisentraut wrote:
> - setlocale()
>
> The locale business needs to be reworked to use locale_t and _l
> functions. This is already being discussed for other reasons.
I posted a few patches to do this for collation:
On Thu, Jun 06, 2024 at 03:47:47PM +0500, Andrey M. Borodin wrote:
> Is it OK to detach() before wakeup()? Or, perhaps, can a detach() do a
> wakeup() automatically?
It is OK to do a detach before a wakeup. Noah has been relying on
this behavior in an isolation test for a patch he's worked on.
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 not - instead of being a new
> wait_event_type. That would
On Fri, 2024-06-07 at 00:19 +0200, Jelte Fennema-Nio wrote:
> Even by default making the search_path "pg_catalog, pg_temp" for
> functions created by extensions would be very useful.
Right now there's no syntax to override that. We'd need something to
say "get the search_path from the session".
On Thu, 6 Jun 2024 at 20:10, Isaac Morland wrote:
>
> On Thu, 6 Jun 2024 at 12:53, Jeff Davis wrote:
>
>>
>> > I didn't get you completely here. w.r.t extensions how will this have
>> > an impact if we set the search_path for definer functions.
>>
>> If we only set the search path for SECURITY
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 made using the port by
> >> the
On 06.06.2024 17:29, Robert Haas wrote:
I think the first of these special interpretations is unnecessary and
should be removed. It seems pretty clear what 0 means.
Agree.
There is an additional technical argument for removing this replacement.
I don't like explicit cast to text of the
Radu Radutiu writes:
> The query itself runs fine in a reasonable time with enable_parallel_hash =
> 'off'. I see two problems - one is the wrong execution plan (right after
> running analyze), the second and the most important is the huge memory
> usage (far exceeding work_mem and shared
1 - 100 of 157635 matches
Mail list logo
