On Tue, 20 Aug 2024 at 08:21, Peter Smith wrote:
>
> On Fri, Aug 16, 2024 at 2:15 PM vignesh C wrote:
> >
>
> Thanks for the review.
>
> >
> > I agree currently there is no test to hit this code. I'm not sure if
> > this is the correct location for the test, should it be included in
> > the 008_d
Hi,
On Fri, Aug 16, 2024 at 12:22 AM Shlok Kyal wrote:
>
> On Wed, 7 Aug 2024 at 11:48, Amit Kapila wrote:
> >
> > On Wed, Aug 7, 2024 at 7:42 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Aug 6, 2024 at 1:12 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Sat, Aug 3, 2024 at 1:21 AM Masa
On Tue, 20 Aug 2024 17:47:57 +0900
Michael Paquier wrote:
> On Mon, Aug 19, 2024 at 02:11:55PM +, Bertrand Drouvot wrote:
> > I made the changes for pg_tblspc in pg_combinebackup.c as the number of
> > occurences
> > are greater that the "pg_wal" ones and we were to define PG_TBLSPC_DIR in
Hi,
On Mon, Jul 01, 2024 at 04:59:25AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Jun 28, 2024 at 08:07:39PM +, Imseih (AWS), Sami wrote:
> > > 46ebdfe164 will interrupt the leaders sleep every time a parallel workers
> > > reports
> > > progress, and we currently don't handle interrup
Hi,
On Tue, Aug 13, 2024 at 11:40:27AM -0500, Nathan Bossart wrote:
> 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 sh
On Tue, Aug 20, 2024 at 1:39 AM Robert Haas wrote:
> On Fri, Aug 16, 2024 at 8:36 AM Amit Langote wrote:
> > So it is possible for the executor to try to run a plan that has
> > become invalid since it was created, so...
>
> I'm not sure what the "so what" here is.
I meant that if the executor h
Heikki Linnakangas writes:
> On 20/08/2024 07:46, Michael Paquier wrote:
>> How about removing it like in the attached to be consistent?
> +1. There's also a prototype for _PG_fini() in fmgr.h, let's remove that
> too.
+1. I think the fmgr.h prototype may have been left there
deliberately to a
On Tue, Aug 20, 2024 at 3:21 AM Robert Haas wrote:
> On Mon, Aug 19, 2024 at 1:52 PM Tom Lane wrote:
> > Robert Haas writes:
> > > But that seems somewhat incidental to what this thread is about.
> >
> > Perhaps. But if we're running into issues related to that, it might
> > be good to set asid
On 2024-08-19 Mo 8:00 AM, Alexander Lakhin wrote:
Hello Andrew,
29.07.2024 13:54, Andrew Dunstan wrote:
On 2024-07-29 Mo 4:00 AM, Alexander Lakhin wrote:
And another interesting fact is that TEMP_CONFIG is apparently
ignored by
`meson test regress/regress`. For example, with temp.config
On 20/08/2024 11:46, 陈宗志 wrote:
I’ve recently started exploring PostgreSQL implementation. I used to
be a MySQL InnoDB developer, and I find the PostgreSQL community feels
a bit strange.
There are some areas where they’ve done really well, but there are
also some obvious issues that haven’t been
On Mon, Aug 19, 2024 at 1:54 PM Jelte Fennema-Nio wrote:
> My point is that the code that breaks, actually wants to be broken in this
> case.
I'll turn this around then and assume for a moment that this is true:
no matter what the use cases are, they all want to be broken for
correctness. If thi
On 2024-Aug-19, Bertrand Drouvot wrote:
> diff --git a/src/include/common/relpath.h b/src/include/common/relpath.h
> index 6f006d5a93..a6cb091635 100644
> --- a/src/include/common/relpath.h
> +++ b/src/include/common/relpath.h
> @@ -33,6 +33,10 @@ typedef Oid RelFileNumber;
> #define TABLESPACE_V
Hi
On Mon, Aug 19, 2024 at 10:12 PM Tom Lane wrote:
>
> We have had multiple instances of code "return"ing out of a PG_TRY,
> so I fully agree that some better way to detect that would be good.
> But maybe we ought to think about static analysis for that.
I have some static analysis scripts for
On Tue, 20 Aug 2024 at 15:48, Jacob Champion
wrote:
> Put another way: for a middlebox on the connection (which may be
> passively observing, but also maybe actively adding new messages to
> the stream), what is guaranteed to remain the same in the protocol
> across a minor version bump? Hopefully
On Tue, Aug 20, 2024 at 9:00 AM Amit Langote wrote:
> I think we'd modify plancache.c to postpone the locking of only
> prunable relations (i.e., partitions), so we're looking at only a
> handful of concurrent modifications that are going to cause execution
> errors. That's because we disallow ma
Maxim Orlov writes:
> So, my point here: installcheck-world doesn't
> work on the current master branch until I explicitly install
> injection_points extension. In my view, it's a bit wired, since
> neither test_decoding, pg_stat_statements or pg_prewarm demand it.
Ugh. The basic issue here is
Dear All,
I would propose a new function like GetXLogInsertRecPtr(), but with some
modifications (please, see the attached patch). The result LSN can be passed to
XLogFLush() safely. I believe, it will not raise an error in any case.
XLogFlush(GetXLogLastInsertEndRecPtr()) will flush (fsync) a
On 20/08/2024 16:48, Jacob Champion wrote:
On Mon, Aug 19, 2024 at 1:54 PM Jelte Fennema-Nio wrote:
My point is that the code that breaks, actually wants to be broken in this case.
I'll turn this around then and assume for a moment that this is true:
no matter what the use cases are, they all
On Tue, Aug 20, 2024 at 11:24 AM Heikki Linnakangas wrote:
> That's not a completely crazy idea, it crossed my mind too. And since we
> already decided to skip protocol number 3.1, how about we jump directly
> to 3.4. That way:
>
> protocol |
> version | PQProtocolVersion()
>
> 2 | 2 (
On Tue, 20 Aug 2024 at 17:46, Robert Haas wrote:
> I personally like this less than both (a) adding a new function and
> (b) redefining the existing function as Jelte proposes. It just seems
> too clever to me.
Agreed, I'm not really seeing a benefit of returning 4 instead of
30004. Both are new
On Tue, Aug 20, 2024 at 11:53 AM Jelte Fennema-Nio wrote:
> On Tue, 20 Aug 2024 at 17:46, Robert Haas wrote:
> > I personally like this less than both (a) adding a new function and
> > (b) redefining the existing function as Jelte proposes. It just seems
> > too clever to me.
>
> Agreed, I'm not
I wrote:
> Ugh. The basic issue here is that "make install-world" doesn't
> install anything from underneath src/test/modules, which I recall
> as being an intentional decision. Rather than poking a hole in
> that policy for injection_points, I wonder if we should move it
> to contrib.
... which
Hi,
On Tue, Aug 20, 2024 at 10:15:44AM -0400, Alvaro Herrera wrote:
> On 2024-Aug-19, Bertrand Drouvot wrote:
>
> > diff --git a/src/include/common/relpath.h b/src/include/common/relpath.h
> > index 6f006d5a93..a6cb091635 100644
> > --- a/src/include/common/relpath.h
> > +++ b/src/include/common/
Hi,
On Tue, Aug 20, 2024 at 09:30:48PM +0900, Yugo Nagata wrote:
> Should be the follwing also rewritten using sizeof(PG_REPLSLOT_DIR)?
>
>struct stat statbuf;
> charpath[MAXPGPATH * 2 + 12];
>
>
Yeah, done in v3 that I just shared up-thread (also removed the macros from
the co
Hi Michael,
Thanks for starting this thread. I've also spent a bit time on this after
reading your first thread on this issue [1]
Michael Harris , 20 Ağu 2024 Sal, 08:52 tarihinde şunu
yazdı:
> The problem is that giving an ANALYZE command targeting a partitioned table
> causes it to update stat
Hi,
On Tue, Aug 20, 2024 at 12:06:52PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Aug 20, 2024 at 05:41:48PM +0900, Michael Paquier wrote:
> > On Tue, Aug 20, 2024 at 11:10:46AM +0530, Ashutosh Bapat wrote:
> > > Since these are all related changes, doing them at once might make it
> > > fa
Melih Mutlu , 20 Ağu 2024 Sal, 19:26 tarihinde şunu
yazdı:
> Hi Michael,
>
> Thanks for starting this thread. I've also spent a bit time on this after
> reading your first thread on this issue [1]
>
Forgot to add the reference [1]
[1]
https://www.postgresql.org/message-id/cadofcaxvbd0ygp_eac9chmz
On 2024-Aug-20, Tom Lane wrote:
> We do, however, need to preserve the property that installcheck
> works after install-world. I'm starting to think that maybe
> the 041 test should be hacked to silently skip if it doesn't
> find injection_points available.
Yeah, I like this option. Injection p
On Tue, Aug 20, 2024 at 9:02 AM Robert Haas wrote:
> Yes. And the major * 1 + minor convention is used in other places
> already, for PG versions, so it might already be familiar to some
> people.
>
I'm wondering why we are indicating that minor versions of the protocol are
even a real thing
On Tue, Aug 20, 2024 at 12:42 PM David G. Johnston
wrote:
> I'm wondering why we are indicating that minor versions of the protocol are
> even a real thing.
Because that concept is already a part of the existing wire protocol.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, 19 Aug 2024 16:43:09 +0800
px shi wrote:
> Hi, hackers,
>
> I've recently encountered an issue where a standby crashes when
> reconnecting to a new primary after a switchover under certain conditions.
> Here's a procedure of the crash scenario:
>
>
> 1) We have three instances: one pri
On Tue, Aug 20, 2024 at 10:07:32AM +0200, Jelte Fennema-Nio wrote:
> On Thu, 15 Aug 2024 at 23:12, Bruce Momjian wrote:
> > Third, I would like to show a more specific example to clarify what is
> > being considered above. If we look at MAX(), we can have FDWs return
> > the max for each FDW, and
On Tue, Aug 20, 2024 at 04:46:54PM +0300, Heikki Linnakangas wrote:
> There are pros and cons. With direct I/O, you cannot take advantage of the
> kernel page cache anymore, so it becomes important to tune shared_buffers
> more precisely. That's a downside: the system requires more tuning. For many
On Tue, 20 Aug 2024 at 18:42, David G. Johnston
wrote:
> v18 libpq-based clients, if they attempt to connect using v4 and fail, will
> try again using the v3 connection. That will retain status quo behavior when
> something like a connection pooler doesn't understand the new reality.
Having co
On Tue, Aug 20, 2024 at 9:44 AM Robert Haas wrote:
> On Tue, Aug 20, 2024 at 12:42 PM David G. Johnston
> wrote:
> > I'm wondering why we are indicating that minor versions of the protocol
> are even a real thing.
>
> Because that concept is already a part of the existing wire protocol.
>
>
Righ
On Tue, Aug 20, 2024 at 7:26 AM Jelte Fennema-Nio wrote:
> In practical terms I think that means for a minor version bump the
> format of the StartupMessage cannot be changed. Changing anything else
> is fair game for a minor protocol version bump.
I may be in a tiny minority here, but when I com
On Tue, 20 Aug 2024 at 18:50, Bruce Momjian wrote:
> Okay, so we can do MAX easily, and AVG if the count can be represented
> as the same data type as the sum? Is that correct? Our only problem is
> that something like AVG(interval) can't use an array because arrays have
> to have the same data
On Tue, Aug 20, 2024 at 1:02 PM David G. Johnston
wrote:
> So basically my proposal amounted to making every update a "major version
> update" and changing the behavior surrounding NegotiateProtocolVersion so it
> applies to major version differences. I'll stand by that change in
> definition.
On Tue, Aug 20, 2024 at 10:03 AM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Tue, Aug 20, 2024 at 7:26 AM Jelte Fennema-Nio
> wrote:
> > In practical terms I think that means for a minor version bump the
> > format of the StartupMessage cannot be changed. Changing anything else
On Tue, Aug 20, 2024 at 8:24 AM Heikki Linnakangas wrote:
> > Put another way: for a middlebox on the connection (which may be
> > passively observing, but also maybe actively adding new messages to
> > the stream), what is guaranteed to remain the same in the protocol
> > across a minor version b
On Tue, Aug 20, 2024 at 10:31 AM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> If we decide we can't, then so be it -- things will
> break either way -- but it's still strange to me that we'd be okay
> with literally zero forward compatibility and still call that a "minor
> version".
On Tue, Aug 20, 2024 at 10:42 AM David G. Johnston
wrote:
> Semantic versioning guidelines are not something we are following, especially
> here.
I understand; the protocol is ours, and we'll do whatever we do in the
end. I'm claiming that we can choose to provide semantics, and if we
do, those
On Tue, Aug 20, 2024 at 10:46 AM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Tue, Aug 20, 2024 at 10:42 AM David G. Johnston
> wrote:
> > Semantic versioning guidelines are not something we are following,
> especially here.
>
> I understand; the protocol is ours, and we'll do wh
I wrote:
> Michael Paquier writes:
>> It looks like %replace_line expects all its elements to have one space
>> between each token, still this is not enforced with a check across its
>> hardcoded elements?
> Yeah, I was wondering about that. I wouldn't do it exactly like
> that, but with a check
On 2024-Aug-19, Andrey M. Borodin wrote:
> > On 5 Jul 2024, at 23:18, Andrey M. Borodin wrote:
> >
> > Alvaro, please find attached the test.
> > I’ve addressed some Michael’s comments in a nearby thread: removed
> > extra load, made injection point names lowercase, fixed some grammar
> > issues
On Tue, Aug 20, 2024 at 1:52 AM Michael Harris wrote:
> 2. The existing ANALYZE command has the following structure:
>
> ANALYZE [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
>
> It would be easiest to add ONLY as another option, but that
> doesn't look quite
> right to me
On Tue, Aug 20, 2024 at 07:03:56PM +0200, Jelte Fennema-Nio wrote:
> On Tue, 20 Aug 2024 at 18:50, Bruce Momjian wrote:
> > Okay, so we can do MAX easily, and AVG if the count can be represented
> > as the same data type as the sum? Is that correct? Our only problem is
> > that something like AV
On Tue, Aug 13, 2024 at 03:22:27PM +0300, Nazir Bilal Yavuz wrote:
> 2- collect_corrupt_items()
>
> This one is more complicated. The read stream callback function loops
> until it finds a suitable block to read. So, if the callback returns
> an InvalidBlockNumber; it means that the stream process
On Tue, Aug 20, 2024 at 02:12:25PM +0530, Amit Kapila wrote:
> +1 for Nathan's version. It is quite close to the previous version,
> for which we haven't heard any complaints since they were introduced.
Committed, thanks.
--
nathan
On Mon, Aug 5, 2024 at 4:16 AM Alexander Korotkov wrote:
> I've revised the patchset. First of all, I've re-ordered the patches.
>
> 0001-0002 (former 0002-0003)
> Comprises hash_search_with_hash_value() function and its application
> to avoid full hash iteration in InvalidateAttoptCacheCallback(
> As it looks like we have a consensus that reducing the number of interrupts
> also
> makes sense, I just provided a rebase version of the 1 Hz version (see [0],
> that
> also makes clear in the doc that the new field might show slightly old
> values).
That makes sense. However, I suspect the
On Tue, 20 Aug 2024 at 19:02, David G. Johnston
wrote:
> So basically my proposal amounted to making every update a "major version
> update" and changing the behavior surrounding NegotiateProtocolVersion so it
> applies to major version differences. I'll stand by that change in
> definition.
On Tue, 20 Aug 2024 at 19:31, Jacob Champion
wrote:
> It's applicable to the use case I was talking about with Jelte. A
> libpq client dropping down to the socket level is relying on
> (implicit, currently undocumented/undecided, possibly incorrect!)
> intermediary guarantees that the protocol pro
On 14/08/2024 16:54, Arseny Sher wrote:
On 8/13/24 06:35, Amit Kapila wrote:
On Mon, Aug 12, 2024 at 3:43 PM Arseny Sher wrote:
Sorry for the poor formatting of the message above, this should be
better:
Hey. Currently synchronous_commit is disabled for logical apply worker
on the ground th
I've combined all the current proposed changes into one patch. I've also
introduced signed versions of the negation functions into int.h to avoid
relying on multiplication.
--
nathan
>From 2364ba4028f879a22b9f69f999aee3ea9c013ec0 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 20 Aug 2
On Tue, Aug 20, 2024 at 12:55 PM Jelte Fennema-Nio wrote:
> Another way of describing this guarantee: If a client connects using
> 3.8 and configures no protocol parameters, the client needs to handle
> anything 3.8 specific that the handshake requires (such as longer
> cancel token). But then aft
Hi. I noticed chipmunk is failing in configure:
checking whether the C compiler works... no
configure: error: in `/home/pgbfarm/buildroot/HEAD/pgsql.build':
configure: error: C compiler cannot create executables
You may want to give it a look.
Thanks!
--
Álvaro Herrera PostgreSQL Deve
On Thu, 25 Jul 2024 at 08:45, Anthonin Bonnefoy
wrote:
> +1 keeping this as a separate command and using \bind_named. \bind has
> a different behaviour as it also parses the query so keeping them as
> separate commands would probably avoid some confusion.
+1 on naming it \bind_named
@Anthonin ar
On Tue, 20 Aug 2024 at 23:48, Jacob Champion
wrote:
> That guarantee (if adopted) would also make it possible for my use
> case to proceed correctly, since a libpq client can still speak 3.0
> packets on the socket safely.
Not necessarily (at least not how I defined it). If a protocol
parameter h
On Tue, Aug 20, 2024 at 09:05:54AM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
>> +1. There's also a prototype for _PG_fini() in fmgr.h, let's remove that
>> too.
>
> +1. I think the fmgr.h prototype may have been left there
> deliberately to avoid breaking extension code, but it's past
Hi! Thank you very much for your review! Sorry for my late response I
was overwhelmed by tasks.
On 16.08.2024 14:12, jian he wrote:
On Thu, Aug 15, 2024 at 4:49 PM Alena Rybakina
wrote:
Hi!
I've applied all the v5 patches.
0002 and 0003 have white space errors.
+
+Number of
We check it there: "tabentry->vacuum_ext.type != type". Or were you
talking about something else?
On 19.08.2024 12:32, jian he wrote:
in pg_stats_vacuum
if (type == PGSTAT_EXTVAC_INDEX || type == PGSTAT_EXTVAC_HEAP)
{
Oidrelid = PG_GETARG_OID(1);
I think you've counted the above system tables from the database, but
I'll double-check it. Thank you for your review!
On 19.08.2024 19:28, Ilia Evdokimov wrote:
Are you certain that all tables are included in
`pg_stat_vacuum_tables`? I'm asking because of the following:
SELECT count(*) FROM
On Wed, Aug 21, 2024 at 9:48 AM Alvaro Herrera wrote:
> Hi. I noticed chipmunk is failing in configure:
>
> checking whether the C compiler works... no
> configure: error: in `/home/pgbfarm/buildroot/HEAD/pgsql.build':
> configure: error: C compiler cannot create executables
One of the runs show
On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
> I like trying to use ONLY somehow.
Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
or as a table modifier like gram.y's extended_relation_expr?
Making it a command option means that the option would apply to all
tables liste
David Rowley writes:
> On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
>> I like trying to use ONLY somehow.
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_relation_expr?
> Making it a command option means that the option
On Tue, Aug 20, 2024 at 12:10:08PM -0400, Tom Lane wrote:
> ... which would also imply writing documentation and so forth,
> and it'd mean that injection_points starts to show up in end-user
> installations. (That would happen with the alternative choice of
> hacking install-world to include src/t
On Tue, Aug 20, 2024 at 02:37:34PM -0400, Alvaro Herrera wrote:
> OK, I've made some minor adjustments and pushed. CI seemed OK for me,
> let's see what does the BF have to say.
I see that you've gone the way with the SQL function doing a load().
Would it be worth switching the test to rely on th
On 2024-Aug-21, Michael Paquier wrote:
> I see that you've gone the way with the SQL function doing a load().
> Would it be worth switching the test to rely on the two macros for
> load and caching instead? I've mentioned that previously but never
> got down to present a patch for the sake of thi
Hi!
On Thu, Aug 15, 2024 at 10:13 PM Alena Rybakina
wrote:
> On 07.08.2024 04:11, Alexander Korotkov wrote:
> > On Mon, Aug 5, 2024 at 11:24 PM Alena Rybakina
> > wrote:
> >> Ok, thank you for your work)
> >>
> >> I think we can leave only the two added libraries in the first patch,
> >> others
On 2023-Oct-27, Ryo Matsumura (Fujitsu) wrote:
> Hi hackers,
>
> I found that 'make update-po' for PGXS does not work.
> Even if execute 'make update-po', but xx.po.new is not generated.
> I don't test and check for meson build system, but I post it tentatively.
>
> I attached patch and test set
Yugo Nagata 于2024年8月21日周三 00:49写道：
>
>
> > Is s1 a cascading standby of s2? If otherwise s1 and s2 is the standbys
> of
> > the primary server respectively, it is not surprising that s2 has
> progressed
> > far than s1 when the primary fails. I believe that this is the case you
> should
> > use p
On 8/6/24 4:15 AM, Zhijie Hou (Fujitsu) wrote:
Thanks for the idea! I thought about few styles based on the suggested format,
what do you think about the following ?
Thanks for proposing formats. Before commenting on the specifics, I do
want to ensure that we're thinking about the following f
Avoid unnecessary form and deform tuple.
In the TPCH test, HashJoin speed up to ~2x.
diff --git a/src/backend/executor/nodeHash.c b/src/backend/executor/nodeHash.c
index 61480733a1..2dad0c8a55 100644
--- a/src/backend/executor/nodeHash.c
+++ b/src/backend/executor/nodeHash.c
@@ -1627,6 +1627,23 @
On Tue, Aug 20, 2024 at 6:53 PM David Rowley wrote:
> On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
> > I like trying to use ONLY somehow.
>
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_relation_expr?
The table modifier
Hi Vignesh, Here are my only review comments for the latest patch set.
v20240820-0003.
nit - missing period for comment in FetchRelationStates
nit - typo in function name 'ProcessSyncingTablesFoSync'
==
Kind Regards,
Peter Smith.
Fujitsu Australia
diff --git a/src/backend/replication/logical
On Wednesday, August 21, 2024 9:33 AM Jonathan S. Katz
wrote:
> On 8/6/24 4:15 AM, Zhijie Hou (Fujitsu) wrote:
>
> > Thanks for the idea! I thought about few styles based on the suggested
> > format, what do you think about the following ?
>
> Thanks for proposing formats. Before commenting on
On 2024-Aug-20, Jehan-Guillaume de Rorthais wrote:
> I'm back on this issue as well. I start poking at this patch to review it,
> test it, challenge it and then report here.
>
> I'll try to check if some other issues might have lost/forgot on they way as
> well.
Thanks, much appreciated, looking
On Tue, Aug 20, 2024 at 4:45 PM Zhijie Hou (Fujitsu)
wrote:
>
> Here are the remaining patches.
>
> 0001 adds additional doc to explain the log format.
Thanks for the patch. Please find few comments on 001:
1)
+Key (column_name, ...)=(column_name, ...);
existing local tuple (column_name, ...)=(c
On Tue, Aug 20, 2024 at 08:13:12PM -0400, Alvaro Herrera wrote:
> I don't understand what do the inj_stats_enabled stuff have to do with
> this patch. I suspect it's a git operation error, ie., you seem to have
> squashed two different things together.
Sorry, I should have split that for clarity
On Tue, Aug 20, 2024 at 5:55 PM Masahiko Sawada wrote:
>
> On Fri, Aug 16, 2024 at 12:22 AM Shlok Kyal wrote:
> >
>
> Thank you for testing the patch!
>
> I'm slightly hesitant to add a test under src/test/subscription since
> it's a bug in ReorderBuffer and not specific to logical replication.
>
If this isn't in commitfest already, please add it there.
On Tue, Aug 20, 2024 at 9:58 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Tue, Aug 20, 2024 at 12:06:52PM +, Bertrand Drouvot wrote:
> > Hi,
> >
> > On Tue, Aug 20, 2024 at 05:41:48PM +0900, Michael Paquier wrote:
> > > On Tue, Aug 20, 20
Hi,
On Wed, Aug 21, 2024 at 10:14:20AM +0530, Ashutosh Bapat wrote:
> If this isn't in commitfest already, please add it there.
>
Done in [0].
[0]: https://commitfest.postgresql.org/49/5193/
Thanks!
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon W
Dear Hou,
Thanks for updating the patch! I think the patch is mostly good.
Here are minor comments.
0001:
01.
```
+
+LOG: conflict detected on relation "schemaname.tablename":
conflict=conflict_type
+DETAIL: detailed explaination.
...
+
```
I don't think the label is correct. label should b
On Tue, Aug 20, 2024 at 4:45 PM Zhijie Hou (Fujitsu)
wrote:
>
> Here are the remaining patches.
>
> 0001 adds additional doc to explain the log format.
> 0002 collects statistics about conflicts in logical replication.
>
0002 has not changed since I last reviewed it. It seems all my old
comments
A USING clause when altering the type of a generated column does not
make sense. It would write the output of the USING clause into the
converted column, which would violate the generation expression.
This patch adds a check to error out if this is specified.
There was a test for this, but t
On Wed, Aug 21, 2024 at 2:25 AM Heikki Linnakangas wrote:
>
> On 14/08/2024 16:54, Arseny Sher wrote:
> > On 8/13/24 06:35, Amit Kapila wrote:
> >> On Mon, Aug 12, 2024 at 3:43 PM Arseny Sher wrote:
> >>>
> >>> Sorry for the poor formatting of the message above, this should be
> >>> better:
> >>>
On Wed, Aug 21, 2024 at 12:46:31PM +0900, Michael Paquier wrote:
> Sorry, I should have split that for clarity (one patch for the GUC,
> one to change the test to use CACHED/LOAD). It is not an error
> though: if we don't have a controlled way to disable the stats of the
> module, then the test wo
On 21/08/2024 01:42, Thomas Munro wrote:
On Wed, Aug 21, 2024 at 9:48 AM Alvaro Herrera wrote:
Hi. I noticed chipmunk is failing in configure:
checking whether the C compiler works... no
configure: error: in `/home/pgbfarm/buildroot/HEAD/pgsql.build':
configure: error: C compiler cannot creat
Here are some review comments for the v19-0001 docs patch.
The content seemed reasonable, but IMO it should be presented quite differently.
1. Use sub-sections
I expect this logical replication "Conflicts" section is going to
evolve into something much bigger. Surely, it's not going to be
When testing the json_table function, it was discovered that specifying FORMAT
JSON in the column definition clause and applying this column to the
JSON_OBJECT function results in an output that differs from Oracle's output.
The sql statement is as follows:
SELECT JSON_OBJECT('config' VALUE c
On Mon, Aug 12, 2024 at 11:01 AM John Naylor wrote:
>
> Extra explicitness might be good. "Response time" seems like a
> networking concept, so possibly ", in turn slowing down INSERT/UPDATE
> statements." I'm inclined to commit that way in a couple days, barring
> further comments.
This is done.
On Tue, 20 Aug 2024 at 02:14, Kirill Reshke wrote:
>
>
> == Major suggestions.
>
> 1) At first glance, working with this IVM/IMMV infrastructure feels
> really unintuitive about what servers actually do for query execution.
> I do think It will be much better for user experience to add more
> EXPL
On Mon, 19 Aug 2024 at 19:10, Tom Lane wrote:
> src/test/recovery/README points out that
>
> Also, to use "make installcheck", you must have built and installed
> contrib/pg_prewarm, contrib/pg_stat_statements and contrib/test_decoding
> in addition to the core code.
>
> I suspect this need
On Tue, Aug 20, 2024 at 9:03 AM John Naylor wrote:
> This is done.
Cool! Thanks John and Robert! :)
-J.
CFBot reported some failures, so I have attached the rebased patch set v9*.
I'm hopeful the majority of these might be pushed to avoid more rebasing...
==
Kind Regards,
Peter Smith.
Fujitsu Australia
v9-0001-Add-quotes-for-GUCs-bool.patch
Description: Binary data
v9-0005-Add-quotes-for-GU
On Tue, 20 Aug 2024 at 07:52, Michael Harris wrote:
> 1. Would such a feature be welcomed? Are there any traps I might not
> have thought of?
I think this sounds like a reasonable feature.
> 2. The existing ANALYZE command has the following structure:
>
> ANALYZE [ ( option [, ...] ) ]
Le dimanche 21 juillet 2024, 07:39:13 UTC+2 Tom Lane a écrit :
> Fujii Masao writes:
> >> Le mercredi 6 mars 2024, 20:28:44 CET Stephen Frost a écrit :
> >>> I agree that this would generally be a useful thing to have.
>
Sorry for the late reply, as I was not available during the late summer.
>
On Thu, 15 Aug 2024 at 23:12, Bruce Momjian wrote:
> Third, I would like to show a more specific example to clarify what is
> being considered above. If we look at MAX(), we can have FDWs return
> the max for each FDW, and the coordinator can chose the highest value.
> This is the patch 1 listed
On Wed, 7 Aug 2024 18:50:10 -0400
Alvaro Herrera wrote:
> On 2024-Jul-26, Tender Wang wrote:
>
> > Junwang Zhao 于2024年7月26日周五 14:57写道：
> >
> > > There is a bug report[0] Tender comments might be the same issue as
> > > this one, but I tried Alvaro's and mine patch, neither could solve
> > > th
1 - 100 of 120 matches
Mail list logo
