> 25 авг. 2021 г., в 19:22, Denis Smirnov написал(а):
>
> I am going to refactor Greenplum backtraces for error messages and want to
> make it more compatible with PostgreSQL code. Backtraces in PostgreSQL were
> introduced by 71a8a4f6e36547bb060dbcc961ea9b57420f7190 commit (original
>
On Wed, Aug 25, 2021 12:22 PM Masahiko Sawada wrote:
>
> Attached updated version patches. Please review them.
The v11-0001 patch LGTM.
Best regards,
Hou zj
On Thu, Aug 26, 2021 at 1:51 PM Amit Kapila wrote:
>
> Do you have any suggestions on how to achieve that without adding some
> additional variable? I think it is not a very hard requirement as we
> don't follow the same at other places in code.
>
Sorry, forget my suggestion, I see it's not easy
On Thu, Aug 26, 2021 at 9:51 AM Peter Smith wrote:
>
> On Thu, Aug 26, 2021 at 1:20 PM Amit Kapila wrote:
> >
> > On Thu, Aug 26, 2021 at 7:37 AM Peter Smith wrote:
> > >
> > > On Wed, Aug 25, 2021 at 3:28 PM Amit Kapila
> > > wrote:
> > > >
> > > ...
> > > >
> > > > Hmm, I think the gain via
On Thu, Aug 26, 2021 at 12:59 PM Ajin Cherian wrote:
>
> On Thu, Aug 26, 2021 at 1:54 PM Amit Kapila wrote:
> >
> > On Thu, Aug 26, 2021 at 9:21 AM Ajin Cherian wrote:
> > >
> > > On Thu, Aug 26, 2021 at 1:06 PM Amit Kapila
> > > wrote:
> > >
> > > >
> > > > You have a point but if we see the
On Thu, Aug 26, 2021 at 1:20 PM Amit Kapila wrote:
>
> On Thu, Aug 26, 2021 at 7:37 AM Peter Smith wrote:
> >
> > On Wed, Aug 25, 2021 at 3:28 PM Amit Kapila wrote:
> > >
> > ...
> > >
> > > Hmm, I think the gain via caching is not visible because we are using
> > > simple expressions. It will
On Thu, Aug 26, 2021 at 12:51 PM Amit Kapila wrote:
>
> On Thu, Aug 26, 2021 at 7:15 AM Greg Nancarrow wrote:
> >
> > On Wed, Aug 25, 2021 at 2:22 PM Masahiko Sawada
> > wrote:
> > >
> > > Attached updated version patches. Please review them.
> > >
> >
> > Regarding the v11-0001 patch, it
On Thu, Aug 26, 2021 at 1:54 PM Amit Kapila wrote:
>
> On Thu, Aug 26, 2021 at 9:21 AM Ajin Cherian wrote:
> >
> > On Thu, Aug 26, 2021 at 1:06 PM Amit Kapila wrote:
> >
> > >
> > > You have a point but if we see the below logs, it seems the second
> > > walsender (#step6) seemed to exited
On Thu, Aug 26, 2021 at 9:21 AM Ajin Cherian wrote:
>
> On Thu, Aug 26, 2021 at 1:06 PM Amit Kapila wrote:
>
> >
> > You have a point but if we see the below logs, it seems the second
> > walsender (#step6) seemed to exited before the first walsender
> > (#step4).
> >
> > 2021-08-15 18:44:38.041
On Thu, Aug 26, 2021 at 7:15 AM Greg Nancarrow wrote:
>
> On Wed, Aug 25, 2021 at 2:22 PM Masahiko Sawada wrote:
> >
> > Attached updated version patches. Please review them.
> >
>
> Regarding the v11-0001 patch, it looks OK to me, but I do have one point:
> In apply_dispatch(), wouldn't it be
On Thu, Aug 26, 2021 at 1:06 PM Amit Kapila wrote:
>
> You have a point but if we see the below logs, it seems the second
> walsender (#step6) seemed to exited before the first walsender
> (#step4).
>
> 2021-08-15 18:44:38.041 CEST [16475:10] tap_sub LOG: disconnection:
> session time:
On 8/25/21, 5:40 PM, "Kyotaro Horiguchi" wrote:
> At Wed, 25 Aug 2021 18:18:59 +, "Bossart, Nathan"
> wrote in
>> Let's say we have the following situation (F = flush, E = earliest
>> registered boundary, and L = latest registered boundary), and let's
>> assume that each segment has a
On Thu, Aug 26, 2021 at 7:37 AM Peter Smith wrote:
>
> On Wed, Aug 25, 2021 at 3:28 PM Amit Kapila wrote:
> >
> ...
> >
> > Hmm, I think the gain via caching is not visible because we are using
> > simple expressions. It will be visible when we use somewhat complex
> > expressions where
On Fri, 20 Aug 2021 02:05:27 +0900
Fujii Masao wrote:
>
> On 2021/08/11 13:56, Fujii Masao wrote:
> > Yes, but I was thinking that's a bug that we should fix.
> > IOW, I was thinking that, in v13, both connection and disconnection delays
> > should be measured whether -C is specified or not,
On Thu, Aug 26, 2021 at 7:38 AM Ajin Cherian wrote:
>
> On Thu, Aug 26, 2021 at 11:02 AM Masahiko Sawada
> wrote:
> >
>
> Luckily these logs have the disconnection times of the tap test client
> sessions as well. (not sure why I don't see these when I run these
> tests).
>
> Step 5 could have
On Wed, Aug 25, 2021 at 5:23 PM Alvaro Herrera wrote:
> > The question of whether or not we do an index scan (i.e. index
> > vacuuming) depends entirely on the number of LP_DEAD items that heap
> > pruning left behind in the table structure. [...]
>
> Ooh, this was illuminating -- thanks for
On Thu, Aug 19, 2021 at 2:35 PM David Rowley wrote:
>
> On Thu, 19 Aug 2021 at 00:20, Andy Fan wrote:
> > In the current master, the result is:
> >
> > empno | salary | c | dr
> > ---++---+
> > 8 | 6000 | 4 | 1
>
> > In the patched version， the result is:
> >
> > empno
On Wed, Aug 25, 2021 at 10:41:14AM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Aug 25, 2021 at 4:06 PM Robert Haas wrote:
> >> It does tend to be controversial, but I think that's basically only
> >> because Tom Lane has reservations about it. I think if Tom dropped his
> >>
On Wednesday, August 25, 2021 5:37 PM vignesh C wrote:
>
> Attached v21 patch has the changes based on the new syntax and fixes
> few of the other review comments provided by reviewers.
>
Thanks for your new patch. I saw the following warning when building, please
have a look.
On Thu, Aug 26, 2021 at 11:02 AM Masahiko Sawada wrote:
>
> On Wed, Aug 25, 2021 at 11:04 PM Ajin Cherian wrote:
> >
> > On Wed, Aug 25, 2021 at 11:17 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Aug 25, 2021 at 6:10 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > I did a quick check with
On Wed, Aug 25, 2021 at 3:28 PM Amit Kapila wrote:
>
...
>
> Hmm, I think the gain via caching is not visible because we are using
> simple expressions. It will be visible when we use somewhat complex
> expressions where expression evaluation cost is significant.
> Similarly, the impact of this
On Wed, Aug 25, 2021 at 9:19 PM Amit Kapila wrote:
>
> On Tue, Aug 24, 2021 at 3:55 PM Dilip Kumar wrote:
> >
> > On Tue, Aug 24, 2021 at 12:26 PM Amit Kapila
> > wrote:
> >
>
> The first patch looks good to me. I have made minor changes to the
> attached patch. The changes include: fixing
On Wed, Aug 25, 2021 at 2:22 PM Masahiko Sawada wrote:
>
> Attached updated version patches. Please review them.
>
Regarding the v11-0001 patch, it looks OK to me, but I do have one point:
In apply_dispatch(), wouldn't it be better to NOT move the error
reporting for an invalid message type into
On Thu, Aug 26, 2021 at 1:51 AM Alvaro Herrera wrote:
>
> On 2021-Aug-25, Magnus Hagander wrote:
>
> > The thing we need the PGDLLIMPORT definition for is to *import* them
> > on the other end?
>
> Oh ... so modules that are willing to cheat can include their own
> declarations of the variables
(this is off-topic here)
At Wed, 25 Aug 2021 09:56:56 -0400, Robert Haas wrote
in
> On Mon, Aug 23, 2021 at 11:04 PM Kyotaro Horiguchi
> wrote:
> > At Mon, 23 Aug 2021 18:52:17 -0400, Alvaro Herrera
> > wrote in
> > > I'd also like to have tests. That seems moderately hard, but if we had
>
At Wed, 25 Aug 2021 20:20:04 -0400, "alvhe...@alvh.no-ip.org"
wrote in
> BTW while going about testing this, I noticed that we forbid
> pg_walfile_name() while in recovery. That restriction was added by
> commit 370f770c15a4 because ThisTimeLineID was not set correctly during
> recovery. That
On Wed, Aug 25, 2021 at 11:04 PM Ajin Cherian wrote:
>
> On Wed, Aug 25, 2021 at 11:17 PM Amit Kapila wrote:
> >
> > On Wed, Aug 25, 2021 at 6:10 PM Masahiko Sawada
> > wrote:
> > >
> > > I did a quick check with the following tap test code:
> > >
> > >
At Wed, 25 Aug 2021 18:18:59 +, "Bossart, Nathan"
wrote in
> On 8/25/21, 5:33 AM, "alvhe...@alvh.no-ip.org"
> wrote:
> > On 2021-Aug-24, Bossart, Nathan wrote:
> >> Another interesting thing I see is that the boundary stored in
> >> earliestSegBoundary is not necessarily the earliest one.
On 2021-Aug-25, Peter Geoghegan wrote:
> On Wed, Aug 25, 2021 at 2:06 PM Alvaro Herrera
> wrote:
> > I like it better than the current layout, so +1.
>
> This seems like a release housekeeping task to me. I'll come up with
> a patch targeting 14 and master in a few days.
Agreed, thanks.
>
BTW while going about testing this, I noticed that we forbid
pg_walfile_name() while in recovery. That restriction was added by
commit 370f770c15a4 because ThisTimeLineID was not set correctly during
recovery. That was supposed to be fixed by commit 1148e22a82ed, so I
thought that it should be
On Wed, Aug 25, 2021 at 2:06 PM Alvaro Herrera wrote:
> You mean:
>
> LOG: automatic vacuum of table "regression.public.bmsql_order_line": index
> scans: 1
> pages: 0 removed, 8810377 remain, 0 skipped due to pins, 3044924 frozen
> tuples: 16819838 removed, 576364686 remain, 2207444 are dead
On 2021-Aug-25, Jakub Wartak wrote:
> In order to get reliable reproducer and get proper the fault injection
> instead of playing with really filling up fs, apparently one could
> substitute fd with fd of /dev/full using e.g. dup2() so that every
> write is going to throw this error too:
Oh,
On Wed, Aug 25, 2021 at 3:25 PM Zhihong Yu wrote:
>
>
> On Wed, Aug 25, 2021 at 11:42 AM Jacob Champion
> wrote:
>
>> On Tue, 2021-06-22 at 23:22 +, Jacob Champion wrote:
>> > On Fri, 2021-06-18 at 11:31 +0300, Heikki Linnakangas wrote:
>> > >
>> > > A few small things caught my eye in the
On Wed, Aug 25, 2021 at 11:42 AM Jacob Champion
wrote:
> On Tue, 2021-06-22 at 23:22 +, Jacob Champion wrote:
> > On Fri, 2021-06-18 at 11:31 +0300, Heikki Linnakangas wrote:
> > >
> > > A few small things caught my eye in the backend oauth_exchange
> function:
> > >
> > > > + /*
On Wed, Aug 25, 2021 at 5:41 AM Nitin Jadhav
wrote:
> > The new list bound binary search and related comparison support
> > function look a bit too verbose to me. I was expecting
> > partition_list_bsearch() to look very much like
> > partition_range_datum_bsearch(), but that is not the case.
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Wed, Aug 25, 2021 at 11:42 AM Nikolay Samokhvalov
> wrote:
> > The last two lines are also "*** usage" -- shouldn't the buffer numbers be
> > next to them?
>
> I agree that that would be better still -- but all the "usage" stuff
>
On 2021-Aug-25, Peter Geoghegan wrote:
> That way the overall structure starts with details of the physical
> data structures (the table and its indexes), then goes into buffers
>
> 1. Heap pages
> 2. Heap tuples
> 3. Index stuff
> 4. I/O timings (only when track_io_timing is on)
> 5. avg read
On Wed, Aug 25, 2021 at 1:33 PM Stephen Frost wrote:
> I don't have any particular issue with moving them.
What do you think of the plan I just outlined to Nikolay?
--
Peter Geoghegan
On Wed, Aug 25, 2021 at 11:42 AM Nikolay Samokhvalov
wrote:
> The last two lines are also "*** usage" -- shouldn't the buffer numbers be
> next to them?
I agree that that would be better still -- but all the "usage" stuff
together in one block.
And that leads me to another observation: The
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> log_autovacuum output looks like this (as of Postgres 14):
>
> LOG: automatic vacuum of table "regression.public.bmsql_order_line":
> index scans: 1
> pages: 0 removed, 8810377 remain, 0 skipped due to pins, 3044924 frozen
> tuples: 16819838
On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion wrote:
>
> Does there need to be any sanity check for overlapping ranges between
> the combining and fullwidth sets? The Unicode data on a dev's machine
> would have to be broken somehow for that to happen, but it could
> potentially go undetected
On Fri, Aug 20, 2021 at 07:55:13AM -0500, Justin Pryzby wrote:
> On Tue, Aug 17, 2021 at 06:30:18AM -0500, Justin Pryzby wrote:
> > On Mon, Aug 16, 2021 at 05:28:10PM -0500, Justin Pryzby wrote:
> > > On Mon, Aug 16, 2021 at 05:42:48PM -0400, Álvaro Herrera wrote:
> > > > On 2021-Aug-16, Álvaro
On Wed, Aug 25, 2021 at 10:34 AM Peter Geoghegan wrote:
> It would be a lot clearer if the "buffer usage" line was simply moved
> down. I think that it should appear after the lines that are specific
> to the table's indexes -- just before the "avg read rate" line. That
> way we'd group the
On 8/25/21, 11:01 AM, "Fujii Masao" wrote:
> If LogwrtResult.Flush >= EndPos, which means that another process already
> has flushed the record concurrently and updated XLogCtl->LogwrtResult.Flush.
> This situation also means that that another process called
>
On 8/25/21, 5:33 AM, "alvhe...@alvh.no-ip.org" wrote:
> On 2021-Aug-24, Bossart, Nathan wrote:
>
>> If moving RegisterSegmentBoundary() is sufficient to prevent the flush
>> pointer from advancing before we register the boundary, I bet we could
>> also remove the WAL writer nudge.
>
> Can you
On 2021/08/24 4:55, alvhe...@alvh.no-ip.org wrote:
On 2021-Aug-23, Bossart, Nathan wrote:
Ah, okay. BTW the other changes you mentioned made sense to me.
Thanks. I've pushed this now to all live branches.
Thanks a lot!
+ /*
+* There's a chance that the
On Mon, Aug 23, 2021 at 5:55 PM Peter Geoghegan wrote:
> Right now my prototype has a centralized table in shared memory, with
> a hash table. One entry per relation, generally multiple freelists per
> relation. And with per-freelist metadata such as owner and original
> leader backend XID
On 2021-Aug-25, Magnus Hagander wrote:
> The thing we need the PGDLLIMPORT definition for is to *import* them
> on the other end?
Oh ... so modules that are willing to cheat can include their own
declarations of the variables they need, and mark them __declspec
(dllimport)?
--
Álvaro Herrera
log_autovacuum output looks like this (as of Postgres 14):
LOG: automatic vacuum of table "regression.public.bmsql_order_line":
index scans: 1
pages: 0 removed, 8810377 remain, 0 skipped due to pins, 3044924 frozen
tuples: 16819838 removed, 576364686 remain, 2207444 are dead but not
yet
On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion wrote:
>
> On Fri, 2021-08-20 at 13:05 -0400, John Naylor wrote:
> > On Thu, Aug 19, 2021 at 8:05 PM Jacob Champion
wrote:
> > > I guess it just depends on what the end result looks/performs like.
> > > We'd save seven hops or so in the worst case?
On Wed, Aug 25, 2021 at 09:50:13AM -0400, Tom Lane wrote:
> Fujii Masao writes:
> > When I applied the patch to the master, I found that the table entries for
> > those function were added into the table for aclitem functions in the docs.
> > I think this is not valid position and needs to be
Esteban Zimanyi writes:
> However, I continuously receive at a random step in the process the
> following error in the log file
> 2021-08-25 16:48:13.608 CEST [22375] LOG: received fast shutdown request
This indicates that something sent the postmaster SIGINT.
You need to look around for
Hello
While executing the regression tests for MobilityDB I load a predefined
database on which I run the tests and then compare the results obtained
with those expected. All the tests are driven by the following bash file
https://github.com/MobilityDB/MobilityDB/blob/develop/test/scripts/test.sh
On Mon, 15 Feb 2021 at 17:01, Finnerty, Jim wrote:
>
> We are applying the Babelfish commits to the REL_12_STABLE branch now, and
> the plan is to merge them into the REL_13_STABLE and master branch ASAP after
> that. There should be a publicly downloadable git repository before very
> long.
On Wed, Aug 25, 2021 at 4:41 PM Tom Lane wrote:
>
> Magnus Hagander writes:
> > On Wed, Aug 25, 2021 at 4:06 PM Robert Haas wrote:
> >> It does tend to be controversial, but I think that's basically only
> >> because Tom Lane has reservations about it. I think if Tom dropped his
> >> opposition
Magnus Hagander writes:
> On Wed, Aug 25, 2021 at 4:06 PM Robert Haas wrote:
>> It does tend to be controversial, but I think that's basically only
>> because Tom Lane has reservations about it. I think if Tom dropped his
>> opposition to this, nobody else would really care. And I think that
>>
On Wed, Aug 25, 2021 at 4:06 PM Robert Haas wrote:
>
> On Tue, Aug 24, 2021 at 5:06 PM Chapman Flack wrote:
> > The thing is, I think I have somewhere a list of all the threads on this
> > topic that I've read through since the first time I had to come with my own
> > hat in hand asking for a
Hello all,
I am going to refactor Greenplum backtraces for error messages and want to make
it more compatible with PostgreSQL code. Backtraces in PostgreSQL were
introduced by 71a8a4f6e36547bb060dbcc961ea9b57420f7190 commit (original
discussion
On Wed, Aug 25, 2021 at 1:48 AM Michael Paquier wrote:
> On Mon, Aug 23, 2021 at 03:39:15PM -0400, Robert Haas wrote:
> > On Mon, Aug 23, 2021 at 3:03 PM Andrew Dunstan wrote:
> >> OK, I count 3 in favor of changing to PgTest::Cluster, 1 against,
> >> remainder don't care.
> >
> > I'd have gone
On Tue, Aug 24, 2021 at 5:06 PM Chapman Flack wrote:
> The thing is, I think I have somewhere a list of all the threads on this
> topic that I've read through since the first time I had to come with my own
> hat in hand asking for a PGDLLIMPORT on something, years ago now, and
> I don't think I
On Wed, Aug 25, 2021 at 11:17 PM Amit Kapila wrote:
>
> On Wed, Aug 25, 2021 at 6:10 PM Masahiko Sawada wrote:
> >
> > I did a quick check with the following tap test code:
> >
> > $node_publisher->poll_query_until('postgres',
> > qq(
> > select 1 != foo.column1
Peter Eisentraut writes:
> While trying to refactor the node support in various ways, the Value
> node is always annoying.
[…]
> This change removes the Value struct and node type and replaces them
> by separate Integer, Float, String, and BitString node types that are
> proper node types and
On Mon, Aug 23, 2021 at 11:04 PM Kyotaro Horiguchi
wrote:
> At Mon, 23 Aug 2021 18:52:17 -0400, Alvaro Herrera
> wrote in
> > I'd also like to have tests. That seems moderately hard, but if we had
> > WAL-molasses that could be used in walreceiver, it could be done. (It
> > sounds easier to
Fujii Masao writes:
> When I applied the patch to the master, I found that the table entries for
> those function were added into the table for aclitem functions in the docs.
> I think this is not valid position and needs to be moved to the proper one
> (maybe the table for system catalog
On Wed, Aug 25, 2021 at 9:20 AM Peter Eisentraut
wrote:
> This change removes the Value struct and node type and replaces them
> by separate Integer, Float, String, and BitString node types that are
> proper node types and structs of their own and behave mostly like
> normal node types.
+1. I
On Wed, Aug 25, 2021 at 5:36 AM Greg Nancarrow wrote:
> I've attached an updated patch, hopefully more along the lines that
> you were thinking of.
LGTM. Committed and back-patched to v10 and up. In theory the same bug
exists in 9.6, but you'd have to have third-party code using the
parallel
On 2021-Aug-25, Michael Paquier wrote:
> On Tue, Aug 24, 2021 at 12:01:33PM +0200, Peter Eisentraut wrote:
> > While analyzing this again, I think I found an existing mistake. The
> > handling of RELKIND_PARTITIONED_INDEX in RelationGetNumberOfBlocksInFork()
> > seems to be misplaced. See
On 2021/07/14 14:45, Laurenz Albe wrote:
On Wed, 2021-07-14 at 14:43 +0900, Ian Lawrence Barwick wrote:
Hi
The description for "pg_database" [1] mentions the function
"pg_encoding_to_char()", but this is not described anywhere in the docs. Given
that that it (and the corresponding
While trying to refactor the node support in various ways, the Value
node is always annoying.
The Value node struct is a weird construct. It is its own node type,
but most of the time, it actually has a node type of Integer, Float,
String, or BitString. As a consequence, the struct name and
On Wed, Aug 25, 2021 at 6:10 PM Masahiko Sawada wrote:
>
> I did a quick check with the following tap test code:
>
> $node_publisher->poll_query_until('postgres',
> qq(
> select 1 != foo.column1 from (values(0), (1)) as foo;
> ));
>
> The query returns {t, f} but
On Wed, Aug 25, 2021 at 5:54 PM Ajin Cherian wrote:
>
> On Wed, Aug 25, 2021 at 9:32 PM Masahiko Sawada wrote:
>
> >
> > IIUC the query[1] used for polling returns two rows in this case: {t,
> > f} or {f, t}. But did poll_query_until() returned OK in this case even
> > if we expected one row of
On Sat, Aug 14, 2021 at 3:02 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> On 13.08.21 04:59, Amit Kapila wrote:
> >> Even if we drop all tables added to the publication from it, 'pubkind'
> >> doesn't go back to 'empty'. Is that intentional behavior? If we do
> >> that, we
On Wed, Aug 25, 2021 at 9:23 PM Amit Kapila wrote:
>
> On Wed, Aug 25, 2021 at 5:02 PM Masahiko Sawada wrote:
> >
> > On Wed, Aug 25, 2021 at 6:53 PM Ajin Cherian wrote:
> > >
> > > On Wed, Aug 25, 2021 at 5:43 PM Ajin Cherian wrote:
> > > >
> > > > On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila
On 2021-Aug-24, Bossart, Nathan wrote:
> If moving RegisterSegmentBoundary() is sufficient to prevent the flush
> pointer from advancing before we register the boundary, I bet we could
> also remove the WAL writer nudge.
Can you elaborate on this? I'm not sure I see the connection.
> Another
On Wed, Aug 25, 2021 at 9:32 PM Masahiko Sawada wrote:
>
> IIUC the query[1] used for polling returns two rows in this case: {t,
> f} or {f, t}. But did poll_query_until() returned OK in this case even
> if we expected one row of 't'? My guess of how this issue happened is:
>
> 1. the first
On Wed, Aug 25, 2021 at 5:02 PM Masahiko Sawada wrote:
>
> On Wed, Aug 25, 2021 at 6:53 PM Ajin Cherian wrote:
> >
> > On Wed, Aug 25, 2021 at 5:43 PM Ajin Cherian wrote:
> > >
> > > On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Wed, Aug 25, 2021 at 8:00 AM Ajin
On Tue, Aug 24, 2021 at 3:55 PM Dilip Kumar wrote:
>
> On Tue, Aug 24, 2021 at 12:26 PM Amit Kapila wrote:
>
The first patch looks good to me. I have made minor changes to the
attached patch. The changes include: fixing compilation warning, made
some comment changes, ran pgindent, and few other
On Wed, Aug 25, 2021 at 1:21 AM Noah Misch wrote:
> Sounds good. I think the log message is the optimal place:
Looks awesome.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi Álvaro, -hackers,
> I attach the patch with the change you suggested.
I've gave a shot to to the v02 patch on top of REL_12_STABLE (already including
5065aeafb0b7593c04d3bc5bc2a86037f32143fc). Previously(yesterday) without the
v02 patch I was getting standby corruption always via
On Wed, Aug 25, 2021 at 6:53 PM Ajin Cherian wrote:
>
> On Wed, Aug 25, 2021 at 5:43 PM Ajin Cherian wrote:
> >
> > On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila wrote:
> > >
> > > On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian wrote:
> > > >
> > > > On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila
> If a .ready file is created out of order, the directory scan logic
> will pick it up about as soon as possible based on its priority. If
> the archiver is keeping up relatively well, there's a good chance such
> a file will have the highest archival priority and will be picked up
> the next
On Wed, Aug 25, 2021 at 5:43 PM Ajin Cherian wrote:
>
> On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila wrote:
> >
> > On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian wrote:
> > >
> > > On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila
> > > wrote:
> > >
> > > > But will poll function still poll or exit?
On Wed, Aug 25, 2021 at 1:37 AM Robert Haas wrote:
>
> I guess I was thinking more of rejiggering things so that we save the
> results of each RestoreSnapshot() call in a local variable, e.g.
> asnapshot and tsnapshot. And then I think we could just
> RestoreTransactionSnapshot() on whichever one
On Wed, Aug 25, 2021 at 10:57 AM Amit Kapila wrote:
>
> On Wed, Aug 25, 2021 at 5:52 AM Euler Taveira wrote:
> >
> > On Tue, Aug 24, 2021, at 4:46 AM, Peter Smith wrote:
> >
> > Anyway, I have implemented the suggested cache change because I agree
> > it is probably theoretically superior, even
Hi,
On 2021-08-25 12:51:58 +0900, Michael Paquier wrote:
> I was looking at this WIP patch, and plugging in the connection
> statistics to the table-access statistics looks like the wrong
> abstraction to me. I find much cleaner the approach of HEAD to use a
> separate API to report this
Hi,
On 2021-08-20 14:27:20 -0500, Justin Pryzby wrote:
> On Tue, Aug 17, 2021 at 02:14:20AM -0700, Andres Freund wrote:
> > Doubling the number of UDP messages in common workloads seems also
> > problematic
> > enough that it should be addressed for 14. It increases the likelihood of
> >
On Mon, Aug 23, 2021 at 11:16 PM vignesh C wrote:
>
> On Tue, Aug 17, 2021 at 6:55 PM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > On Tue, Aug 17, 2021 at 6:40 AM Peter Smith wrote:
> > >> On Mon, Aug 16, 2021 at 11:31 PM Tom Lane wrote:
> > >>> Abstractly it'd be
> > >>>
> > >>>
On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila wrote:
>
> On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian wrote:
> >
> > On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila
> > wrote:
> >
> > > But will poll function still poll or exit? Have you tried that?
> >
> > I have forced that condition with a
On Mon, Mar 15, 2021 at 03:05:24PM +0800, Erica Zhang wrote:
> This way the same query can be reused for both older versions and current
> version.
> Yep, it's neater to use the query as you suggested. Thanks!
>
> Also, can you register your patch for the next commitfest at
>
I reviewed the v14-0001 patch.
All my previous comments have been addressed.
Apply / build / test was all OK.
--
More review comments:
1. Params names in the function declarations should match the rest of the code.
1a. src/include/replication/logical.h
@@ -26,7 +26,8 @@ typedef
On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian wrote:
>
> On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila wrote:
>
> > But will poll function still poll or exit? Have you tried that?
>
> I have forced that condition with a changed query and found that the
> poll will not exit in case of a NULL
91 matches
Mail list logo
