Hi,
- /* use Oid as relation identifier */
+ /* use Oid as type identifier */
pq_sendint32(out, typoid);
I think it must be "type identifier" rather than "relation identifier".
--
Regards,
ChangAo Chen
0001-Fix-a-comment-error-in-logicalrep_write_typ.patch
Description: B
On Wed, Jul 10, 2024 at 09:00:31AM +, Bertrand Drouvot wrote:
> On Wed, Jul 10, 2024 at 08:28:56AM +, Bertrand Drouvot wrote:
>> v5-0001 LGTM.
Thanks. I've applied this refactoring piece.
> /*
> * We found an existing statistics file. Read it and put all the hash
> * table
Hi,
A cfbot test suddenly failed with regression test error.
http://cfbot.cputube.org/highlights/all.html#4460
Following the link "regress" shows:
https://api.cirrus-ci.com/v1/artifact/task/5428792720621568/testrun/build/testrun/recovery/027_stream_regress/data/regression.diffs
diff --strip-tra
Hi,
On Wed, 10 Jul 2024 at 17:04, Andrew Dunstan wrote:
>
>
> On 2024-07-10 We 9:25 AM, Tom Lane wrote:
> > Dave Page writes:
> >> On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote:
> >>> As I was looking at this I wondered if there might be anywhere else that
> >>> needed adjustment. One thin
Hi,
On Thu, 11 Jul 2024 at 11:07, Tatsuo Ishii wrote:
>
> Hi,
>
> A cfbot test suddenly failed with regression test error.
>
> http://cfbot.cputube.org/highlights/all.html#4460
>
> Following the link "regress" shows:
> https://api.cirrus-ci.com/v1/artifact/task/5428792720621568/testrun/build/test
On Wed, Jul 10, 2024 at 3:09 PM shveta malik wrote:
>
> On Wed, Jul 3, 2024 at 8:31 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Wednesday, June 26, 2024 10:58 AM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> >
> > Hi,
> >
> > As suggested by Sawada-san in another thread[1].
> >
> > I am attaching the
On Fri, Jun 28, 2024 at 10:14 PM Andrei Lepikhov wrote:
> I have reviewed v7 of the patch. This improvement is good enough to be
> applied, thought.
Thank you for reviewing this patch!
> Comment may be rewritten for clarity:
> "Determine if the clauses in param_info and innerrel's lateral_vars"
On Tue, Jul 9, 2024 at 1:00 AM Tom Lane wrote:
>
> Nisha Moond writes:
> > Attached v5 patch with the translator comments as suggested.
>
> I looked at this, and I agree with the goal, but I find just about all
> of the translator comments unnecessary. The ones that are useful are
> useful only
>> The differences are that the result has an extra space at the end of
>> line. I am not familiar with Windows and has no idea why this could
>> happen (I haven't changed the patch set since May 24. The last
>> succeeded test was on July 9 14:58:44 (I am not sure about time zone).
>> Also I see e
Hi,
> The proposed patch looks rather incomplete to me, based on the fact
> that this stuff has a lot of inconsistencies with the types used when
> manipulating 64b SLRU pages. Some of them are harder to catch as the
> variables don't specifically refer to pages.
>
> So, even after v2, there are
On Tue, Jul 9, 2024 at 4:30 PM Alexander Lakhin wrote:
>
> Please look at another failure of the test [1]:
> [13:28:05.647](2.460s) not ok 26 - failover slot is synced
> [13:28:05.648](0.001s) # Failed test 'failover slot is synced'
> # at
> /home/bf/bf-build/skink-master/HEAD/pgsql/src/bin/p
On Wed, Jul 10, 2024 at 4:51 PM Euler Taveira wrote:
>
> On Tue, Jul 9, 2024, at 8:00 AM, Alexander Lakhin wrote:
>
> Hello Amit and Kuroda-san,
>
> 03.07.2024 14:02, Amit Kapila wrote:
> > Pushed 0002 and 0003. Let's wait for a discussion on 0001.
>
> Please look at another failure of the test [1
On Thu, Jul 11, 2024 at 12:46 PM cca5507 wrote:
>
> - /* use Oid as relation identifier */
> + /* use Oid as type identifier */
> pq_sendint32(out, typoid);
>
> I think it must be "type identifier" rather than "relation identifier".
>
LGTM.
--
With Regards,
Amit Kapila.
On Wed, 10 Jul 2024 at 16:58, Greg Sabino Mullane
wrote:
--snip--
> Why not build a more generic log filtering case?
>
> I looked into this, but it would be a large undertaking, given the way our
> logging system works. And as per above, I don't think the pain would be
> worth it, as duration cov
On 2024/07/11 1:35, Robert Haas wrote:
On Wed, Jul 10, 2024 at 10:10 AM Robert Haas wrote:
On Wed, Jul 10, 2024 at 1:56 AM Fujii Masao wrote:
I believe this issue occurs when the server is shut down cleanly.
The shutdown-checkpoint record retains the wal_level value used
before the shutdow
Thank you for review!
The commitfest link for tracking:
https://commitfest.postgresql.org/49/5121/
--
Regards,
ChangAo Chen
On 2024/07/10 22:35, Masahiko Sawada wrote:
BTW the new regression tests don't check the table and index names.
Isn't it better to show table and index names for better
diagnosability?
Sounds good to me. I've updated the patch as suggested.
Please see the attached patch.
Regards,
--
Fujii M
On Thursday, July 11, 2024 6:21 PM Amit Kapila wrote:
>
> On Tue, Jul 9, 2024 at 4:30 PM Alexander Lakhin
> wrote:
> >
> > Please look at another failure of the test [1]:
> > [13:28:05.647](2.460s) not ok 26 - failover slot is synced
> > [13:28:05.648](0.001s) # Failed test 'failover slot is s
On 2024-07-11 Th 4:59 AM, Nazir Bilal Yavuz wrote:
Hi,
On Wed, 10 Jul 2024 at 17:04, Andrew Dunstan wrote:
On 2024-07-10 We 9:25 AM, Tom Lane wrote:
Dave Page writes:
On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote:
As I was looking at this I wondered if there might be anywhere else
On Thu, 6 Jun 2024 at 23:10, Pavel Luzanov wrote:
>
> 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
On Sat, Jun 15, 2024 at 07:56:38PM +0100, Ilya Gladyshev wrote:
> In addition, I noticed that progress tracking is once again broken for
> partitioned tables, while looking at REINDEX implementation, attaching the
> second patch to fix it.
Thanks for the fixes, I started reviewing them but need so
On Wed, Jul 10, 2024 at 11:22 PM Nitin Motiani wrote:
>
> On Wed, Jul 10, 2024 at 10:39 PM vignesh C wrote:
> >
> > On Wed, 10 Jul 2024 at 12:28, Amit Kapila wrote:
> > > The patch missed to use the ShareRowExclusiveLock for partitions, see
> > > attached. I haven't tested it but they should als
On Tue, Jul 09, 2024 at 04:20:12PM -0700, Jeff Davis wrote:
> On Mon, 2024-07-08 at 18:05 -0700, Noah Misch wrote:
> > I'm thinking about these
> > aggravating factors for $SUBJECT:
>
> This is still marked as an open item for 17, but you've already
> acknowledged[1] that no code changes are neces
On Tue, Jul 09, 2024 at 05:47:36PM -0700, Jeff Davis wrote:
> On Tue, 2024-07-09 at 15:20 +0900, Michael Paquier wrote:
> > On Sun, Jun 30, 2024 at 03:23:44PM -0700, Noah Misch wrote:
> > Hmm. Is RestrictSearchPath() something that we should advertise more
> > strongly, thinking here about extens
Hi,
On Fri, Jul 05, 2024 at 09:35:19AM +0900, Michael Paquier wrote:
> On Thu, Jul 04, 2024 at 11:30:17AM +, Bertrand Drouvot wrote:
> >
> > /*
> > * Reads in existing statistics file into the shared stats hash.
> >
> > This comment above pgstat_read_statsfile() is not correct, fixed stats
On Thu, Jul 11, 2024, at 8:22 AM, Zhijie Hou (Fujitsu) wrote:
> The analysis and suggestion look reasonable to me.
> Here is a small patch which does the same.
LGTM. However, I would add a comment above the INSERT you moved around to remind
you that a transaction cannot be added there because it w
On Thu, Jul 11, 2024 at 11:38 AM cca5507 wrote:
> Hi,
> in func get_rel_sync_entry() we access the same tuple in pg_class three
> times:
> Oid schemaId = get_rel_namespace(relid);
> bool am_partition = get_rel_relispartition(relid);
> char relkind = get_rel_relkind(relid);
> W
Tatsuo Ishii writes:
>> I think It is related to the '628c1d1f2c' commit. This commit changed
>> the output of the regress test in Windows.
> Yeah, it seems that explains. I see few buildfarm window animals
> complain too.
I think that the contents of
src/test/regress/expected/collate.windows.wi
On 2024-07-11 Th 5:34 AM, Tatsuo Ishii wrote:
The differences are that the result has an extra space at the end of
line. I am not familiar with Windows and has no idea why this could
happen (I haven't changed the patch set since May 24. The last
succeeded test was on July 9 14:58:44 (I am not
On 2024-07-11 Th 7:29 AM, Andrew Dunstan wrote:
On 2024-07-11 Th 4:59 AM, Nazir Bilal Yavuz wrote:
Hi,
On Wed, 10 Jul 2024 at 17:04, Andrew Dunstan
wrote:
On 2024-07-10 We 9:25 AM, Tom Lane wrote:
Dave Page writes:
On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan
wrote:
As I was looking
-- Original --
From:
"Ashutosh Bapat"
I did a few tests with the patch and did not see any "large" drifts like theones observed above.Thanks for testing.I think it could be "simplified" by making use of instr_time instead of timespecfor current and absolute. Then I think it would be enough to compare theirticks.Correct I attached a v2
>
> Correct I attached a v2 of this patch that uses instr_time to check the
> elapsed
> time and break out of the loop. It needs some more benchmarking.
My email client has an issue sending attachments it seems. Reattaching
v2-0001-vaccum_delay-with-absolute-time-nanosleep.patch
Description:
+ /*
+* We allow nanosleep to handle interrupts and retry with the
remaining time.
+* However, since nanosleep is susceptible to time drift when
interrupted
+* frequently, we add a safeguard to break out of the nanosleep
whenever the
On Wed, 10 Jul 2024 at 10:35, Dave Page wrote:
> > The other failures I see are the following, which I'm just starting to
>>> dig
>>> > into:
>>> >
>>> > 26/298 postgresql:recovery / recovery/019_replslot_limit
>>> > ERROR43.05s exit status 2
>>> > 44/298 postgresql:re
Michael Paquier writes:
> On Mon, Jul 08, 2024 at 12:20:30PM +0300, Aleksander Alekseev wrote:
> -and arrays of any of these types.
> +and also arrays and records of any of these types.
> This update of the docs is incorrect, no? Records could include much
> more types than the o
Thanks for the review. Please find attached a new version with proper tabs
and indenting.
Cheers,
Greg
0002-Add-local-address-to-log_line_prefix.patch
Description: Binary data
On Thu, Jul 11, 2024 at 6:51 AM Fujii Masao wrote:
> It looks like the fast_forward field in WalSummarizerData is no longer
> necessary.
>
> So far, I haven't found any other issues with the patch.
Thanks for reviewing. Regarding fast_forward, I think I had the idea
in mind that perhaps it shoul
Hi, again!
I have finished patch and processed almost your suggestions (from [0],
[1], [2]). It remainsonlyto addtestswherethe conversionshouldwork,butI
willaddthis inthe nextversion.
[0]
https://www.postgresql.org/message-id/3381819.e9J7NaK4W3%40thinkpad-pgpro
[1]
https://www.postgresql.
On 2024-07-11 Th 9:50 AM, Tom Lane wrote:
Tatsuo Ishii writes:
I think It is related to the '628c1d1f2c' commit. This commit changed
the output of the regress test in Windows.
Yeah, it seems that explains. I see few buildfarm window animals
complain too.
I think that the contents of
src/tes
Sorry for repeating, but I have noticed that this message displays
incorrectly and just in case I'll duplicate it.
On 11.07.2024 19:17, Alena Rybakina wrote:
The errorwascausedby the specificsof storingthe "OR"clausesinthe
RestrictInfostructure.Scanning the orclauses list of the RestrictInfo
v
Hello Amit and Hou-San,
11.07.2024 13:21, Amit Kapila wrote:
We don't wait for the xmin to catch up corresponding to this insert
and I don't know if there is a way to do that. So, we should move this
Insert to after the call to pg_sync_replication_slots(). It won't
impact the general test of pg
Nisha Moond writes:
> Attached the patch v6 with suggested improvements.
> - Removed unnecessary translator comments.
> - Added appropriate identifier names where missing.
I think this is generally OK, although one could argue that it's
violating our message style guideline that primary error mes
On Thu, Jul 11, 2024 at 6:51 AM Fujii Masao wrote:
> So far, I haven't found any other issues with the patch.
Here is a new version that removes the hunks you highlighted and also
adds a test case.
--
Robert Haas
EDB: http://www.enterprisedb.com
v4-0001-Do-not-summarize-WAL-if-generated-with-
>
> I'm curious why we wouldn't just subtract "elapsed_time" from "delay" at
> the bottom of the while loop to avoid needing this extra check.
Can you elaborate further? I am not sure how this will work since delay is a
timespec
and elapsed time is an instr_time.
Also, in every iteration
On Thu, Jul 11, 2024 at 01:10:25PM -0500, Sami Imseih wrote:
>> I'm curious why we wouldn't just subtract "elapsed_time" from "delay" at
>> the bottom of the while loop to avoid needing this extra check.
>
> Can you elaborate further? I am not sure how this will work since delay is a
> timespec
On Wed, Jul 10, 2024 at 9:16 PM David Rowley wrote:
> Melih and I talked about this in a meeting yesterday evening. I think
> I'm about on the fence about having the IDs in leaf-to-root or
> root-to-leaf. My main concern about which order is chosen is around
> how easy it is to write hierarchical
Per discussion elsewhere [1], I've been looking at $SUBJECT.
I have a very crude Perl hack (too ugly to show yet ;-)) that
produces output along the lines of
Existing code:
/* CREATE STATISTICS */
else if (Matches("CREATE", "STATISTICS", MatchAny))
COMPLETE_WITH("(", "ON");
else
It is broken in master, I just didn’t want to create a separate thread, but it
can be fixed independently. As I remember, the problem is that progress is
tracked for each table in the hierarchy as if the table is processed
separately, without ever setting partitions_total and partitions_done cou
On Wed, Jul 10, 2024 at 01:41:41PM -0500, Nathan Bossart wrote:
> On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote:
>> We went through a ton of permutations of that kind of
>> idea years ago, when it first became totally clear that cross-checks
>> between GUCs do not work nicely if implemen
> On 2024-07-11 Th 5:34 AM, Tatsuo Ishii wrote:
The differences are that the result has an extra space at the end of
line. I am not familiar with Windows and has no idea why this could
happen (I haven't changed the patch set since May 24. The last
succeeded test was on July 9 1
On 03.07.24 17:20, Daniel Gustafsson wrote:
After fiddling a bit with the code and documentation I came up with the
attached version which also makes the testsuite use the list syntax in order to
test it. It's essentially just polish and adding comments with the functional
changes that a) it par
On 07.05.24 11:36, Daniel Gustafsson wrote:
Yeah, that depends on how much version you expect your application to
work on. Still it seems to me that there's value in mentioning that
if your application does not care about anything older than OpenSSL
1.1.0, like PG 18 assuming that this patch is
Nathan Bossart writes:
> On Wed, Jul 10, 2024 at 01:41:41PM -0500, Nathan Bossart wrote:
>> On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote:
>>> We went through a ton of permutations of that kind of
>>> idea years ago, when it first became totally clear that cross-checks
>>> between GUCs
Em qui., 11 de jul. de 2024 às 09:09, David Rowley
escreveu:
> On Wed, 10 Jul 2024 at 02:42, Ashutosh Bapat
> wrote:
> > Observations
> > 1. The numbers corresponding to 10 and 100 partitions are higher when
> > patched. That might be just noise. I don't see any reason why it would
> > impact ne
Hey Richard,
Looking more closely at this example
>select t2.a, count(*) from t t1 left join t t2 on t2.b > 1 group by t2.a
having t2.a is null;
I wonder if the inability to exploit eager aggregation is more based on the
fact that COUNT(*) cannot be decomposed into an aggregation of PARTIAL
COUN
On Thu, Jul 11, 2024, at 2:00 PM, Alexander Lakhin wrote:
> Hello Amit and Hou-San,
>
> 11.07.2024 13:21, Amit Kapila wrote:
> >
> > We don't wait for the xmin to catch up corresponding to this insert
> > and I don't know if there is a way to do that. So, we should move this
> > Insert to after th
On Tue, Apr 16, 2024 at 02:12:19PM +0300, Nazir Bilal Yavuz wrote:
> I am working on using read streams in the CREATE DATABASE command when the
> strategy is wal_log. RelationCopyStorageUsingBuffer() function is used in
> this context. This function reads source buffers then copies them to the
Ple
On Thu, Jul 11, 2024 at 09:35:24PM +0100, Ilya Gladyshev wrote:
> It is broken in master, I just didn’t want to create a separate
> thread, but it can be fixed independently. As I remember, the
> problem is that progress is tracked for each table in the hierarchy
> as if the table is processed sepa
On Thu, Jul 11, 2024 at 01:29:08PM +, Bertrand Drouvot wrote:
> Please find attached a patch to do so (attached as .txt to not perturb the
> cfbot).
+ * Reads in existing statistics file into the shared stats hash (for non fixed
+ * amount stats) or into the fixed amount stats.
Thanks. I hav
On Thu, Jul 11, 2024 at 01:11:05PM +0300, Aleksander Alekseev wrote:
> Thanks, Michael. I prepared a corrected patchset.
A comment about v3-0001.
-* If true, use long segment filenames formed from lower 48 bits of the
-* segment number, e.g. pg_xact/1234. Otherwise, use sh
On Sat, Jul 6, 2024 at 2:35 PM Tom Lane wrote:
> Thomas Munro writes:
> > So I propose to back-patch 101c37cd to those two branches.
>
> +1.
Done.
> I see that there are a boatload of related warnings in older
> branches too; do we want to try to do anything about that? (I doubt
> code changes
On Thu, Jul 11, 2024 at 07:10:58PM +0530, Ashutosh Bapat wrote:
> I think it's just convenient. We do that at multiple places; not exactly
> these functions but functions which fetch relation attributes from cached
> tuples. Given that the tuple is cached and local to the backend, it's not
> too ex
On Wed, Jul 10, 2024 at 02:14:55PM +0900, Michael Paquier wrote:
> +# Only non-superuser roles granted pg_signal_autovacuum_worker are allowed
> +# to signal autovacuum workers. This test uses an injection point located
> +# at the beginning of the autovacuum worker startup.
nitpick: Superuser ro
On Wed, Jul 10, 2024 at 11:52:33PM -0300, Euler Taveira wrote:
> On Wed, Jul 10, 2024, at 7:05 PM, Nathan Bossart wrote:
>> Unfortunately, I think we have to keep this workaround since older minor
>> releases of PostgreSQL don't have the fix.
>
> Hmm. Right.
On second thought, maybe we should jus
Thomas Munro writes:
> On Sat, Jul 6, 2024 at 2:35 PM Tom Lane wrote:
>> I see that there are a boatload of related warnings in older
>> branches too; do we want to try to do anything about that? (I doubt
>> code changes would be in-scope, but maybe adding a -Wno-foo switch
>> to the build flags
Michael Paquier writes:
> On Thu, Jul 11, 2024 at 07:10:58PM +0530, Ashutosh Bapat wrote:
>> I think it's just convenient. We do that at multiple places; not exactly
>> these functions but functions which fetch relation attributes from cached
>> tuples. Given that the tuple is cached and local to
On Sat, Jul 6, 2024 at 5:32 PM Richard Guo wrote:
> Here is a new rebase.
>
> I'm planning to push it next week, barring any objections.
Pushed.
Thanks
Richard
Richard Guo 于2024年7月12日周五 10:30写道：
> On Sat, Jul 6, 2024 at 5:32 PM Richard Guo wrote:
> > Here is a new rebase.
> >
> > I'm planning to push it next week, barring any objections.
>
> Pushed.
>
> Thanks
> Richard
>
Thanks for pushing.
--
Tender Wang
Hi Vignesh. Here are the rest of my comments for patch v20240705-0003.
(Apologies for the length of this post; but it was unavoidable due to
this being the 1st review of a very large large 1700-line patch)
==
src/backend/catalog/pg_subscription.c
1. GetSubscriptionSequences
+/*
+ * Get the
On 7/11/24 23:09, Greg Sabino Mullane wrote:
Thanks for the review. Please find attached a new version with proper
tabs and indenting.
This looks good to me now. +1 overall for the feature.
Regards,
-David
On 7/11/24 14:43, jian he wrote:
On Tue, Jul 9, 2024 at 2:06 PM Andrei Lepikhov wrote:
On 7/2/24 07:25, jian he wrote:
to make sure it's correct, I have added a lot of tests,
Some of this may be contrived, maybe some of the tests are redundant.
Thanks for your job!
I passed through the patch
On 7/11/24 16:18, Richard Guo wrote:
On Fri, Jun 28, 2024 at 10:14 PM Andrei Lepikhov wrote:
I got the point about Memoize over join, but as a join still calls
replace_nestloop_params to replace parameters in its clauses, why not to
invent something similar to find Memoize keys inside specific
Hi David,
Thank you for the patch.
> I think this might just be noise as a result of rearranging code. In
> terms of C code, I don't see any reason for it to be slower. If you
> look at GenerationDelete() (as what is getting called from
> MemoryContextDelete()), it just calls GenerationReset().
On Fri, Jul 12, 2024 at 2:26 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Sat, Jul 6, 2024 at 2:35 PM Tom Lane wrote:
> >> I see that there are a boatload of related warnings in older
> >> branches too; do we want to try to do anything about that? (I doubt
> >> code changes would be in-scop
Thomas Munro writes:
> On Fri, Jul 12, 2024 at 2:26 PM Tom Lane wrote:
>> Thomas Munro writes:
>>> I don't see any on clang 16 in the 12 and 13 branches. Where are you
>>> seeing them?
>> In the buildfarm. "adder" and a bunch of other machines are throwing
>> -Wcast-function-type in about two
On Tue, Jul 9, 2024 at 1:07 PM Michael Paquier wrote:
>
> On Mon, Jul 08, 2024 at 03:59:30PM +0530, Ashutosh Bapat wrote:
> > Before submitting the patch, I looked for all the places which mention
> > AdjustUpgrade or AdjustUpgrade.pm to find places where the new module needs
> > to be mentioned.
Hi,
Since I'd like to understand the skip scan to improve the EXPLAIN output
for multicolumn B-Tree Index[1], I began to try the skip scan with some
queries and look into the source code.
I have some feedback and comments.
(1)
At first, I was surprised to look at your benchmark result because t
On Thu, Jul 11, 2024 at 08:50:57PM -0500, Nathan Bossart wrote:
> I'm not following how this is guaranteed to trigger an autovacuum quickly.
> Shouldn't we set autovacuum_vacuum_insert_threshold to 1 so that it is
> eligible for autovacuum?
You are right, this is not going to influence a faster st
On Thu, Jul 11, 2024 at 7:04 PM Euler Taveira wrote:
>
> On Thu, Jul 11, 2024, at 8:22 AM, Zhijie Hou (Fujitsu) wrote:
>
> The analysis and suggestion look reasonable to me.
> Here is a small patch which does the same.
>
>
> LGTM. However, I would add a comment above the INSERT you moved around to
> @@ -2684,6 +2726,14 @@ ExecEndWindowAgg(WindowAggState *node)
> PlanState *outerPlan;
> int i;
>
> + if (node->buffer != NULL)
> + {
> + tuplestore_end(node->buffer);
> +
> + /* nullify so that release_partition skips the
> tuple
On Thu, Jul 11, 2024 at 5:39 PM David Rowley wrote:
>
> On Wed, 10 Jul 2024 at 02:42, Ashutosh Bapat
> wrote:
> > Observations
> > 1. The numbers corresponding to 10 and 100 partitions are higher when
> > patched. That might be just noise. I don't see any reason why it would
> > impact negatively
On Fri, Jul 05, 2024 at 01:52:31PM +0900, Michael Paquier wrote:
> On Sat, Jun 29, 2024 at 11:13:04PM +0200, Tomas Vondra wrote:
>> I think those are two independent issues - knowing that the snapshot is
>> from the last checkpoint, and knowing that it's correct (not corrupted).
>> And yeah, we sho
Hi Shubham.
Thanks for separating the new BMS 'columns' modification.
Here are my review comments for the latest patch v17-0001.
==
1. src/backend/replication/pgoutput/pgoutput.c
/*
* Columns included in the publication, or NULL if all columns are
* included implicitly. Note that th
84 matches
Mail list logo
