On Thu, Apr 25, 2024 at 7:25 PM Ashutosh Bapat
wrote:
> Quickly looking at the function, the patch would make it more apparent
> that the function is a noop when mergeclause_list is empty.
>
Thanks for looking at this patch. Yes, that's what it does.
> I haven't looked closely to see if creat
> On Tue, Apr 23, 2024 at 8:13 PM Tatsuo Ishii wrote:
>> SELECT v.a, count(*) OVER w
>> FROM (VALUES ('A'),('B'),('B'),('C')) AS v (a)
>> WINDOW w AS (
>> ORDER BY v.a
>> ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
>> PATTERN (B+)
>> DEFINE B AS a = 'B'
>> )
>> a | count
>> ---+-
Added a CF entry for the same - https://commitfest.postgresql.org/48/4955/
Regards
Ayush Vatsa
Amazon Web Services (AWS)
On Fri, 26 Apr 2024 at 11:05, Ayush Vatsa wrote:
> Hi PostgreSQL Community,
> Recently I have been working on foreign servers regarding my project and
> wanted to add some ex
Hi PostgreSQL Community,
Recently I have been working on foreign servers regarding my project and
wanted to add some extensions in server options to support query pushdown.
For this, suppose I had 20 extensions in the beginning I used ALTER SERVER
srv OPTIONS (ADD EXTENSIONS 'all 20 extensions'), t
On Thu, Apr 25, 2024 at 11:55 PM •Isaac Rv wrote:
> Entiendo si, me han dicho que es sencillo, pero no entiendo si solo
> descargo los binarios y en cual carpeta reemplazo? no hay una guía cómo tal
> de cómo realizarlo, me podrías ayudar?
>
Follow the below steps
1. Backup your data
2. Review t
On Thu, Apr 18, 2024 at 9:33 AM Amit Langote wrote:
> On Mon, Apr 15, 2024 at 9:46 PM Amit Langote wrote:
> > On Sat, Apr 13, 2024 at 11:12 PM jian he
> > wrote:
> > > On Fri, Apr 12, 2024 at 5:44 PM Amit Langote
> > > wrote:
> > > >
> > > > > elog(ERROR, "unrecognized json wrapper %d", wrapp
Hi, just by visual inspection of the v3/v4 patch diffs, the latest v4 LGTM.
==
Kind Regards,
Peter Smith.
Fujitsu Australia
On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> I believe that the underlying problem here can be summarized in this
> way: just because I'm OK with 2MB of bloat in my 10MB table doesn't
> mean that I'm OK with 2TB of bloat in my 10TB table. One reason for
> this is simply that I can afford
Anton Voloshin writes:
> On 18/04/2023 20:34, Tom Lane wrote (on pgsql-committers):
>>> I shall now retire to a safe distance and watch the buildfarm.
> Unfortunately, on fresh perl (5.38.2 verified) and on ru_RU.UTF-8
> locale, it breaks basic float comparison: 0 < 0.5 is no longer true.
Haven
Chris Cleveland writes:
> Can anyone tell me why my index access method isn't seeing an order_by
> ScanKey when there is a query with an ORDER BY clause that uses an operator
> that the access method supports?
Hmm, you have
> CREATE OPERATOR pg_catalog.<<=>> (
> FUNCTION = rdb.test_sort_matc
On Thu, Apr 25, 2024 at 4:57 PM Frédéric Yhuel
wrote:
> Now I have just read Robert's new message, and I understand his point.
> But is there a real problem with triggering analyze after every 50
> (or more) modifications in the table anyway?
It depends on the situation, but even on a laptop,
I wrote:
> Hmm, is that actually true? There's no more reason to think a tuple
> in a temp table is old enough to be visible to all other sessions
> than one in any other table. It could be all right if we had a
> special-case rule for setting all-visible in temp tables. Which
> indeed I thought
Can anyone tell me why my index access method isn't seeing an order_by
ScanKey when there is a query with an ORDER BY clause that uses an operator
that the access method supports?
(Apologies for the volume of code below. I just don't know what is
important. This is all in Rust.)
CREATE OPERATOR
Melanie Plageman writes:
> On Wed, Apr 24, 2024 at 4:46 PM Melanie Plageman
> wrote:
>> After thinking about it more, I suppose we can't add a test that
>> relies on the relation being all visible in the VM in a group in the
>> parallel schedule. I'm not sure this edge case is important enough to
On Thu, Apr 25, 2024 at 2:50 PM Heikki Linnakangas wrote:
> > I think that comes down to the debate upthread, and whether you think
> > it's a performance tweak or a security feature. My take on it is,
> > `direct` mode is performance, and `requiredirect` is security.
>
> Agreed, although the the
On Wed, Apr 24, 2024 at 4:46 PM Melanie Plageman
wrote:
>
> On Tue, Apr 23, 2024 at 6:43 PM Tomas Vondra
> wrote:
> >
> > On 4/23/24 18:05, Melanie Plageman wrote:
> > > One other note: there is some concurrency effect in the parallel
> > > schedule group containing "join" where you won't trip th
On Wed, 3 Jan 2024 at 15:10, Robert Haas wrote:
> On Fri, Dec 22, 2023 at 12:00 AM Alexander Lakhin
> wrote:
> > My quick experiment shows that that TimestampDifferenceMilliseconds call
> > always returns zero, due to it's arguments swapped.
>
> Thanks. Tom already changed the unsigned -> int st
I wrote:
> I could get behind offering an alternative notation, eg "a.b->c does
> the same thing as (a.b).c", if we could find a reasonable notation
> that doesn't infringe on user operator namespace. I think that might
> be hard to do though, and I don't think the existing notation is so
> awful
On 25/04/2024 21:13, Jacob Champion wrote:
On Thu, Apr 25, 2024 at 10:35 AM Robert Haas wrote:
Maybe I'm missing something here, but why doesn't sslnegotiation
override sslmode completely? Or alternatively, why not remove
sslnegotiation entirely and just have more sslmode values? I mean
maybe t
On Thu, 25 Apr 2024 at 17:05, Tom Lane wrote:
> > I think it's confusing and counterintuitive that putting parentheses
> > around a subexpression completely changes the meaning. I don't know of
> > any other programming language that behaves that way,
>
> I take it that you also don't believe th
Le 25/04/2024 à 18:51, Melanie Plageman a écrit :
I'm not too sure I understand. What are the reasons it might by skipped?
I can think of a concurrent index creation on the same table, or
anything holding a SHARE UPDATE EXCLUSIVE lock or above. Is this the
sort of thing you are talking about?
Robert Haas writes:
> On Thu, Apr 25, 2024 at 12:34 PM Tom Lane wrote:
>> Uh, no. My point is that if you make a custom output function
>> for "type complex (real float8, imaginary float8)", that function
>> will probably crash pretty hard if what it's handed is something
>> other than two float
Le 25/04/2024 à 21:21, Nathan Bossart a écrit :
On Thu, Apr 25, 2024 at 02:33:05PM -0400, Robert Haas wrote:
What does surprise me is that Frédéric suggests a default value of
500,000. If half a million tuples (proposed default) is 20% of your
table (default value of autovacuum_vacuum_scale_f
On Thu, Apr 25, 2024 at 3:21 PM Nathan Bossart wrote:
> Agreed, the default should probably be on the order of 100-200M minimum.
>
> The original proposal also seems to introduce one parameter that would
> affect all three of autovacuum_vacuum_threshold,
> autovacuum_vacuum_insert_threshold, and a
On Thu, Apr 25, 2024 at 02:33:05PM -0400, Robert Haas wrote:
> What does surprise me is that Frédéric suggests a default value of
> 500,000. If half a million tuples (proposed default) is 20% of your
> table (default value of autovacuum_vacuum_scale_factor) then your
> table has 2.5 million tuples.
On Wed, Apr 24, 2024 at 3:57 PM Nathan Bossart wrote:
> Yeah, I'm having trouble following the proposed mechanics for this new GUC,
> and it's difficult to understand how users would choose a value. If we
> just want to cap the number of tuples required before autovacuum takes
> action, perhaps w
Hello, hackers.
On 18/04/2023 20:34, Tom Lane wrote (on pgsql-committers):
> I shall now retire to a safe distance and watch the buildfarm.
Unfortunately, on fresh perl (5.38.2 verified) and on ru_RU.UTF-8
locale, it breaks basic float comparison: 0 < 0.5 is no longer true.
This is the reprod
On Thu, Apr 25, 2024 at 10:35 AM Robert Haas wrote:
> Maybe I'm missing something here, but why doesn't sslnegotiation
> override sslmode completely? Or alternatively, why not remove
> sslnegotiation entirely and just have more sslmode values? I mean
> maybe this shouldn't happen categorically, bu
> On 25 Apr 2024, at 17:48, Robert Haas wrote:
>
> On Wed, Apr 24, 2024 at 3:20 PM Daniel Gustafsson wrote:
>> Patch LGTM.
>
> Thanks. Here's an updated version with fixes for the other issues you
> mentioned.
LGTM, only one small error in the commitmessage: s/Gustaffson/Gustafsson/
--
Danie
> On 25 Apr 2024, at 18:16, Robert Haas wrote:
>
> On Wed, Apr 24, 2024 at 3:08 PM Daniel Gustafsson wrote:
>> LGTM; only one small comment which you can ignore if you feel it's not worth
>> the extra words.
>>
>> +pg_combinebackup when the checksum status of the
>> +cluster has been ch
On Thu, Apr 25, 2024 at 12:28 PM Jacob Champion
wrote:
> On Thu, Apr 25, 2024 at 9:17 AM Robert Haas wrote:
> > It is difficult to imagine a world in which we have both requiredirect
> > and forcedirect and people are not confused.
>
> Yeah... Any thoughts on a better scheme? require_auth was mea
Hi Isaac
You are doing the minor version upgrade so it's not a big effort as
compared to major version upgrade, following is the process to do it.
*Minor releases never change the internal storage format and are always
compatible with earlier and later minor releases of the same major version
num
On Thu, Apr 25, 2024 at 12:34 PM Tom Lane wrote:
> Yes. We've heard that argument about "this only affects extensions
> that choose to use it" before, and it's nonsense. As soon as you
> extend system-wide APIs, the consequences are system-wide: everybody
> has to cope with the new definition.
On Thu, Apr 25, 2024 at 2:52 AM Frédéric Yhuel
wrote:
>
> Le 24/04/2024 à 21:10, Melanie Plageman a écrit :
> > On Wed, Apr 24, 2024 at 8:08 AM Frédéric Yhuel
> > wrote:
> >>
> >> Hello,
> >>
> >> I would like to suggest a new parameter, autovacuum_max_threshold, which
> >> would set an upper lim
On Wed, 2024-04-24 at 18:19 +0530, Bharath Rupireddy wrote:
> I added a flush callback named TableModifyBufferFlushCallback; when
> provided by callers invoked after tuples are flushed to disk from the
> buffers but before the AM frees them up. Index insertions and AFTER
> ROW INSERT triggers can b
Hello everyone, I hope you're doing well. Does anyone have a guide or know
how to perform an upgrade from PostgreSQL 13.12 to 13.14 on Linux? I've
searched in various places but haven't found any solid guides, and truth be
told, I'm a bit of a novice with PostgreSQL. Any help would be appreciated.
Robert Haas writes:
> This thread caught my eye this morning, and I'm confused.
> On Thu, Apr 25, 2024 at 12:44 AM Tom Lane wrote:
>> The primary outcome would be to require a huge amount of new work
>> to be done by a lot of software, much of it not under our control.
> What, what is the "lot o
On Thu, Apr 25, 2024 at 9:17 AM Robert Haas wrote:
>
> It is difficult to imagine a world in which we have both requiredirect
> and forcedirect and people are not confused.
Yeah... Any thoughts on a better scheme? require_auth was meant to
lock down overly general authentication; maybe a require_
On Thu, Apr 25, 2024 at 12:16 PM Jacob Champion
wrote
> Right. I don't like that it still happens with
> sslnegotiation=requiredirect, but I suspect that this is not the
> thread to complain about it in. Maybe I can propose a
> sslnegotiation=forcedirect or something for 18, to complement a
> post
On Wed, Apr 24, 2024 at 3:08 PM Daniel Gustafsson wrote:
> LGTM; only one small comment which you can ignore if you feel it's not worth
> the extra words.
>
> +pg_combinebackup when the checksum status of the
> +cluster has been changed; see
>
> I would have preferred that this sentence in
On Tue, Apr 23, 2024 at 2:20 PM Heikki Linnakangas wrote:
>
> Attached patch tries to fix and clarify those.
s/negotiatied/negotiated/ in the attached patch, but other than that
this seems like a definite improvement. Thanks!
> (Note that the client will only attempt GSSAPI encryption if it can
On Wed, Apr 24, 2024 at 3:20 PM Daniel Gustafsson wrote:
> Patch LGTM.
Thanks. Here's an updated version with fixes for the other issues you mentioned.
--
Robert Haas
EDB: http://www.enterprisedb.com
v2-0001-Minor-fixes-to-pg_combinebackup-and-its-documenta.patch
Description: Binary data
Hi!
Recently, I'm stumbled in such an easy task as build Postgres with clang
and
sanitizer.
Usually, I use autotools to build Postgres something like this:
SRC="../postgres"
TRG="/tmp"
LINUX_CONFIGURE_FEATURES="
On Thu, Apr 25, 2024 at 09:13:07AM +0200, Frédéric Yhuel wrote:
> Le 24/04/2024 à 21:57, Nathan Bossart a écrit :
>> Yeah, I'm having trouble following the proposed mechanics for this new GUC,
>> and it's difficult to understand how users would choose a value. If we
>> just want to cap the number
jian he writes:
> On Wed, Apr 24, 2024 at 5:47 PM Yugo NAGATA wrote:
>> This message was introduced by 278cb434110 which was aiming to
>> standardize the wording for similar errors. We can find the pattern
>> "missing {support function | operator} %d(%u,%u) in opfamily %u"
>> in several places.
Hi,
On 2024-04-25 00:20:05 -0400, Tom Lane wrote:
> Something I've been mulling over is whether to suggest that the
> proposed "new port" should only target building with gcc.
Yes. I also wonder if such a port should only support building with sysv
style shared library support, rather than the A
Hi,
On 2024-04-18 10:54:18 +0200, Christoph Berg wrote:
> Re: Andres Freund
> > > This commit broke VPATH builds when the original source directory
> > > contains symlinks.
> > Argh, this is missing spaces around the '=', leading to the branch always
> > being entered.
>
> Glad I found at least s
On Wed, Apr 24, 2024 at 5:47 PM Yugo NAGATA wrote:
>
> On Wed, 24 Apr 2024 15:05:00 +0800
> jian he wrote:
>
> > hi.
> >
> > in make_pathkey_from_sortinfo
> >
> > equality_op = get_opfamily_member(opfamily,
> > opcintype,
> > opcintype,
> > BTEqualStrategyNumber);
> > if (!OidIsValid(equali
Daniel Gustafsson writes:
>> On 25 Apr 2024, at 13:23, Dagfinn Ilmari Mannsåker wrote:
>
>> An IRC conversation just now made me notice that it would be handy to
>> have stable links for the descrpitions of the various COPY formats, per
>> the attached patch.
>
> No objections, that seems perfec
On Tue, 23 Apr 2024 at 12:37, Heikki Linnakangas wrote:
> This is really a bug fix. It didn't matter when TransactionId and
> MultiXactOffset were both typedefs of uint32, but it was always wrong.
> The argument name 'xid' is also misleading.
>
> I think there are some more like that, MXOffsetToF
Hi, Karina!
On Thu, 25 Apr 2024 at 17:44, Karina Litskevich
wrote:
> Hi, hackers!
>
> On Thu, Apr 25, 2024 at 4:00 PM Pavel Borisov
> wrote:
>
>> 0005: Rename checkunique parameter to more user friendly as proposed by
>> Peter Eisentraut and Alexander Korotkov
>>
>
> I'm not sure renaming check
Peter Eisentraut writes:
> On 25.04.24 06:20, Tom Lane wrote:
>> Something I've been mulling over is whether to suggest that the
>> proposed "new port" should only target building with gcc.
> My understanding is that the old xlc is dead and has been replaced by
> "xlclang", which is presumably a
Hi, hackers!
On Thu, Apr 25, 2024 at 4:00 PM Pavel Borisov
wrote:
> 0005: Rename checkunique parameter to more user friendly as proposed by
> Peter Eisentraut and Alexander Korotkov
>
I'm not sure renaming checkunique is a good idea. Other arguments of
bt_index_check and bt_index_parent_check f
On Thu, Apr 25, 2024 at 1:38 PM Masahiko Sawada wrote:
>
> On Thu, Apr 25, 2024 at 12:17 PM John Naylor wrote:
> >
> > On Thu, Apr 25, 2024 at 9:50 AM Masahiko Sawada
> > wrote:
> > >
> > > > I saw a SIGSEGV there when using tidstore to write a fix for something
> > > > else.
> > > > Patch att
Hi, hackers!
On Wed, 24 Apr 2024 at 13:58, Alexander Korotkov
wrote:
> On Wed, Apr 17, 2024 at 9:38 AM Peter Eisentraut
> wrote:
> > On 24.10.23 22:13, Alexander Korotkov wrote:
> > > On Wed, Sep 28, 2022 at 11:44 AM Aleksander Alekseev
> > > wrote:
> > >>> I think, this patch was marked as "W
Hi,
> Now Majid stated that he uses "RBD" - Majid, any chance to specify
> what that RBD really is ? What's the tech? What fs? Any ioping or fio
> results? What's the blockdev --report /dev/XXX output ? (you stated
> "high" latency and "high" bandwidth , but it is relative, for me 15ms+
> is high
This thread caught my eye this morning, and I'm confused.
On Thu, Apr 25, 2024 at 12:44 AM Tom Lane wrote:
> The primary outcome would be to require a huge amount of new work
> to be done by a lot of software, much of it not under our control.
What, what is the "lot of software" that would have
Hi,
Thank you for working on this!
On Sat, 13 Apr 2024 at 05:12, Andres Freund wrote:
>
> Hi,
>
> We have CI support for mingw, but don't run the task by default, as it eats up
> precious CI credits. However, for cfbot we are using custom compute resources
> (currently donated by google), so we
> On 25 Apr 2024, at 13:23, Dagfinn Ilmari Mannsåker wrote:
> An IRC conversation just now made me notice that it would be handy to
> have stable links for the descrpitions of the various COPY formats, per
> the attached patch.
No objections, that seems perfectly a reasonable idea. Maybe we sho
On Thu, Apr 25, 2024 at 12:50 PM Richard Guo wrote:
>
> On Wed, Apr 24, 2024 at 5:13 PM Richard Guo
> wrote:
>
>> In sort_inner_and_outer, we create mergejoin join paths by explicitly
>> sorting both relations on each possible ordering of the available
>> mergejoin clauses. However, if there ar
Hi hackers,
An IRC conversation just now made me notice that it would be handy to
have stable links for the descrpitions of the various COPY formats, per
the attached patch.
- ilmari
>From 5e59273370a39cd46627b89145a7c06dd6f00f7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dagfinn=20Ilmari=20Manns=
čt 25. 4. 2024 v 12:53 odesílatel Melanie Plageman <
melanieplage...@gmail.com> napsal:
> On Thu, Apr 25, 2024 at 2:13 AM Pavel Stehule
> wrote:
> >
> > Hi
> >
> > yesterday, I had to fix strange issue on standby server
> >
> > The query to freshly updated data fails
> >
> > select * from seller_
On Wed, 24 Apr 2024 at 15:49, Amit Kapila wrote:
>
> On Tue, Apr 23, 2024 at 4:53 PM Amit Kapila wrote:
> >
> > On Wed, Mar 13, 2024 at 11:59 AM vignesh C wrote:
> > >
> > > On Wed, 13 Mar 2024 at 10:12, Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > >
> > > > For 0002, instead of avoid resett
On Thu, Apr 25, 2024 at 2:13 AM Pavel Stehule wrote:
>
> Hi
>
> yesterday, I had to fix strange issue on standby server
>
> The query to freshly updated data fails
>
> select * from seller_success_rate where create_time::date = '2024-04-23';
> ERROR: 58P01: could not access status of transaction
On Wed, Apr 24, 2024 at 10:28 AM shveta malik wrote:
>
> Modified the logic to remove only synced temporary slots during
> SQL-function exit.
>
> Please find v11 with above changes.
>
LGTM, so pushed!
--
With Regards,
Amit Kapila.
On Thu, Apr 25, 2024 at 7:01 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, April 24, 2024 6:29 PM vignesh C wrote:
> >
> >
> > The attached patch
> > v7-0001-Table-sync-missed-due-to-race-condition-in-subscr.patch
> > applies for master and PG16 branch,
> > v7-0001-Table-sync-missed-due-to-rac
On 2024-Apr-25, Alexander Lakhin wrote:
> While studying the NO INHERIT option, I've noticed that the documentation
> probably misses it's specification for NOT NULL:
> https://www.postgresql.org/docs/devel/sql-createtable.html
>
> where column_constraint is:
> ...
> [ CONSTRAINT constraint_name
čt 25. 4. 2024 v 10:52 odesílatel Andrey M. Borodin
napsal:
>
>
> > On 25 Apr 2024, at 12:06, Pavel Stehule wrote:
> >
> > Unfortunately, I have not direct access to backup, so I am not able to
> test it. But VACUUM FREEZE DISABLE_PAGE_SKIPPING on master didn't help
> >
>
> If Primary considers
Hi,
Currently the launcher's latch is used for the following: a) worker
process attach b) worker process exit and c) subscription creation.
Since this same latch is used for multiple cases, the launcher process
is not able to handle concurrent scenarios like: a) Launcher started a
new apply worker
> On 25 Apr 2024, at 12:06, Pavel Stehule wrote:
>
> Unfortunately, I have not direct access to backup, so I am not able to test
> it. But VACUUM FREEZE DISABLE_PAGE_SKIPPING on master didn't help
>
If Primary considers all freezable tuples frozen, but a standby does not,
"disable page ski
On Thu, 25 Apr 2024 10:26:41 +0200
Peter Eisentraut wrote:
> On 24.04.24 15:25, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On 24.04.24 11:59, Yugo NAGATA wrote:
> >>> I noticed that a permission check is performed in be_lo_put()
> >>> just after returning inv_open(), but teh permission sh
On 24.04.24 15:25, Tom Lane wrote:
Peter Eisentraut writes:
On 24.04.24 11:59, Yugo NAGATA wrote:
I noticed that a permission check is performed in be_lo_put()
just after returning inv_open(), but teh permission should be
already checked in inv_open(), so I think we can remove this
part of cod
On 25.04.24 01:50, Michael Paquier wrote:
On Wed, Apr 24, 2024 at 09:25:09AM -0400, Tom Lane wrote:
I agree. Do you want to do the honors?
Good catch. The same check happens when the object is opened. Note
that you should be able to remove utils/acl.h at the top of
be-fsstubs.c as this woul
On 2024-Apr-24, Bruce Momjian wrote:
> I agree that targeting PG 18 for a new-er AIX port is the reasonable
> approach. If there is huge demand, someone can create an AIX fork for
> PG 17 using the reverted patches --- yeah, lots of pain there, but we
> have carried the AIX pain for too long with
On 25.04.24 06:20, Tom Lane wrote:
Something I've been mulling over is whether to suggest that the
proposed "new port" should only target building with gcc.
On the one hand, that would (I think) remove a number of annoying
issues, and the average end user is unlikely to care which compiler
their
On 25.04.24 06:53, Sutou Kouhei wrote:
I haven't got any reply since 2024-03-15:
https://www.postgresql.org/message-id/flat/20240315.173754.2049843193122381085.kou%40clear-code.com#07aefc636d8165204ddfba971dc9a490
(I sent some pings.)
So I called this status as "stalled".
I'm not familiar with
On Wed, Apr 24, 2024 at 5:13 PM Richard Guo wrote:
> In sort_inner_and_outer, we create mergejoin join paths by explicitly
> sorting both relations on each possible ordering of the available
> mergejoin clauses. However, if there are no available mergejoin
> clauses, we can skip this process ent
Hi,
On Thu, Apr 25, 2024 at 09:00:00AM +0300, Alexander Lakhin wrote:
> Hi,
>
> 25.04.2024 08:00, Bertrand Drouvot wrote:
> >
> > > though concurrent create/drop operations can still produce
> > > the "cache lookup failed" error, which is probably okay, except that it is
> > > an INTERNAL_ERROR,
On Wed, Apr 24, 2024 at 4:01 PM Alena Rybakina
wrote:
> I tested the main postgres branch with and without your fix using a script
> that was written by me. It consists of five scenarios and I made a
> comparison in the logs between the original version of the master branch
> and the master branc
Hi Nathan, thanks for your review.
Le 24/04/2024 à 21:57, Nathan Bossart a écrit :
Yeah, I'm having trouble following the proposed mechanics for this new GUC,
and it's difficult to understand how users would choose a value. If we
just want to cap the number of tuples required before autovacuum
On 24/04/2024 23:51, Peter Eisentraut wrote:
On 08.04.24 10:38, Heikki Linnakangas wrote:
On 08/04/2024 04:25, Heikki Linnakangas wrote:
One important open item now is that we need to register a proper ALPN
protocol ID with IANA.
I sent a request for that:
https://mailarchive.ietf.org/arch/ms
čt 25. 4. 2024 v 8:52 odesílatel Andrey M. Borodin
napsal:
>
>
> > On 25 Apr 2024, at 11:12, Pavel Stehule wrote:
> >
> > yesterday, I had to fix strange issue on standby server
>
> It’s not just broken reading, if this standby is promoted in HA cluster -
> this would lead to data loss.
> Recent
82 matches
Mail list logo