Junwang, Kirill,
The split work has been done. I created a new patch for removing
redundant smgrclose() function as attached.
Please help review it.
Thanks,
Steven
Steven Niu 于2024年8月12日周一 18:11写道：
> Kirill,
>
> Good catch!
> I will split the patch into two to cover both cases.
>
> Thanks,
> S
Hi, Kirill, Junwang,
I made this patch to address the refactor issue in our previous email
discussion.
https://www.postgresql.org/message-id/flat/CABBtG=cdtcbdcbk7mcsy6bjr3s5xutog0vsffuw8olduyyc...@mail.gmail.com
That is, the for loop in function smgrdestroy() and smgrdounlinkall can be
replaced
On Tue, Aug 13, 2024, at 13:01, Joel Jacobson wrote:
> I think this is acceptable, since it produces more correct results.
In addition, I've traced the rscale_adjustment -15 mul_var() calls to originate
from numeric_exp() and numeric_power(), so I thought it would be good to
brute-force test those
On 07.08.24 09:24, Heikki Linnakangas wrote:
On 07/08/2024 09:56, Peter Eisentraut wrote:
I think we could remove the TRACE_SORT macro.
The TRACE_SORT macro has guarded the availability of the trace_sort GUC
setting. But it has been enabled by default ever since it was
introduced in PostgreSQ
Hi,
On Tue, Aug 13, 2024 at 04:30:46PM -0500, Nathan Bossart wrote:
> On Tue, Aug 13, 2024 at 01:12:30PM -0500, Imseih (AWS), Sami wrote:
> >> None of this seems intractable to me. 1 Hz seems like an entirely
> >> reasonable place to start, and it is very easy to change (or to even make
> >> conf
On Fri, Aug 2, 2024 at 8:11 AM Masahiko Sawada wrote:
>
> On Wed, Jul 31, 2024 at 11:27 PM Anthonin Bonnefoy
> wrote:
> >
> > On Wed, Jul 31, 2024 at 9:36 PM Masahiko Sawada
> > wrote:
> > > Meanwhile, I think we can push 0001 and 0002 patches since they are in
> > > good shape. I've updated co
On Tue, Aug 13, 2024 at 9:48 AM Amit Kapila wrote:
>
> On Mon, Aug 12, 2024 at 3:37 PM shveta malik wrote:
> >
> > On Fri, Aug 9, 2024 at 2:39 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > >
> > > > + /*
> > > > + * Register a callback to reset the origin state before aborting the
> > > > + *
On Wed, Aug 14, 2024 at 2:24 AM Jacob Champion
wrote:
>
> On Fri, Aug 9, 2024 at 2:26 AM Ashutosh Bapat
> wrote:
> > Here are my observations with the patch applied
> > 1. If I run configure without setting PG_TEST_EXTRA, it won't run the
> > tests that require PG_TEST_EXTRA to be set. This is ex
On Mon, Jun 24, 2024 at 4:01 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> Hi,
>
> On Mon, Jun 17, 2024 at 5:55 PM Bharath Rupireddy
> wrote:
>
> Please find the attached v41 patches implementing the idea of vacuum
> doing the invalidation.
>
> Thoughts?
>
>
>
Some mino
Hi Heikki & Team,
I tried to look at the assembly code changes with our team, in the below file.
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index 29ac6cdcd9..69582f4ae7 100644
--- a/src/include/storage/s_lock.h
+++ b/src/include/storage/s_lock.h
static __inli
Hi Vignesh, Here are my review comments for the latest patchset:
Patch v20240813-0001. No comments
Patch v20240813-0002. No comments
Patch v20240813-0003. No comments
Patch v20240813-0004. See below
Patch v20240813-0005. No comments
//
Patch v20240813-0004
==
src/backend/catalog/pg_subs
On Tue, Aug 13, 2024 at 04:46:34PM -0500, Nathan Bossart wrote:
> I've been preparing 0001 for commit. I've attached what I have so far.
>
> The main changes are the implementations of pg_abs_* and pg_neg_*. For the
> former, I've used abs()/i64abs() for the short/int implementations. For
> the
Sounds fine by me (still need to check all three patterns).
+ if (list_length(psrc->query_list) > 0)
+ pgstat_report_query_id(linitial_node(Query, psrc->query_list)->queryId,
false);
Something that slightly worries me is to assume that the first Query
in the query_list is fetched. Usin
On Tuesday, August 13, 2024 7:04 PM Amit Kapila wrote:
>
> On Tue, Aug 13, 2024 at 10:09 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Here is V13 patch set which addressed above comments.
> >
>
> 1.
> +ReportApplyConflict(int elevel, ConflictType type, EState *estate,
> +ResultRelInfo *relinfo,
>
On Wed, Aug 14, 2024 at 1:05 PM Jeff Davis wrote:
> The only alternative is to essentially ban the use of non-_l variants,
> which is fine I suppose, but causes a fair amount of code churn.
Let's zoom out a bit and consider some ways we could set up the
process, threads and individual calls:
1.
On Tuesday, August 13, 2024 7:33 PM Michail Nikolaev
wrote:
> I think this is an independent issue which can be discussed separately in the
> original thread[1], and I have replied to that thread.
>Thanks! But it seems like this part is still relevant to the current thread:
> > It also seems
On Tue, Aug 13, 2024 at 10:15 PM Alexander Korotkov
wrote:
> On Tue, Aug 13, 2024 at 9:39 PM Heikki Linnakangas wrote:
> >
> > This causes an assertion failure when executed in a hot standby server:
> >
> > select * from pg_check_visible('pg_database');
> >
> > TRAP: failed Assert("!RecoveryInP
On 8/10/24 9:10 AM, Peter Eisentraut wrote:
Thoughts?
I like it. Not because of the security issue but mainly because it is
more correct to do it this way. Plus the old code running stat() on
Windows also made little sense.
I think this simple fix can be committed.
Andreas
On Sat, 2024-08-10 at 09:42 +1200, Thomas Munro wrote:
> The NetBSD situation is more vexing. I was trying to find out if
> someone is working on it and unfortunately it looks like there is a
> principled stand against adding it:
>
> https://mail-index.netbsd.org/tech-userlevel/2015/12/28/msg0095
On Tue, Aug 13, 2024 at 10:00 PM vignesh C wrote:
>
> On Tue, 13 Aug 2024 at 09:19, Peter Smith wrote:
> >
> > 3.1. GENERAL
> >
> > Hmm. I am guessing this was provided as a separate patch to aid review
> > by showing that existing functions are moved? OTOH you can't really
> > judge this patch p
On Thu, Aug 8, 2024 at 2:23 PM Peter Eisentraut wrote:
>
> Thank you for your extensive testing. Here is a new patch set that has
> fixed all the issues you have reported (MERGE, sublinks, statistics,
> ANALYZE).
if (coldef->generated && restdef->generated &&
coldef->generate
On 8/13/24 7:56 PM, Jeff Davis wrote:
But I don't think that's a major problem -- we can just move the
hardcoded test into pg_newlocale_from_collation() and return a
predefined struct with collate_is_c/ctype_is_c already set.
I tried that out but thought it felt cleaner to do the hardcoding in
Here's another mystery from Windows + MinGW. Although "fairywren" is
green, that is because it lacks ICU, which would activate extra tests.
CI is green too, but the optional CI task "Windows - Server 2019,
MinGW64 - Meson" has ICU and it is now failing if you trigger it[1]
after commit 35eeea62, i
On Tue, Aug 13, 2024 at 4:30 PM Nathan Bossart
wrote:
> On Tue, Aug 13, 2024 at 01:12:30PM -0500, Imseih (AWS), Sami wrote:
> >> None of this seems intractable to me. 1 Hz seems like an entirely
> >> reasonable place to start, and it is very easy to change (or to even
> make
> >> configurable).
Hey Thomas,
Thanks for picking this up. I think your patch looks really good. Are
you familiar with gcc's function poisoning?
#include
#pragma GCC poison puts
int main(){
#pragma GCC bless begin puts
puts("a");
#pragma GCC bless end
On Tue Aug 13, 2024 at 9:15 AM CDT, Greg Sabino Mullane wrote:
Sounds like a good idea. You probably want to ask on pgsql-www. I imagine
it would have to be coded against this:
https://git.postgresql.org/gitweb/?p=pgweb.git
A working patch would probably be nice to get things started. but I
rec
I've been preparing 0001 for commit. I've attached what I have so far.
The main changes are the implementations of pg_abs_* and pg_neg_*. For the
former, I've used abs()/i64abs() for the short/int implementations. For
the latter, I've tried to use __builtin_sub_overflow() when possible, as
that
On Tue, Aug 13, 2024 at 01:12:30PM -0500, Imseih (AWS), Sami wrote:
>> None of this seems intractable to me. 1 Hz seems like an entirely
>> reasonable place to start, and it is very easy to change (or to even make
>> configurable). pg_stat_progress_vacuum might show slightly old values in
>> this
On Wed, 14 Aug 2024 at 01:13, Heikki Linnakangas wrote:
>
> On 05/04/2024 13:49, Andrey M. Borodin wrote:
> >> On 5 Apr 2024, at 02:08, Kirill Reshke wrote:
>
> Thanks for taking a look, Kirill!
>
> >> maybe we need some hooks here? Or maybe, we can take CSN here from
> >> extension somehow.
> >
On Fri, Aug 9, 2024 at 2:26 AM Ashutosh Bapat
wrote:
> Here are my observations with the patch applied
> 1. If I run configure without setting PG_TEST_EXTRA, it won't run the
> tests that require PG_TEST_EXTRA to be set. This is expected.
> 2. But it wont' run tests even if PG_TEST_EXTRA is set wh
On 09.08.24 10:59, Heikki Linnakangas wrote:
On 09/08/2024 11:16, Michael Banck wrote:
Hi,
Holger Jacobs complained in pgsql-admin that in v17, if you have the ICU
development libraries installed but not pkg-config, you get a somewhat
unhelpful error message about ICU not being present:
|check
On Tue, Aug 13, 2024 at 10:42 AM Greg Sabino Mullane wrote:
> Fair enough. I think the performance impact is acceptable, as evidenced by
> the large number of people that turn it on. And it is easy enough to turn it
> off again, either via --no-data-checksums or pg_checksums --disable.
> When I
> On Sun, Aug 11, 2024 at 09:34:55PM GMT, Dmitry Dolgov wrote:
> > On Sun, Aug 11, 2024 at 07:54:05PM +0300, Sergei Kornilov wrote:
> >
> > This feature will improve my monitoring. Even in patch 0001. I think there
> > are many other people in the thread who think this is useful. So maybe we
> >
On Tue, Aug 13, 2024 at 9:39 PM Heikki Linnakangas wrote:
>
> This causes an assertion failure when executed in a hot standby server:
>
> select * from pg_check_visible('pg_database');
>
> TRAP: failed Assert("!RecoveryInProgress()"), File:
> "../src/backend/storage/ipc/procarray.c", Line: 2710,
On Tue, Aug 13, 2024 at 10:38 AM Sofia Kopikova
wrote:
> I noticed that in commit d3cc5ffe81f6 some GUC variables were moved to
> header files. According to the commit message in 8ec569479, all
> variables in header files must be marked with PGDLLIMPORT, am I right?
>
> I've made a patch that adds
On Tue, Aug 6, 2024 at 5:42 PM Matthias van de Meent
wrote:
> Attached is version 16 now.
I ran this with my old land registry benchmark, used for validating
the space utilization impact of nbtree deduplication (among other
things). This isn't obviously the best benchmark for this sort of
thing,
This causes an assertion failure when executed in a hot standby server:
select * from pg_check_visible('pg_database');
TRAP: failed Assert("!RecoveryInProgress()"), File:
"../src/backend/storage/ipc/procarray.c", Line: 2710, PID: 1142572
GetStrictOldestNonRemovableTransactionId does this:
On Tue, Aug 13, 2024 at 12:49 PM Tom Lane wrote:
> This discussion tickles a concern I've had for awhile: do we really
> know that modern postgres_fdw would work with an 8.3 server (never
> mind 8.1)? How many of us are in a position to test or debug such
> a setup? The discussions we've had aro
On Fri, Aug 9, 2024 at 11:48 AM Melanie Plageman
wrote:
> In the adaptive freezing code, I use the time stream to answer a yes
> or no question. I translate a time in the past (now -
> target_freeze_duration) to an LSN so that I can determine if a page
> that is being modified for the first time a
On Tue, Aug 13, 2024 at 12:15 PM Fujii Masao
wrote:
> On 2024/08/09 17:49, Etsuro Fujita wrote:
> > I just thought consolidating the information to one place would make
> > the documentation more readable.
>
> Yes, so I think that adding a note about the required remote server version
> to the cro
On Wed, Aug 7, 2024 at 5:55 AM Heikki Linnakangas wrote:
> On 06/08/2024 03:58, Thomas Munro wrote:
> > On Tue, Aug 6, 2024 at 2:41 AM Heikki Linnakangas wrote:
> >> What if the message contains multiple attribute of the same type? If
> >> there's a duplicate Message-Authenticator, we should sure
None of this seems intractable to me. 1 Hz seems like an entirely
reasonable place to start, and it is very easy to change (or to even make
configurable). pg_stat_progress_vacuum might show slightly old values in
this column, but that should be easy enough to explain in the docs if we
are really
On Tue, 2024-08-13 at 17:11 +0200, Peter Eisentraut wrote:
> They used to be completely separate from
> pg_newlocale_from_collation(),
> but now they are just mostly a thin wrapper around it. Except there
> is
> some hardcoded handling of C_COLLATION_OID and POSIX_COLLATION_OID.
> Do
> we car
On Mon, Aug 12, 2024 at 5:13 AM Amul Sul wrote:
> I tried this in the attached version and made a few additional changes
> based on Sravan's off-list comments regarding function names and
> descriptions.
>
> Now, verification happens in two passes. The first pass simply
> verifies the file names,
On Tue, Aug 13, 2024 at 11:07:46AM -0500, Imseih (AWS), Sami wrote:
> Having to add special handling to space out instrumentation
> directly in vacuum_delay_point seems very odd to me. I don't
> think vacuum_delay_point should have to worry about this.
>
> Also,
> 1/ what is an appropriate interva
Please disregards this point from the last reply:
"""
2/ What if there are other callers in the future that wish
to instrument parallel vacuum workers? they will need to implement
similar logic.
"""
I misspoke about this and this point does not matter since only
vacuum sleep matters for this
On 8/13/24 10:57 AM, Nathan Bossart wrote:
On Tue, Aug 13, 2024 at 10:47:51AM -0500, Imseih (AWS), Sami wrote:
On 8/13/24 10:09 AM, Nathan Bossart wrote:
On Mon, Aug 12, 2024 at 05:35:08PM -0500, Imseih (AWS), Sami wrote:
Skimming the last few messages of that thread [0], it looks like Bertr
On Tue, Aug 13, 2024 at 10:47:51AM -0500, Imseih (AWS), Sami wrote:
> On 8/13/24 10:09 AM, Nathan Bossart wrote:
>> On Mon, Aug 12, 2024 at 05:35:08PM -0500, Imseih (AWS), Sami wrote:
>> > > Skimming the last few messages of that thread [0], it looks like Bertrand
>> > > is exploring ways to avoid
On 8/13/24 10:09 AM, Nathan Bossart wrote:
On Mon, Aug 12, 2024 at 05:35:08PM -0500, Imseih (AWS), Sami wrote:
Skimming the last few messages of that thread [0], it looks like Bertrand
is exploring ways to avoid so many interrupts. I guess the unavoidable
question is whether this work is stil
I'm wondering if after this patch series, lc_collate_is_c() and
lc_ctype_is_c() are still useful.
They used to be completely separate from pg_newlocale_from_collation(),
but now they are just mostly a thin wrapper around it. Except there is
some hardcoded handling of C_COLLATION_OID and POSIX
On Mon, Aug 12, 2024 at 05:35:08PM -0500, Imseih (AWS), Sami wrote:
>> Skimming the last few messages of that thread [0], it looks like Bertrand
>> is exploring ways to avoid so many interrupts. I guess the unavoidable
>> question is whether this work is still worthwhile given that improvement.
>
On Tue, Jul 23, 2024 at 9:37 AM David Christensen wrote:
> I'm not married to the exact syntax of this feature; anything else short
> and consistent could work if `ALL` is considered to potentially
> gain a different interpretation in the future.
>
GROUP BY *
Just kidding. But a big +1 to the w
Now that I've spent some time away from this, I'm reconsidering why we are
going through all the trouble of semi-jumbling SET statements. Maybe we
just keep it simple and everything becomes "SET myvar = $1" or even "SET
myvar" full stop? I'm having a hard time finding a real-world situation in
whic
On Thu, Aug 8, 2024 at 6:11 AM Peter Eisentraut
wrote:
> My understanding was that the reason for some hesitation about adopting
> data checksums was the performance impact. Not the checksumming itself,
> but the overhead from hint bit logging. The last time I looked into that,
> you could get
On Tue, Aug 13, 2024 at 5:23 PM Pavel Stehule wrote:
> út 13. 8. 2024 v 16:13 odesílatel Jelte Fennema-Nio
> napsal:
>>
>> Shared libraries of extensions might want to invalidate or update their
>> own caches whenever a CREATE/ALTER/DROP EXTENSION command is run for
>> their extension (in any ba
Hi hackers,
I noticed that in commit d3cc5ffe81f6 some GUC variables were moved to
header files. According to the commit message in 8ec569479, all
variables in header files must be marked with PGDLLIMPORT, am I right?
I've made a patch that adds missing PGDLLIMPORTs, please, take a look.
--
Bes
út 13. 8. 2024 v 16:13 odesílatel Jelte Fennema-Nio
napsal:
> Shared libraries of extensions might want to invalidate or update their
> own caches whenever a CREATE/ALTER/DROP EXTENSION command is run for
> their extension (in any backend). Right now this is non-trivial to do
> correctly and effi
Sounds like a good idea. You probably want to ask on pgsql-www. I imagine
it would have to be coded against this:
https://git.postgresql.org/gitweb/?p=pgweb.git
A working patch would probably be nice to get things started. but I
recognize it's a little bit of chicken-and-egg.
Cheers,
Greg
Shared libraries of extensions might want to invalidate or update their
own caches whenever a CREATE/ALTER/DROP EXTENSION command is run for
their extension (in any backend). Right now this is non-trivial to do
correctly and efficiently. But if the extension catalog was part of a
syscache this coul
Hi,
Over on the security mailing list, Tom Lane expressed discontent about
a few things related to astreamer_gzip.c. Here's a patch to improve
the comments to try to address those concerns.
This ended up being discussed on -security because
f80b09bac87d6b49f5dbb6131da5fbd9b9773c5c moved the code,
And I have one suggestion for pg_stat_vacuum_database: I suppose we
should add database's name column after 'dboid' column because it is
difficult to read statistics without database's name. We could call it
'datname' just like in 'pg_stat_database' view.
Regards,
Ilia Evdokimov,
Tantor Labs
On 10.8.24 22:37, Andrei Zubkov wrote:
Hi, Ilia!
Do you consider not to create new table in pg_catalog but to save
statistics in existing table? I mean pg_class or
pg_stat_progress_analyze, pg_stat_progress_vacuum?
Thank you for your interest on our patch!
*_progress views is not our case.
Hi,
I am working on using the read stream in pg_visibility. There are two
places to use it:
1- collect_visibility_data()
This one is straightforward. I created a read stream object if
'include_pd' is true because read I/O is done when 'include_pd' is
true. There is ~4% timing improvement with th
On Tue, 13 Aug 2024 at 12:31, Peter Smith wrote:
>
> OBSERVATION #2
>
> When 1000s of sequences are refreshed (set to INIT) then there are
> 1000s of logs like below:
>
> ...
> 2024-08-13 16:13:57.873 AEST [10301] LOG: sequence "public.seq_0698"
> of subscription "sub3" set to INIT state
> 2024-0
On Tue, Aug 13, 2024 at 11:25 PM Thomas Munro wrote:
> On Tue, Aug 13, 2024 at 6:23 PM Heikki Linnakangas wrote:
> > On 13/08/2024 08:45, Thomas Munro wrote:
> > Patches 1 and 2 look good to me.
>
> Thanks. I went ahead and pushed these ones. A couple of Macs in the
> build farm are failing, as
Hello!
> I think this is an independent issue which can be discussed separately in
the
> original thread[1], and I have replied to that thread.
Thanks! But it seems like this part is still relevant to the current thread:
> It also seems possible that a conflict could be resolved by a concurrent
On Tue, Aug 13, 2024 at 6:23 PM Heikki Linnakangas wrote:
> On 13/08/2024 08:45, Thomas Munro wrote:
> Patches 1 and 2 look good to me.
Thanks. I went ahead and pushed these ones. A couple of Macs in the
build farm are failing, as if they didn't include and
haven't seen the type locale_t. CI'
On Tue, Aug 13, 2024 at 10:09 AM Zhijie Hou (Fujitsu)
wrote:
>
> Here is V13 patch set which addressed above comments.
>
1.
+ReportApplyConflict(int elevel, ConflictType type, EState *estate,
+ ResultRelInfo *relinfo,
The change looks better but it would still be better to keep elevel
and type a
On Tue, Aug 13, 2024, at 12:23, Dean Rasheed wrote:
> On Tue, 13 Aug 2024 at 08:49, Joel Jacobson wrote:
>>
>> I reran the tests and v5 produces much fewer diffs than v4.
>> Not sure if the remaining ones are problematic or not.
...
>
> Yes, that's exactly the sort of thing you'd expect to see. Th
Hello,
Further testing found that using a property graph with the plpgsql
function crashed the server. Please take a look at the attached SQL
file for reference tables.
postgres=# create or replace function func() returns int as
postgres-# $$
postgres$# declare person_av varchar;
postgres$# begin
On Tue, 13 Aug 2024 at 08:49, Joel Jacobson wrote:
>
> I reran the tests and v5 produces much fewer diffs than v4.
> Not sure if the remaining ones are problematic or not.
>
> joel@Joels-MBP postgresql % ./test-mul_var-verify-v5.sh
> HEAD is now at a67a49648d Rename C23 keyword
> SET
> DROP TABLE
Hi,
- IIUC your "fast forward" concern is not related to this particular thread but
you
- think it's already an issue on the master branch (outside of the
BUILDING_SNAPSHOT
- handling we are discussing here), is that correct? (that's also what your
coding
- changes makes me think of). If so, I
Hello,
With the attached patch found below error when try to use "Any
directed edge" syntax.
postgres=# SELECT * FROM GRAPH_TABLE (students_graph
postgres(# MATCH
postgres(# (a IS person ) - [] - (b IS person)
postgres(# COLUMNS (a.name AS person_a, b.name AS person_b)
postgres(# );
ERROR:
Hi hackers,
I found that the entry size is not aligned with MAXALIGN, but
dshash_table_item did that in dshash_table. IMHO, both entry size and
dshash_table_item should be aligned with MAXALIGN.
static dshash_table_item *
insert_into_bucket(dshash_table *hash_table,
const void *key,
dsa_pointer *b
Hi everybody
Current tests with regexp_instr() and regexp_substr() with string
'abcabcabc' are really unreadable and you would spend time to understand
that happens in these tests and if they are really correct. I'd better
change them into "abcdefghi" just like in query
SELECT regexp_su
Hi,
On Tue, Aug 13, 2024 at 03:32:42PM +0800, cca5507 wrote:
> Hi,
>
> - I re-read your comments in [0] and it looks like you've concern about
> - the 2 "if" I'm proposing above and the fast forward handling. Is that the
> case
> - or is your fast forward concern unrelated to my proposals?
>
>
On Tue, Aug 13, 2024, at 09:49, Joel Jacobson wrote:
> I reran the tests and v5 produces much fewer diffs than v4.
> Not sure if the remaining ones are problematic or not.
Attaching scripts if needed.
Regards,
Joel#!/bin/bash
git reset --hard && \
{
patch -p1 < ~/numeric_mul_rscale.patch && \
On Tue, Aug 13, 2024, at 00:56, Dean Rasheed wrote:
> On Mon, 12 Aug 2024 at 16:17, Joel Jacobson wrote:
>>
>> On Mon, Aug 12, 2024, at 17:14, Joel Jacobson wrote:
>> > The case found with the smallest rscale adjustment was this one:
>> > -[ RECORD 1 ]--+
>> > v
Robert Haas 于2024年8月13日周二 00:28写道：
> On Thu, Aug 8, 2024 at 10:27 PM Xiaoran Wang
> wrote:
> > > Add function 'pq_leave_shm_mq' to allow the process to go
> > > back to the previous pq environment.
> >
> > >.In the code as it currently exists, a parallel worker never has a
> > >.
Hi,
- I re-read your comments in [0] and it looks like you've concern about
- the 2 "if" I'm proposing above and the fast forward handling. Is that the case
- or is your fast forward concern unrelated to my proposals?
In your proposals, we will just return when fast forward. But I think we need
Sorry for the late reply.
Yes ， it's the openssl , i accidentally install two version openssl the 3.x and
1.x on the same machine.
I remove the 3.x openssl and it's ok now.
--
Best regards,
huchangqi
> -原始邮件-
> 发件人: "Thomas Munro"
> 发送时间:2024-08-02 09:27:53 (星期五)
> 收件人: "Michael
Hi Vignesh,
I have been using the latest patchset, trying a few things using many
(1000) sequences.
Here are some observations, plus some suggestions for consideration.
~
OBSERVATION #1
When 1000s of sequences are refreshed using REFRESH PUBLICATION
SEQUENCES the logging is excessive. For
82 matches
Mail list logo
