On 29/08/2024 04:06, Alvaro Herrera wrote:
I have had many a chance to visit english.stackexchange.net on
account of something I read in pgsql lists or code comments.
I see what you did there :-).
Committed, with "which see". Thanks everyone!
--
Heikki Linnakangas
Neon (https://neon.tech)
On 22.08.24 10:49, Peter Eisentraut wrote:
On 22.08.24 09:59, Yugo NAGATA wrote:
Although ERRCODE_INVALID_TABLE_DEFINITION is used for en error on
changing
type of inherited column, I guess that is because it prevents from
breaking
consistency between inherited and inheriting tables as a resul
On Wed, Aug 28, 2024 at 3:14 AM Jeff Davis wrote:
>
> On Mon, 2024-08-26 at 14:18 -0700, Jeff Davis wrote:
> > 0001 implementation issues:
> >
> > * We need default implementations for AMs that don't implement the
> > new
> > APIs, so that the AM will still function even if it only defines the
> >
On Tue, Aug 27, 2024 at 12:51 PM Shirisha Shirisha
wrote:
>
> Hello hackers,
>
> This is an attempt to resurrect the thread [1] to throttle WAL inserts
> before the point of commit.
>
> Background:
>
> Transactions on commit, wait for replication and make sure WAL is
> flushed up to commit lsn on
On Mon, Aug 26, 2024 at 11:26 AM Alexander Korotkov
wrote:
>
> On Mon, Aug 26, 2024 at 9:37 AM Andrei Lepikhov wrote:
> > On 25/8/2024 23:22, Alexander Korotkov wrote:
> > > On Sun, Aug 25, 2024 at 10:21 PM Alexander Korotkov
> > >>> (This Assert is introduced by c14d4acb8.)
> > >>
> > >> Thank y
On Wed, Aug 28, 2024 at 1:25 AM Bertrand Drouvot
wrote:
>
> On Mon, Aug 26, 2024 at 07:05:27PM +0530, Amit Kapila wrote:
> > On Thu, Aug 22, 2024 at 5:56 PM Bertrand Drouvot
> > wrote:
> > >
> > > 2. The SnapBuildOnDisk and SnapBuild structs are now exposed to public.
> > > Means
> > > we should
On Thu, Aug 29, 2024 at 2:31 AM John H wrote:
>
> Hi Amit,
>
> On Mon, Aug 26, 2024 at 11:00 PM Amit Kapila wrote:
> > I wanted a simple test where in the first case you use
> > synchronous_standby_names = 'ANY 3 (A,B,C,D,E)' and in the second case
> > use standby_slot_names = A_slot, B_slot, C_s
Usually I see printtup in the perf-report with a noticeable ratio. Take
"SELECT * FROM pg_class" for example, we can see:
85.65% 3.25% postgres postgres [.] printtup
The high level design of printtup is:
1. Used a pre-allocated StringInfo DR_printtup.buf to store data for
each tuples.
Hi,
On Thu, Aug 29, 2024 at 02:51:36PM +0530, Amit Kapila wrote:
> On Wed, Aug 28, 2024 at 1:25 AM Bertrand Drouvot
> wrote:
> >
> > On Mon, Aug 26, 2024 at 07:05:27PM +0530, Amit Kapila wrote:
> > > On Thu, Aug 22, 2024 at 5:56 PM Bertrand Drouvot
> > > wrote:
> > > >
> > > > 2. The SnapBuildOn
On Wed, Aug 28, 2024 at 8:46 PM Nazir Bilal Yavuz wrote:
>
> Also, I think TEST 110 and 170 do not look correct to me. In the
> current way, we do not pass PG_TEST_EXTRA to the make command.
>
> 110 should be:
> 'cd $XID_MODULE_DIR && PG_TEST_EXTRA=xid_wraparound make check'
> instead of 'PG_TEST_
On Fri, Aug 23, 2024 at 10:39 AM shveta malik wrote:
>
> Please find issues which need some thoughts and approval for
> time-based resolution and clock-skew.
>
> 1)
> Time based conflict resolution and two phase transactions:
>
> Time based conflict resolution (last_update_wins) is the one
> resol
Hi Michael,
Michael Harris , 23 Ağu 2024 Cum, 13:01 tarihinde şunu
yazdı:
> V2 of the patch is attached.
>
Thanks for updating the patch. I have a few more minor feedbacks.
-ANALYZE [ ( option [, ...] )
> ] [ table_and_columns [, ...] ]
> +ANALYZE [ ( option [, ...] )
> ] [ [ ONLY ] table_and_c
On Thu, 29 Aug 2024 at 21:40, Andy Fan wrote:
>
>
> Usually I see printtup in the perf-report with a noticeable ratio.
> Part of the slowness is caused by "memcpy", "strlen" and palloc in
> outfunction.
Yeah, it's a pretty inefficient API from a performance point of view.
> My high level propos
On Wed, Aug 28, 2024 at 12:24 AM Thomas Munro wrote:
> 2. I tested against LLVM 10-18, and found that 10 and 11 lack some
> needed symbols. So I just hid this code from them. Even though our
> stable branches support those and even older versions, I am not sure
> if it's worth trying to do some
On Wed, Aug 28, 2024 at 10:26 PM Richard Guo wrote:
> Yeah, I'm concerned about this too. In addition to the inaccuracies
> in aggregation estimates, our estimates for joins are sometimes not
> very accurate either. All this are likely to result in regressions
> with eager aggregation in some ca
Our tool have detected that postgre in the version of REL9_6_18~ REL9_6_24
may also affected by the vulnerability CVE-2022-2625. The vulnerability
database does not include these versions and you may not fix it in the
REL9_6 branch. Is there a need to backport the patch of CVE-2022-2625?
Hello Thomas,
29.08.2024 01:16, Thomas Munro wrote:
Yeah. That's quite interesting, and must destabilise that
simple-minded demo. I'm curious to know exactly what contention is
causing that (about 3/4 of a millisecond that I don't see and now I
want to know what it's waiting for), but it's a v
> On 29 Aug 2024, at 14:54, James Watt wrote:
>
> Our tool have detected that postgre in the version of REL9_6_18~ REL9_6_24
> may also affected by the vulnerability CVE-2022-2625. The vulnerability
> database does not include these versions and you may not fix it in the REL9_6
> branch. Is
On Wed, Aug 28, 2024 at 11:38 PM Tender Wang wrote:
> I upload EXPLAIN(COSTS ON, ANALYZE) test to [1].
> I ran the same query three times, and I chose the third time result.
> You can check 19_off_explain.out and 19_on_explain.out.
So, in 19_off_explain.out, we got this:
-> Finalize Gr
On Thu, Aug 29, 2024 at 3:44 PM Bertrand Drouvot
wrote:
>
> Yeah that's fair. And now I'm wondering if we need an extra module. I think
> we could "simply" expose 2 new functions in core, thoughts?
>
> > > What do you think? Did you have something else in mind?
> > >
> >
> > On similar lines, we c
On Sat, Aug 24, 2024 at 5:31 AM Thomas Munro wrote:
> On Thu, Aug 22, 2024 at 7:31 PM Mats Kindahl wrote:
> > The alternate version proposed by Nazir allows you to deide which
> interface to use.
> > Reverting the patch entirely would also solve the problem.
>
After digging through the code a l
Hi,
Thanks for looking into this.
On Fri, Aug 23, 2024 at 5:03 AM John H wrote:
>
> For a motivation aspect I can see this being useful
> synchronous_replicas if you have commit set to flush mode.
In synchronous replication setup, until standby finishes fetching WAL
from the archive, the commit
On Thu, Aug 29, 2024 at 8:15 PM Peter Eisentraut wrote:
>
>
> > drop table if exists comment_test cascade;
> > CREATE TABLE comment_test (
> >id int,
> >positive_col int GENERATED ALWAYS AS (22) CHECK (positive_col > 0),
> >positive_col1 int GENERATED ALWAYS AS (22) stored CHECK (pos
On Sat, Aug 24, 2024 at 2:02 AM Robert Haas wrote:
>
> On Wed, Aug 21, 2024 at 7:08 AM Amul Sul wrote:
> []
> Then the result verifies. But I feel like we should have some test
> cases that do this kind of stuff so that there is automated
> verification. In fact, the current patch seems to ha
Hello,
This patch was a bit discussed on [1], and with more details on [2]. It
introduces four new columns in pg_stat_all_tables:
* parallel_seq_scan
* last_parallel_seq_scan
* parallel_idx_scan
* last_parallel_idx_scan
and two new columns in pg_stat_all_indexes:
* parallel_idx_scan
* last_para
Hi,
On Thu, Aug 29, 2024 at 06:33:19PM +0530, Bharath Rupireddy wrote:
> On Thu, Aug 29, 2024 at 3:44 PM Bertrand Drouvot
> wrote:
> >
> > That's right. I think this one would be simply enough to expose one or two
> > functions in core too (and probably would not need an extra module).
>
> +1 fo
On Thu, Aug 29, 2024 at 02:11:22PM +0900, Michael Paquier wrote:
> Okay, here is a v2 of the patch using this name for the function.
LGTM
--
nathan
On Thu, Aug 29, 2024 at 01:55:27AM -0400, Tom Lane wrote:
> Thomas Munro writes:
>> The fix I propose to commit shortly is just the first of those new
>> lines, to homogenise the initial state. See attached. The previous
>> idea works too, I think, but this bigger hammer is more obviously
>> rem
On Thu, Aug 29, 2024 at 03:44:45PM +0900, Michael Paquier wrote:
> On Tue, Aug 27, 2024 at 04:01:58PM -0500, Nathan Bossart wrote:
>> My current thinking is that it would be better to disallow marking
>> partitioned tables as LOGGED/UNLOGGED and continue to have users explicitly
>> specify what the
On 8/23/24 12:51, Frédéric Yhuel wrote:
On 8/23/24 12:02, Rafia Sabih wrote:
On the other hand, this got me thinking about the purpose of this
space information.
If we want to understand that there's still some space for the tuples
in a page, then using PageGetExactFreeSpace is not doing ju
Hi,
This is a new patch which:
* fixes some typos
* changes the execgather / execgathermerge code so that the stats are
accumulated in EState and inserted in pg_stat_database only once, during
ExecutorEnd
* adds tests (very ugly, but I could get the parallel plan to be stable
across make chec
David Rowley writes:
> [ redesign I/O function APIs ]
> I had planned to work on this for PG18, but I'd be happy for some
> assistance if you're willing.
I'm skeptical that such a thing will ever be practical. To avoid
breaking un-converted data types, all the call sites would have to
support bo
On Thu, Aug 29, 2024 at 8:11 PM Noah Misch wrote:
>
> On Tue, Aug 20, 2024 at 11:59:45AM +0300, Heikki Linnakangas wrote:
> > My order of preference is: 2, 1, 3.
>
> I kept tuple locking responsibility in heapam.c. That's simpler and better
> for modularity, but it does mean we release+acquire af
On Aug 27, 2024, at 22:24, Craig Ringer wrote:
> `pg_config` only cares about compile-time settings, so I would not
> expect its output to change.
Right, of course that’s its original purpose, but extensions depend on it to
determine where to install extensions. Not just PGXS, but also pgrx and
On 2024-08-28 We 5:53 PM, Mark Murawski wrote:
Hi Hackers!
This would be version v1 of this feature
Basically, the subject says it all: pl/pgperl Patch for being able to
tell which function you're in.
This is a hashref so it will be possible to populate new and exciting
other details in the
Hello Hackers,
I’ve attached a patch to start adding SQL:2023 JSON simplified
accessor support. This allows accessing JSON or JSONB fields using dot
notation (e.g., colname.field.field...), similar to composite types.
Currently, PostgreSQL uses nonstandard syntax like colname->x->y for
JSON and J
Hi all,
Please find attached the patch that re-enables
support for sequences within the pgstattuple extension.
I have also included the necessary test cases for
sequences, implemented in the form of regress tests.
Here is the commitfest link for the same -
https://commitfest.postgresql.org/49/5215
On 8/29/24 11:56, Andrew Dunstan wrote:
On 2024-08-28 We 5:53 PM, Mark Murawski wrote:
Hi Hackers!
This would be version v1 of this feature
Basically, the subject says it all: pl/pgperl Patch for being able to
tell which function you're in.
This is a hashref so it will be possible to popu
On Wed, Aug 28, 2024 at 9:25 AM Robert Haas wrote:
> On Tue, Aug 27, 2024 at 3:04 PM Tom Lane wrote:
> I kind of had that reaction too initially, but I think that was mostly
> because "Primitive Index Scans" seemed extremely unclear. I think
> "Index Searches" is pretty comprehensible, honestly.
On Thu, Aug 29, 2024 at 10:17:57PM +0530, Ayush Vatsa wrote:
> Please find attached the patch that re-enables
> support for sequences within the pgstattuple extension.
> I have also included the necessary test cases for
> sequences, implemented in the form of regress tests.
Thanks. Robert, do you
On Thu, Aug 29, 2024 at 12:36:35PM -0500, Nathan Bossart wrote:
> +select * from pgstattuple('serial');
> + table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count |
> dead_tuple_len | dead_tuple_percent | free_space | free_percent
> +---+-+---+-
Hi
út 27. 8. 2024 v 16:52 odesílatel Laurenz Albe
napsal:
> time""On Tue, 2024-08-27 at 08:52 +0200, Pavel Stehule wrote:
> > I can throw 200KB from another 300KB patch set which can be better for
> review, but it
> > can be harder to maintain this patch set. I'll try it, and I'll send a
> reduc
> I'm concerned that some of this might be platform-dependent and make the
> test unstable. Perhaps we should just select count(*) here.
> Sure enough, the CI testing for 32-bit is failing here [0].
Thanks for catching that! I wasn't aware of this earlier.
> I think we should be a bit more descri
út 27. 8. 2024 v 13:57 odesílatel Jim Jones
napsal:
>
>
> On 26.08.24 16:59, Pavel Stehule wrote:
> >
> > 1. what about behaviour of NO INDENT - the implementation is not too
> > old, so it can be changed if we want (I think), and it is better to do
> > early than too late
>
> While checking the
Currently, if you configure a hot standby server with a smaller
max_connections setting than the primary, the server refuses to start up:
LOG: entering standby mode
FATAL: recovery aborted because of insufficient parameter settings
DETAIL: max_connections = 10 is a lower setting than on the p
On Fri, Aug 30, 2024 at 12:17:47AM +0530, Ayush Vatsa wrote:
> The patch with all the changes is attached.
Looks generally reasonable to me.
--
nathan
Hi Shveta,
Thanks for reviewing it so quickly.
On Thu, Aug 29, 2024 at 2:35 AM shveta malik wrote:
>
> Thanks for the patch. Few comments and queries:
>
> 1)
> + static XLogRecPtr lsn[NUM_SYNC_REP_WAIT_MODE];
>
> We shall name it as 'lsns' as there are multiple.
>
This follows the same na
On Thu, 2024-08-29 at 12:55 +0530, Bharath Rupireddy wrote:
> IMO, every caller branching out in the code like if (rel->rd_tableam-
> >
> tuple_modify_buffer_insert != NULL) then multi insert; else single
> insert; doesn't look good. IMO, the default implementation approach
> keeps things simple wh
Hello,
This patch was a bit discussed on [1], and with more details on [2]. It's
based on another patch sent in 2022 (see [3]). It introduces seven new
columns in pg_stat_statements:
* parallelized_queries_planned, number of times the query has been planned
to be parallelized,
* parallelized_qu
On Sun, Jun 30, 2024 at 10:48 AM Noah Misch wrote:v
> > Would anyone like me to be more aggressive, and create a pgstat entry
> > as soon as we have the opening transaction? Or... as soon as a
> > connection is made?
>
> All else being equal, I'd like backends to have one before taking any lmgr
>
On Sun, May 19, 2024 at 6:46 AM Noah Misch wrote:
>
> On Wed, May 15, 2024 at 02:56:54PM +0900, Masahiko Sawada wrote:
> >
> > How about extending amcheck to support GIN and GIst indexes so that it
> > can detect potential data incompatibility due to changing 'char' to
> > 'unsigned char'? I think
Richard Guo writes:
> On Thu, Aug 29, 2024 at 4:47 AM Tom Lane wrote:
>> In the meantime, I think this test case is mighty artificial,
>> and it wouldn't bother me any to just take it out again for the
>> time being.
> Yeah, I think we can remove the 't1.two+t2.two' test case if we go
> with you
On 2024-08-29 Th 1:01 PM, Mark Murawski wrote:
On 8/29/24 11:56, Andrew Dunstan wrote:
On 2024-08-28 We 5:53 PM, Mark Murawski wrote:
Hi Hackers!
This would be version v1 of this feature
Basically, the subject says it all: pl/pgperl Patch for being able
to tell which function you're in.
Hi,
On Thu, Aug 29, 2024 at 6:32 AM Bharath Rupireddy
wrote:
> In synchronous replication setup, until standby finishes fetching WAL
> from the archive, the commits on the primary have to wait which can
> increase the query latency. If the standby can connect to the primary
> as soon as the broke
On 8/29/24 16:54, Andrew Dunstan wrote:
On 2024-08-29 Th 1:01 PM, Mark Murawski wrote:
On 8/29/24 11:56, Andrew Dunstan wrote:
On 2024-08-28 We 5:53 PM, Mark Murawski wrote:
Hi Hackers!
This would be version v1 of this feature
Basically, the subject says it all: pl/pgperl Patch for be
On 29.08.24 20:50, Pavel Stehule wrote:
>
> I know, but theoretically, there can be some benefit for CANONICAL if
> pg supports bytea there. Lot of databases still use non utf8 encoding.
>
> It is a more theoretical question - if pg supports different types
> there in future (because SQL/XML or
On 28.08.24 10:19, Jim Jones wrote:
> Hi,
>
> While testing a feature reported by Pavel in this thread[1] I realized
> that elements containing whitespaces between them won't be indented with
> XMLSERIALIZE( ... INDENT)
>
> SELECT xmlserialize(DOCUMENT '42' AS text INDENT);
>
> xmlserialize
On Wed, 2024-08-28 at 19:25 -0400, Tom Lane wrote:
> This does not seem remarkably problematic to me, given Robert's
> proposal of a bitmask of allowed plan types per RelOptInfo.
> You just do something like
>
> rel->allowed_plan_types = DESIRED_PLAN_TYPE;
>
> The names of the bits you ar
On Thu, Aug 29, 2024 at 09:28:49AM -0500, Nathan Bossart wrote:
> On Thu, Aug 29, 2024 at 02:11:22PM +0900, Michael Paquier wrote:
> > Okay, here is a v2 of the patch using this name for the function.
>
> LGTM
Thanks, applied that, after one tweak for the #define name.
--
Michael
signature.asc
David Rowley writes:
Hello David,
>> My high level proposal is define a type specific print function like:
>>
>> oidprint(Datum datum, StringInfo buf)
>> textprint(Datum datum, StringInfo buf)
>
> I think what we should do instead is make the output functions take a
> StringInfo and just pass it
On Fri, 30 Aug 2024 at 03:33, Tom Lane wrote:
>
> David Rowley writes:
> > [ redesign I/O function APIs ]
> > I had planned to work on this for PG18, but I'd be happy for some
> > assistance if you're willing.
>
> I'm skeptical that such a thing will ever be practical. To avoid
> breaking un-con
On Fri, 30 Aug 2024 at 12:10, Andy Fan wrote:
> What would be the extra benefit we redesign all the out functions?
If I've understood your proposal correctly, it sounds like you want to
invent a new "print" output function for each type to output the Datum
onto a StringInfo, if that's the case, w
David Rowley writes:
> On Fri, 30 Aug 2024 at 12:10, Andy Fan wrote:
>> What would be the extra benefit we redesign all the out functions?
>
> If I've understood your proposal correctly, it sounds like you want to
> invent a new "print" output function for each type to output the Datum
> onto a
On Fri, 30 Aug 2024 at 13:04, Andy Fan wrote:
>
> David Rowley writes:
> > If there's anywhere we call output functions
> > where the resulting value isn't directly appended to a StringInfo,
> > then we could just use a temporary StringInfo to obtain the cstring
> > and its length.
>
> I think th
David Rowley writes:
> On Fri, 30 Aug 2024 at 13:04, Andy Fan wrote:
>>
>> David Rowley writes:
>> > If there's anywhere we call output functions
>> > where the resulting value isn't directly appended to a StringInfo,
>> > then we could just use a temporary StringInfo to obtain the cstring
>> >
Hi, here are some review comments for patch v43-0001.
==
Commit message
1.
... introduces a GUC allowing users set inactive timeout.
~
1a. You should give the name of the new GUC in the commit message.
1b. /set/to set/
==
doc/src/sgml/config.sgml
GUC "replication_slot_inactive_timeou
Hi hackers,
I find there are some unnecessary load/store instructions being
emitted by the JIT compiler.
E.g.,
```
v_boolnull = l_load(b, TypeStorageBool, v_resnullp, "");
v_boolvalue = l_load(b, TypeSizeT, v_resvaluep, "");
/* set resnull to boolnull */
LLVMBuildStore(b, v_boolnull, v_resnullp
Hello Heikki,
26.08.2024 07:00, Alexander Lakhin wrote:
Could you also take a look at the kerberos setup on chipmunk? Now that
chipmunk goes beyond configure (on HEAD and REL_17_STABLE), it fails on the
kerberosCheck stage, ...
I see that chipmunk turned green.
Thank you for taking care of th
On Thu, Aug 29, 2024 at 11:06 AM Zhijie Hou (Fujitsu)
wrote:
>
>
> Agreed. Here is new version patch which change the names as suggested. I also
> rebased the patch based on another renaming commit 640178c9.
>
Thanks for the patch. Few minor things:
1)
conflict.h:
* This enum is used in statist
čt 29. 8. 2024 v 23:54 odesílatel Jim Jones
napsal:
>
>
> On 29.08.24 20:50, Pavel Stehule wrote:
> >
> > I know, but theoretically, there can be some benefit for CANONICAL if
> > pg supports bytea there. Lot of databases still use non utf8 encoding.
> >
> > It is a more theoretical question - if
David Rowley writes:
> On Fri, 30 Aug 2024 at 03:33, Tom Lane wrote:
>>
>> David Rowley writes:
>> > [ redesign I/O function APIs ]
>> > I had planned to work on this for PG18, but I'd be happy for some
>> > assistance if you're willing.
>>
>> I'm skeptical that such a thing will ever be practi
Hi Alex,
JITLink came back onto the radar screen: we see that LLVM 20 will
deprecate the RuntimeDyld link layer that we're using. JITLink would
in fact fix the open bug report we have about LLVM crashing all over
the place on ARM[1], and I can see that would be quite easy to do what
you showed, b
Hi Hou-San. Here are my review comments for v4-0001.
==
1. Add links in the docs
IMO it would be good for all these confl_* descriptions (in
doc/src/sgml/monitoring.sgml) to include links back to where each of
those conflict types was defined [1].
Indeed, when links are included to the orig
H, hackersi! Tell me, please Do I understand correctly that
pg_dump/pg_restore has
not been taught to do COPY FREEZE when filling data? The last mention of
the plans was Bruce in 2013: https://postgrespro.com/list/thread-id/1815657
https://paquier.xyz/postgresql-2/postgres-9-3-feature-highlight-cop
On 30.08.24 06:46, Pavel Stehule wrote:
>
>
> čt 29. 8. 2024 v 23:54 odesílatel Jim Jones
> napsal:
>
>
> > +SELECT xmlserialize(CONTENT doc AS text CANONICAL) =
> > xmlserialize(CONTENT doc AS text CANONICAL WITH COMMENTS) FROM
> > xmltest_serialize;
> > + ?column?
> > +
On Fri, Aug 30, 2024 at 9:40 AM shveta malik wrote:
>
> On Thu, Aug 29, 2024 at 11:06 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> >
> > Agreed. Here is new version patch which change the names as suggested. I
> > also
> > rebased the patch based on another renaming commit 640178c9.
> >
>
> Thanks for
On Fri, Aug 30, 2024 at 10:53 AM Peter Smith wrote:
>
> Hi Hou-San. Here are my review comments for v4-0001.
>
> ==
>
> 1. Add links in the docs
>
> IMO it would be good for all these confl_* descriptions (in
> doc/src/sgml/monitoring.sgml) to include links back to where each of
> those confli
On Fri, Aug 23, 2024 at 10:39 AM shveta malik wrote:
>
> On Thu, Aug 22, 2024 at 3:44 PM shveta malik wrote:
> >
> >
> > For clock-skew and timestamp based resolution, if needed, I will post
> > another email for the design items where suggestions are needed.
> >
>
> Please find issues which need
On Mon, Aug 26, 2024 at 2:23 PM Amit Kapila wrote:
>
> On Thu, Aug 22, 2024 at 3:45 PM shveta malik wrote:
> >
> > On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond
> > wrote:
> > >
> > > The patches have been rebased on the latest pgHead following the merge
> > > of the conflict detection patch [1].
On Tue, Aug 20, 2024 at 04:23:06PM +, Bertrand Drouvot wrote:
> Please find attached v3 that:
>
> - takes care of your comments (and also removed the use of PG_TBLSPC_DIR in
> RELATIVE_PG_TBLSPC_DIR).
> - removes the new macros from the comments (see Michael's and Yugo-San's
> comments in [0]
On 27.08.24 11:26, Etsuro Fujita wrote:
On Sat, Aug 24, 2024 at 11:27 PM Peter Eisentraut wrote:
As usual, please check for problems such as wrong sorting, duplicate
names in different variants, or names in the wrong order etc.
I think Japanese names are in the right order except “Sutou Kouhe
On Wed, Aug 28, 2024 at 10:58 AM shveta malik wrote:
>
> On Wed, Aug 28, 2024 at 10:30 AM Ajin Cherian wrote:
> >
> >> 2)
> >> Currently pg_dump is dumping even the default resolvers configuration.
> >> As an example if I have not changed default configuration for say
> >> sub1, it still dumps al
On Friday, August 30, 2024 2:24 PM shveta malik wrote:
>
> On Fri, Aug 30, 2024 at 10:53 AM Peter Smith
> wrote:
> >
> > Hi Hou-San. Here are my review comments for v4-0001.
Thanks Shveta and Peter for giving comments !
> >
> > ==
> >
> > 1. Add links in the docs
> >
> > IMO it would be go
Hi Michael,
On 2024-08-23 19:01, Michael Harris wrote:
V2 of the patch is attached.
Thanks for the proposal and the patch.
You said this patch was a first draft version, so these may be too minor
comments, but I will share them:
-- https://www.postgresql.org/docs/devel/progress-reporting
On Fri, Aug 30, 2024 at 12:13 PM Amit Kapila wrote:
>
> On Wed, Aug 28, 2024 at 10:58 AM shveta malik wrote:
> >
> > On Wed, Aug 28, 2024 at 10:30 AM Ajin Cherian wrote:
> > >
> > >> 2)
> > >> Currently pg_dump is dumping even the default resolvers configuration.
> > >> As an example if I have n
On Wed, Aug 28, 2024 at 4:07 PM shveta malik wrote:
>
> > On Wed, Aug 28, 2024 at 10:30 AM Ajin Cherian wrote:
> > >
>
> The review is WIP. Please find a few comments on patch001.
>
> 1)
> logical-repliction.sgmlL
>
> + Additional logging is triggered for specific conflict_resolvers.
> Users can
86 matches
Mail list logo
