On Fri, Feb 12, 2021 at 3:26 AM Robert Haas wrote:
>
> On Thu, Feb 11, 2021 at 6:07 AM Dilip Kumar wrote:
> > > Thanks for the patch. I tested the new function and it works as
> > > expected. I have no further comments on the v13 patch.
> >
> > Thanks for the review and testing.
>
> I don't see
On Tue, Feb 23, 2021 at 9:33 AM Andres Freund wrote:
>
> On 2021-02-23 09:24:18 +0530, Amit Kapila wrote:
> > Okay, so is it sufficient to add comments in code, or do we want to
> > add something in docs? I am not completely sure if we need to add in
> > docs till we have core-implementation of
On Thu, Dec 31, 2020 at 10:05 AM Michael Banck
wrote:
>
> Hi,
>
> Am Montag, den 28.12.2020, 20:41 +0900 schrieb Masahiko Sawada:
> > On Sat, Nov 28, 2020 at 7:50 AM Michael Banck
> > wrote:
> > > https://www.postgresql.org/docs/current/default-roles.html mentions the
> > > "Administrator"
> > 4. Maybe it also doesn't make sense to consider the parent relation's
> > parallel_workers if Parallel Append is disabled
> > (enable_parallel_append = off). That's because with a simple
> > (non-parallel) Append running under Gather, all launched parallel
> > workers process the same
Andy Fan writes:
> Planning is expensive and we use plancache to bypass its effect. I find the
> $subject recently which is caused by we register NAMESPACEOID invalidation
> message for pg_temp_%s as well as other normal namespaces. Is it a
> must?
Since we don't normally delete those
Andres Freund writes:
> We could add a wrapper node around "planner expressions" that stores
> metadata about them during planning, without those properties leaking
> over expressions used at other times. E.g. having
> preprocess_expression() return a PlannerExpr that that points to the
>
On Tue, Feb 23, 2021 at 12:07 PM Andy Fan wrote:
> Planning is expensive and we use plancache to bypass its effect. I find the
> $subject recently which is caused by we register NAMESPACEOID invalidation
> message for pg_temp_%s as well as other normal namespaces. Is it a
> must?
>
> We can
Planning is expensive and we use plancache to bypass its effect. I find the
$subject recently which is caused by we register NAMESPACEOID invalidation
message for pg_temp_%s as well as other normal namespaces. Is it a
must?
We can demo the issue with the below case:
Sess1:
create table t (a
Hi
On 2021-02-23 09:24:18 +0530, Amit Kapila wrote:
> Okay, so is it sufficient to add comments in code, or do we want to
> add something in docs? I am not completely sure if we need to add in
> docs till we have core-implementation of prepare waiting to get
> logically replicated.
There's
On Tue, Feb 23, 2021 at 9:09 AM Andres Freund wrote:
>
> On 2021-02-23 08:56:39 +0530, Amit Kapila wrote:
> > On Tue, Feb 23, 2021 at 3:58 AM Andres Freund wrote:
> > > Perhaps all that we need to do is to disallow 2PC prepare if [user]
> > > catalog tables have been locked exclusively?
>
> >
Hi Hackers,
Recently, I took some performance measurements for CREATE TABLE AS.
https://www.postgresql.org/message-id/34549865667a4a3bb330ebfd035f85d3%40G08CNEXMBPEKD05.g08.fujitsu.local
Then I found an issue about the tuples unbalance distribution(99% tuples read
by one worker) among workers
Hi,
On 2021-02-23 08:56:39 +0530, Amit Kapila wrote:
> On Tue, Feb 23, 2021 at 3:58 AM Andres Freund wrote:
> > Perhaps all that we need to do is to disallow 2PC prepare if [user]
> > catalog tables have been locked exclusively?
> Right, and we have discussed this during development [1][2].
I
On Tue, Feb 23, 2021 at 6:37 AM Greg Nancarrow wrote:
>
> On Tue, Feb 23, 2021 at 12:33 AM Amit Kapila wrote:
> >
> > On Mon, Feb 22, 2021 at 8:41 AM Greg Nancarrow wrote:
> > >
> > > On Fri, Feb 19, 2021 at 9:38 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Thu, Feb 18, 2021 at 11:05 AM
On Tue, Feb 23, 2021 at 3:58 AM Andres Freund wrote:
>
>
> At first this seems to be a significant issue. But on the other hand, if
> you were to shut the cluster down in this situation (or disconnect all
> sessions), you have broken cluster on your hand - without logical
> decoding being
On Mon, Feb 22, 2021 at 11:04 PM Markus Wanner wrote:
>
> On 04.01.21 09:18, Amit Kapila wrote:
> > Thanks, I have pushed the 0001* patch after making the above and a few
> > other cosmetic modifications.
>
> That commit added the following snippet to the top of
> ReorderBufferFinishPrepared:
>
>
Hi,
On 2021-02-22 20:51:17 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Except for the annoying issue that that we pervasively use Lists as
> > expressions, I'd argue that we should actually cache "subtree
> > volatility" in Expr nodes, similar to the way we use OpExpr.opfuncid
> > etc.
Andres Freund writes:
> Except for the annoying issue that that we pervasively use Lists as
> expressions, I'd argue that we should actually cache "subtree
> volatility" in Expr nodes, similar to the way we use OpExpr.opfuncid
> etc. That'd allow us to make contain_volatile_functions() very cheap
Hi,
On 2021-02-16 23:15:51 +1300, David Rowley wrote:
> There might be gains to be had by checking the parse once rather than
> having to call contains_volatile_functions in the various places we do
> call it. I think both the parallel safety and volatile checks could
> then be done in the same
On Tue, Feb 23, 2021 at 7:55 AM Peter Geoghegan wrote:
>
> On Mon, Feb 22, 2021 at 4:21 AM Masahiko Sawada wrote:
> > The 0001 patch looks good to me. In the documentation, I think we need
> > to update the following paragraph in the description of
> > vacuum_cleanup_index_scale_factor:
>
> Good
On Mon, Feb 22, 2021 at 9:21 AM Justin Pryzby wrote:
> On Tue, Feb 16, 2021 at 11:15:51PM +1300, David Rowley wrote:
> > To summarise here, the planner performance gets a fair bit worse with
> > the patched code. With master, summing the average planning time over
> > each of the queries
Hi,
On 2021-02-15 16:21:38 +0900, Michael Paquier wrote:
> I have been playing with this idea, and finished with the attached,
> which is not the sexiest patch around. The table AM used as fallback
> for tables without storage is called no_storage (this could be called
> virtual_am?).
> One
Hi,
On 2021-02-22 08:33:21 +0100, Mats Kindahl wrote:
> I started to experiment with the table access method interface to see if it
> can be used for some ideas I have.
Cool.
> The `relation_set_new_filenode` is indirectly called from
> `heap_create_with_catalog`, but there is no corresponding
On Tue, Feb 23, 2021 at 12:33 AM Amit Kapila wrote:
>
> On Mon, Feb 22, 2021 at 8:41 AM Greg Nancarrow wrote:
> >
> > On Fri, Feb 19, 2021 at 9:38 PM Amit Kapila wrote:
> > >
> > > On Thu, Feb 18, 2021 at 11:05 AM Amit Langote
> > > wrote:
> > > >
> > > > > > It also occurred to me that we
On 2021-Feb-22, Álvaro Herrera wrote:
> Here's an updated patch.
>
> I haven't added commentary or documentation to account for the new
> assumption, per Matthias' comment and Robert's discussion thereof.
Done that. I also restructured the code a bit, since one line in
ComputedXidHorizons was
On Tue, Dec 8, 2020 at 2:42 AM Alexander Korotkov wrote:
> Thank you for your feedback!
It would be nice to use this patch to test things that are important
but untested inside vacuumlazy.c, such as the rare
HEAPTUPLE_DEAD/tupgone case (grep for "Ordinarily, DEAD tuples would
have been removed
On Mon, Feb 22, 2021 at 4:21 AM Masahiko Sawada wrote:
> The 0001 patch looks good to me. In the documentation, I think we need
> to update the following paragraph in the description of
> vacuum_cleanup_index_scale_factor:
Good point. I think that the structure should make the page deletion
On Fri, Dec 11, 2020 at 7:57 AM Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > The if-we're-going-to-delay-anyway path in vacuum_delay_point seems
> > OK to add a touch more overhead to, though.
>
> Alright, for this part at least, seems like it'd be something like the
>
Hi,
The 2pc decoding added in
commit a271a1b50e9bec07e2ef3a05e38e7285113e4ce6
Author: Amit Kapila
Date: 2021-01-04 08:34:50 +0530
Allow decoding at prepare time in ReorderBuffer.
has a deadlock danger when used in a way that takes advantage of
separate decoding of the 2PC PREPARE.
I
> On 22 Feb 2021, at 22:21, Andres Freund wrote:
>
> Hi,
>
> On 2021-02-22 15:44:30 -0500, Tom Lane wrote:
>> Robert Haas writes:
>>> So at the end of the day I'm not really quite sure what is best here.
>>> I agree with all of Craig's points about the advantages of
>>> packet-level
Hi,
On 2021-02-22 15:44:30 -0500, Tom Lane wrote:
> Robert Haas writes:
> > So at the end of the day I'm not really quite sure what is best here.
> > I agree with all of Craig's points about the advantages of
> > packet-level compression, so I'd really prefer to make that approach
> > work if we
Hi,
On 2021-02-22 11:20:54 -0500, Jim Mlodgenski wrote:
> As Jan mentioned in his thread about a pluggable wire protocol [0], AWS is
> working on a set of extensions for Babelfish. The intention is to not
> necessarily have it as a single monolithic extension, but be possible for
> people to use
Robert Haas writes:
> So at the end of the day I'm not really quite sure what is best here.
> I agree with all of Craig's points about the advantages of
> packet-level compression, so I'd really prefer to make that approach
> work if we can. However, it also seems to me that there's room to be
>
I solved my problem by using attnum::text instead of attname for
pg_class.relkind = ‘i’ as a work-around to avoid a diff.
On Mon, Feb 22, 2021, at 18:21, Joel Jacobson wrote:
> Hi,
>
> When renaming a column that is part of a primary key,
> the primary key index's pg_attribute.attname value
>
Hi,
On 2021-02-22 14:48:25 -0500, Robert Haas wrote:
> So, if I read these results correctly, on the "pg_restore of IMDB
> database" test, we get 88% of the RX bytes reduction and 99.8% of the
> TX bytes reduction for 90% of the CPU cost. On the "pgbench" test,
> which probably has much smaller
On Mon, Feb 15, 2021 at 10:37 AM Tomas Vondra
wrote:
> [v20210215]
Hi Tomas,
This time I only looked at the cumulative changes in the multiminmax
opclass, since I'm pretty sure all the bloom issues have been addressed.
* XXX CombineRange name seems a bit weird. Consider renaming, perhaps to
On 2021-Feb-21, Michael Paquier wrote:
> On Sat, Feb 20, 2021 at 12:25:58PM -0300, Álvaro Herrera wrote:
> > Hmm. Alternatively, maybe it'd make sense to change
> > HeapTupleHeaderSetMovedPartition to use ItemPointerSetMovedPartitions
> > instead of doing ItemPointerSet directly. But that
On Thu, Feb 11, 2021 at 8:09 AM Daniil Zakhlystov
wrote:
> [ benchmark results ]
So, if I read these results correctly, on the "pg_restore of IMDB
database" test, we get 88% of the RX bytes reduction and 99.8% of the
TX bytes reduction for 90% of the CPU cost. On the "pgbench" test,
which
On 2/22/21 1:01 PM, Tom Lane wrote:
Yeah, and as I pointed out somewhere upthread, trying to replace the
whole parser will just end in a maintenance nightmare. The constructs
that the parser has to emit are complex, Postgres-specific, and
constantly evolving. We are NOT going to promise any
On Mon, Feb 22, 2021 at 1:01 PM Tom Lane wrote:
> Jan Wieck writes:
> > As Jim Mlodgenski just posted in [0], having the ability to also extend
> > and/or replace the parser will give them the ability to do just that.
>
> Yeah, and as I pointed out somewhere upthread, trying to replace the
>
Jan Wieck writes:
> On 2/10/21 1:10 PM, Tom Lane wrote:
>> What I'm actually more concerned about, in this whole line of development,
>> is the follow-on requests that will surely occur to kluge up Postgres
>> to make its behavior more like $whatever. As in "well, now that we
>> can serve MySQL
On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
> cd src/test/ssl
> touch ../../Makefile.global
> rm -f ssl/client-dn.crt ssl/client-dn.key
> touch ssl/root_ca-certindex
> echo 01> ssl/root_ca.srl
Note that, on my machine at least, the root_ca serial counter is at 03
Hello Amit,
On 04.01.21 09:18, Amit Kapila wrote:
Thanks, I have pushed the 0001* patch after making the above and a few
other cosmetic modifications.
That commit added the following snippet to the top of
ReorderBufferFinishPrepared:
txn = ReorderBufferTXNByXid(rb, xid, true, NULL,
Hi,
When renaming a column that is part of a primary key,
the primary key index's pg_attribute.attname value
isn't updated accordingly, the old value remains.
This causes problems when trying to measure if the
effects of a migration script caused the same end result
as if installing the same
On Sun, Feb 21, 2021 at 11:05:26PM -0600, Justin Pryzby wrote:
> On Mon, Jan 04, 2021 at 11:09:39AM -0600, Justin Pryzby wrote:
> > For example:
> >
> > $ python3.5 -c "import pg; db=pg.DB(); q = db.query(\"SET
> > log_parameter_max_length_on_error=-1;\"); db.prepare('p', 'SELECT
> >
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Other than "Hunk #1 succeeded at 3832 (offset 33 lines)." message
On 2/10/21 1:10 PM, Tom Lane wrote:
What I'm actually more concerned about, in this whole line of development,
is the follow-on requests that will surely occur to kluge up Postgres
to make its behavior more like $whatever. As in "well, now that we
can serve MySQL clients protocol-wise, can't we
David Fetter writes:
> I'm not sure whether this is a bug or an infelicity we document, but
> at least in some parts of the world, this calculation doesn't comport
> with the calendar in place at the time:
> SELECT to_timestamp('1753', '') - to_timestamp('1752', '');
Yeah, Appendix B.6
As Jan mentioned in his thread about a pluggable wire protocol [0], AWS is
working on a set of extensions for Babelfish. The intention is to not
necessarily have it as a single monolithic extension, but be possible for
people to use pieces of it as they need when they are migrating to
PostgreSQL.
On Mon, Feb 22, 2021 at 07:34:51AM -0500, Dave Cramer wrote:
> On Fri, 19 Feb 2021 at 15:39, Álvaro Hernández wrote:
>
> > On 19/2/21 19:30, Jan Wieck wrote:
> > > [...]
> > >
> > > I also am not sure if building a connection pool into a
> > > background worker or postmaster is a good idea to
On Mon, Feb 22, 2021 at 10:52:42AM -0500, Tom Lane wrote:
> "Michael J. Baars" writes:
> > So how do you compute the number of seconds in 8 years?
>
> IMO, that's a meaningless computation, because the answer is not fixed.
> Before you claim otherwise, think about the every-four-hundred-years
>
Here's an updated patch.
I haven't added commentary or documentation to account for the new
assumption, per Matthias' comment and Robert's discussion thereof.
--
Álvaro Herrera39°49'30"S 73°17'W
"Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)
"Michael J. Baars" writes:
> So how do you compute the number of seconds in 8 years?
IMO, that's a meaningless computation, because the answer is not fixed.
Before you claim otherwise, think about the every-four-hundred-years
leap year exception in the Gregorian rules. Besides, what if the
"wangsh.f...@fujitsu.com" writes:
> Because it's a little difficult to install lcov in offline environment and we
> can get a
> text format result by running make coverage. How about change this action,
> when
> there is no lcov in system, only a warning message is reported.
> The patch
On 2/19/21 4:36 AM, Kuntal Ghosh wrote:
On Thu, Feb 18, 2021 at 9:32 PM Jan Wieck wrote:
Few comments in the extension code (although experimental):
1. In telnet_srv.c,
+ static intpe_port;
..
+ DefineCustomIntVariable("telnet_srv.port",
+
On 2/22/21 7:34 AM, Dave Cramer wrote:
Yes, when did it become a good idea to put a connection pooler in the
backend???
Dave Cramer
www.postgres.rocks
As Alvaro said, different pool purposes lead to different pool
architecture and placement.
However, the changes proposed here, aiming at
On 2/21/21 10:34 PM, Andres Freund wrote:
> Hi,
>
> On 2021-02-17 15:18:02 -0500, Andrew Dunstan wrote:
>> yeah. The cfbot runs check-world which makes it difficult for it to know
>> which log files to show when there's an error. That's a major part of
>> the reason the buildfarm runs a much
On 2/21/21 9:28 PM, Thomas Munro wrote:
> On Sat, Feb 20, 2021 at 3:54 AM Andrew Dunstan wrote:
>> here's a very small and simple (and possibly naive) POC patch that
>> demonstrates this and seems to do the right thing.
> As a small variation that might be more parallelism-friendly, would it
>
On 2/22/21 1:28 PM, Peter Eisentraut wrote:
> On 22.02.21 11:05, Vik Fearing wrote:
>> This looks good to me, except that you forgot to add the feature stamp.
>> Attached is a small diff to apply on top of your patch to fix that.
>
> The feature code is from SQL:202x, whereas the table is
On Mon, Feb 22, 2021 at 8:41 AM Greg Nancarrow wrote:
>
> On Fri, Feb 19, 2021 at 9:38 PM Amit Kapila wrote:
> >
> > On Thu, Feb 18, 2021 at 11:05 AM Amit Langote
> > wrote:
> > >
> > > > > It also occurred to me that we can avoid pointless adding of
> > > > > partitions if the final plan
On Mon, Feb 22, 2021 at 8:46 AM Amit Langote wrote:
>
> On Fri, Feb 19, 2021 at 7:38 PM Amit Kapila wrote:
> > On Thu, Feb 18, 2021 at 11:05 AM Amit Langote
> > wrote:
> > >
> > > > > It also occurred to me that we can avoid pointless adding of
> > > > > partitions if the final plan won't use
On Mon, Feb 22, 2021 at 6:25 PM houzj.f...@fujitsu.com
wrote:
>
> Hi
>
> (I may be wrong here)
> I noticed that the patch does not have check for partial index(index
> predicate).
> It seems parallel index build will check it like the following:
> --
> /*
> * Determine
On Sat, Feb 20, 2021, at 7:33 AM, Amit Kapila wrote:
> I have used a bit of different wording here to make things clear.
>
> Let me know what you think of the attached?
WFM.
--
Euler Taveira
EDB https://www.enterprisedb.com/
On Fri, 19 Feb 2021 at 15:39, Álvaro Hernández wrote:
>
>
> On 19/2/21 19:30, Jan Wieck wrote:
> > [...]
> >
> > I also am not sure if building a connection pool into a background
> > worker or postmaster is a good idea to begin with. One of the
> > important features of a pool is to be able to
On Mon, Feb 22, 2021, at 7:45 AM, Önder Kalacı wrote:
> Thanks for working on this. I did some review and testing, please see my
> comments below.
I appreciate your review. I'm working on a new patch set and expect to post it
soon.
> I think if you are planning to keep the debug patch, there
On 22.02.21 11:05, Vik Fearing wrote:
This looks good to me, except that you forgot to add the feature stamp.
Attached is a small diff to apply on top of your patch to fix that.
The feature code is from SQL:202x, whereas the table is relative to
SQL:2016. We could add it, but probably with
On Fri, Feb 19, 2021 at 3:18 PM Masahiko Sawada wrote:
>
> On Fri, Feb 19, 2021 at 3:12 PM Peter Geoghegan wrote:
> >
> > On Thu, Feb 18, 2021 at 3:13 AM Masahiko Sawada
> > wrote:
> > > Agreed. Thanks for your explanation.
> >
> > Attached is v5, which has some of the changes I talked about.
On Mon, Feb 22, 2021 at 8:27 PM Michael Paquier wrote:
> Looks good to me, thanks!
Pushed, with one further small change: I realised that tab completion
should use a "schema" query.
> On 22 Feb 2021, at 11:52, Magnus Hagander wrote:
>
> On Thu, Feb 18, 2021 at 1:51 PM Daniel Gustafsson wrote:
>>
>> A few years ago we discussed whether to disable SSL compression [0] which
>> ended
>> up with it being off by default combined with a recommendation against it in
>> the docs.
On Thu, Feb 18, 2021 at 1:51 PM Daniel Gustafsson wrote:
>
> A few years ago we discussed whether to disable SSL compression [0] which
> ended
> up with it being off by default combined with a recommendation against it in
> the docs.
>
> OpenSSL themselves disabled SSL compression by default in
Hi,
Thanks for working on this. I did some review and testing, please see my
comments below.
1)
0008 is only for debug purposes (I'm
>not sure some of these messages will be part of the final patch).
>
I think if you are planning to keep the debug patch, there seems to be an
area of
On 2/22/21 9:44 AM, Peter Eisentraut wrote:
> On 22.05.20 14:32, Peter Eisentraut wrote:
>>> As an improvement over the spec, I think the vast majority of people
>>> will be using simple true/false values. Can we make that optional?
>>>
>>> CYCLE f, t SET is_cycle USING path
>>>
>>> would be
On Mon, Feb 22, 2021 at 2:55 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-02-22 09:25:52 +0100, Markus Wanner wrote:
> > What issues do you see with the approach I proposed?
>
> Very significant increase in complexity for initializing a logical
> replica, because there's no easy way to just use
On Sat, 2021-02-20 at 11:20 -0500, Tom Lane wrote:
> "Michael J. Baars" writes:
> > Can someone please tell me which of these two queries gives the correct
> > result and which one the incorrect?
> > // 2.922 (&)
> > with A1 as ( select make_interval (0, 0, 0, 0, 0, 0, ( extract ( epoch
On 2021/02/18 16:26, torikoshia wrote:
On 2021-02-16 16:59, Fujii Masao wrote:
On 2021/02/15 15:17, Fujii Masao wrote:
On 2021/02/10 10:43, Fujii Masao wrote:
On 2021/02/09 23:31, torikoshia wrote:
On 2021-02-09 22:54, Fujii Masao wrote:
On 2021/02/09 19:11, Fujii Masao wrote:
On
Hi,
On 2021-02-22 14:29:09 +0530, Amit Kapila wrote:
> On Mon, Feb 22, 2021 at 9:39 AM Andres Freund wrote:
> > What I am proposing is to instead track the point at which the slot
> > gained consistency - a simple LSN. That way you can change the above
> > logic to instead be
> >
> > if
Hi,
On 2021-02-22 09:25:52 +0100, Markus Wanner wrote:
> What issues do you see with the approach I proposed?
Very significant increase in complexity for initializing a logical
replica, because there's no easy way to just use the initial slot.
- Andres
On Mon, Feb 22, 2021 at 9:39 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-02-22 08:22:35 +0530, Amit Kapila wrote:
> > On Mon, Feb 22, 2021 at 3:56 AM Andres Freund wrote:
> > >
> > > On 2021-02-21 11:32:29 +0530, Amit Kapila wrote:
> > > > Here, I am assuming you are asking to disable 2PC both
On 22.05.20 14:32, Peter Eisentraut wrote:
As an improvement over the spec, I think the vast majority of people
will be using simple true/false values. Can we make that optional?
CYCLE f, t SET is_cycle USING path
would be the same as
CYCLE f, t SET is_cycle TO true DEFAULT false
Hi, hackers
In [1] wrote:
> If you don't have lcov or prefer text output over an HTML report, you can
> also run
> make coverage
[1] https://www.postgresql.org/docs/13/regress-coverage.html
It seems the lcov is not a necessary program to run a coverage test.
But when I configure with
Alvaro-san, Iwata-san,
From: Iwata, Aya/岩田 彩
> I update patch to v19.
...
> And 3 bugs I noted February 2nd email are all fixed.
> > 1. fix 3 bugs
> > 1.1 -1 output in "Query" message
> > 1.2 two message output in "ReadyForQuery" message
> > 1.3 "StartupMessage" output as " UnknownMessage
On 22.02.21 05:22, Andres Freund wrote:
Hi,
On 2021-02-19 15:53:32 +0100, Markus Wanner wrote:
However, more generally speaking, I suspect you are overthinking this. All
of the complexity arises because of the assumption that an output plugin
receiving and confirming a PREPARE may not be able
On 20.02.21 13:15, Amit Kapila wrote:
I think after the patch Ajin proposed decoders won't need any special
checks after receiving the prepared xacts. What additional simplicity
this approach will bring?
The API becomes clearer in that all PREPAREs are always decoded in WAL
stream order and
Hi Tsunakawa san,
I update patch to v19.
> -Original Message-
> From: Tsunakawa, Takayuki/綱川 貴之
> Sent: Monday, February 22, 2021 1:30 PM
> (52)
> + of tracing. If (flags contains
> PQTRACE_SUPPRESS_TIMESTAMPS),
>
> () can be removed?
Yes, I removed ().
> (53)
> + int
Rebased, with a few additions.
>From 27656ceb05d495300d86df40a1d25b0b454fa18b Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Fri, 8 Jan 2021 13:09:55 -0600
Subject: [PATCH 01/21] doc: pageinspect
d6061f83a166b015657fda8623c704fcb86930e9
backpatch to 9.6?
---
doc/src/sgml/pageinspect.sgml |
84 matches
Mail list logo
