On Fri, Aug 6, 2021 at 1:39 PM Amit Kapila wrote:
>
> On Fri, Aug 6, 2021 at 5:09 AM Masahiko Sawada wrote:
> >
> > On Thu, Aug 5, 2021 at 11:40 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > > To summary, I think that what we want to do in DROP SUBSCRIPTION cases
> > > > is to
> > > > drop r
Hi,
On Thu, Aug 5, 2021, at 22:20, Yura Sokolov wrote:
> Andres Freund писал 2021-08-06 06:49:
> > Hi,
> >
> > On 2021-08-06 06:43:55 +0300, Yura Sokolov wrote:
> >> Why don't use simplehash or something like that? Open-addressing
> >> schemes
> >> show superior cache locality.
> >
> > I though
On Fri, Aug 6, 2021 at 10:09 AM Amit Kapila wrote:
>
> On Fri, Aug 6, 2021 at 5:09 AM Masahiko Sawada wrote:
> >
>
> But, isn't this happening because of your suggestion to compare the
> current set of relations with relations from publications that doesn't
> need to be removed? Do we have better
Andres Freund писал 2021-08-06 06:49:
Hi,
On 2021-08-06 06:43:55 +0300, Yura Sokolov wrote:
Why don't use simplehash or something like that? Open-addressing
schemes
show superior cache locality.
I thought about that as well - but it doesn't really resolve the
question of
what we want to sto
At Fri, 6 Aug 2021 02:34:24 +, "Bossart, Nathan"
wrote in
> On 8/5/21, 6:26 PM, "Kyotaro Horiguchi" wrote:
> > It works the current way always at the first iteration of
> > pgarch_ArchiveCopyLoop() becuse in the last iteration of
> > pgarch_ArchiveCopyLoop(), pgarch_readyXlog() erases the l
On Fri, Aug 6, 2021 at 5:09 AM Masahiko Sawada wrote:
>
> On Thu, Aug 5, 2021 at 11:40 PM houzj.f...@fujitsu.com
> wrote:
> >
> > > To summary, I think that what we want to do in DROP SUBSCRIPTION cases is
> > > to
> > > drop relations from pg_subscription_rel that are no longer included in
> >
On Thu, Aug 05, 2021 at 03:06:54PM +0200, Tomas Vondra wrote:
> On 8/5/21 8:39 AM, Andrey Borodin wrote:
> >>...
> >>
> >>Early commitfests recognized a rule that patch authors owed one review per
> >>patch registered in the commitfest. If authors were holding to that, then
> >>both submissions an
Hi,
On 2021-08-06 06:43:55 +0300, Yura Sokolov wrote:
> Why don't use simplehash or something like that? Open-addressing schemes
> show superior cache locality.
I thought about that as well - but it doesn't really resolve the question of
what we want to store in-line in the hashtable and what not
Andres Freund писал 2021-08-05 23:12:
Hi,
On 2021-08-05 12:27:49 -0400, John Naylor wrote:
On Wed, Aug 4, 2021 at 3:44 PM Andres Freund
wrote:
> On 2021-08-04 12:39:29 -0400, John Naylor wrote:
> > typedef struct cc_bucket
> > {
> > uint32 hashes[4];
> > catctup *ct[4];
> > dlist_head;
Hi,
When testing EXEC_BACKEND on linux I see occasional test failures as long as I
don't disable ASLR. There's a code comment to that effect:
* If testing EXEC_BACKEND on Linux, you should run this as root before
* starting the postmaster:
*
* echo 0 >/proc/sys
Dean Rasheed writes:
> On Thu, 5 Aug 2021 at 17:04, Tom Lane wrote:
>> It looks like castoroides is not happy with this patch:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides&dt=2021-08-01%2008%3A52%3A43
> Hmm, there's something very weird going on there.
Yeah. I tried t
Hi,
On 2021-08-05 20:02:02 -0400, Tom Lane wrote:
> Andres Freund writes:
> > First, what do we want to do with BGWORKER_SHMEM_ACCESS? I'm inclined to
> > treat
> > it as a required flag going forward.
>
> +1
>
> > The second question is what we want to do in the backbranches. I think the
> >
At Thu, 5 Aug 2021 21:53:30 +0530, Dipesh Pandit
wrote in
> > I'm not sure. I think we need the value to be accurate during
> > recovery, so I'm not sure whether replayEndTLI would get us there.
> > Another approach might be to set ThisTimeLineID on standbys also.
> > Actually just taking a fast
On 8/5/21, 6:26 PM, "Kyotaro Horiguchi" wrote:
> It works the current way always at the first iteration of
> pgarch_ArchiveCopyLoop() becuse in the last iteration of
> pgarch_ArchiveCopyLoop(), pgarch_readyXlog() erases the last
> anticipated segment. The shortcut works only when
> pgarch_Archive
At Tue, 3 Aug 2021 20:46:57 +, "Bossart, Nathan"
wrote in
> + /*
> + * Perform a full directory scan to identify the next log segment. There
> + * may be one of the following scenarios which may require us to
> perform a
> + * full directory scan.
> + *
> + * 1.
I wrote:
> Hm. I thought that this might be an old issue, but I'm not seeing the
> crash in pre-v14 branches. That means it's some bug introduced in
> the performance improvements I did a few months ago. Open item added.
git bisect says the trouble started with
ea1268f6301cc7adce571cc9c5ebe8d9
Andres Freund writes:
> First, what do we want to do with BGWORKER_SHMEM_ACCESS? I'm inclined to treat
> it as a required flag going forward.
+1
> The second question is what we want to do in the backbranches. I think the
> reasonable options are to do nothing, or to make !BGWORKER_SHMEM_ACCESS
On Thu, Aug 5, 2021 at 11:40 PM houzj.f...@fujitsu.com
wrote:
>
> On Thursday, August 5, 2021 1:09 PM Masahiko Sawada
> wrote
> > I've reviewed v2 patch. Here are some comments:
> >
> > + if (type == ALTER_SUBSCRIPTION_SET_PUBLICATION ||
> > + type == ALTER_SUBSCRIPTION_R
On Sun, Aug 1, 2021 at 5:41 PM Thomas Munro wrote:
> On Fri, Jul 30, 2021 at 12:34 PM John Naylor
> wrote:
> > I got around to getting a benchmark together to serve as a starting point.
> > I based it off something I got from the archives, but don't remember where
> > (I seem to remember Tomas
Mark Dilger writes:
> I have now found lots of cases of this failure. I *believe* the
> backreference is always greater than 1, and it is always in a capture group
> which then has the {0} or {0,0} applied to it.
Hm. I thought that this might be an old issue, but I'm not seeing the
crash in p
Hi,
On 2021-08-02 15:34:07 -0400, Alvaro Herrera wrote:
> Ah, that makes sense. That doesn't sound super fragile, but it is odd
> and it's probably a good argument for removing the feature, particularly
> since nobody seems to be using it.
ISTM we concluded that we should remove unconnected work
> On Aug 5, 2021, at 12:35 AM, Simon Riggs wrote:
>
> Noting that all constraints have been removed, not just the ones
> wholly dependent on dropped columns.
I don't find this all that surprising. If CHECK (a > 5 AND b IS NOT NULL AND c
> 10) is really meant as three independent checks, it
> On Aug 5, 2021, at 3:15 PM, Tom Lane wrote:
>
> I don't immediately see what's different about your failing case
> versus the not-failing ones.
I have now found lots of cases of this failure. I *believe* the backreference
is always greater than 1, and it is always in a capture group which
Mark Dilger writes:
> +select '' ~ '(())(\2){0}';
> +server closed the connection unexpectedly
> Any ideas?
Huh. This seems like some deficiency in the part of parseqatom
starting with
/* annoying special case: {0} or {0,0} cancels everything */
if (m == 0 && n == 0)
but I do
> On Aug 5, 2021, at 7:36 AM, Tom Lane wrote:
>
> Probably should add more cases...
The patch triggers an assertion that master does not:
+select 'azrlfkjbjgidgryryiglcabkgqluflu' !~ '(.(.)((.)))((?:(\3)))';
+server closed the connection unexpectedly
+ This probably means the server termin
> On Aug 5, 2021, at 1:38 PM, Mark Dilger wrote:
>
> +select 'vyrlvyrlwvqko' ~ '(?:(?:((.((\2)\1.){0,0}?';
I've boiled it down a bit more:
+select '' ~ '()\1{0}';
+ ?column?
+--
+ t
+(1 row)
+
+select '' ~ '()(\1){0}';
+ ?column?
+--
+ t
+(1 row)
+
+select '' ~ '(())\2{
Tom,
while testing your patch in [1], I stumbled upon the following assert in
master, without your patch applied:
+select 'vyrlvyrlwvqko' ~ '(?:(?:((.((\2)\1.){0,0}?';
+server closed the connection unexpectedly
+ This probably means the server terminated abnormally
+ before or while proc
On 8/5/21 12:48 PM, Platon Pronko wrote:
> Hi!
I also find this annoying and would be happy to be rid of it.
>>>
>>> Have you tried "\pset format wrapped"? Pavel suggested it, and it
>>> solved most of the problem for me, for example.
>>
>> Yes, but it changes the data line output. Ideally,
On 8/5/21 2:25 PM, Pavel Stehule wrote:
>
>
> čt 5. 8. 2021 v 18:48 odesílatel Platon Pronko
> mailto:platon7pro...@gmail.com>> napsal:
>
> Hi!
> >>> I also find this annoying and would be happy to be rid of it.
> >>
> >> Have you tried "\pset format wrapped"? Pavel suggested it,
Hi,
On 2021-08-05 12:27:49 -0400, John Naylor wrote:
> On Wed, Aug 4, 2021 at 3:44 PM Andres Freund wrote:
> > On 2021-08-04 12:39:29 -0400, John Naylor wrote:
> > > typedef struct cc_bucket
> > > {
> > > uint32 hashes[4];
> > > catctup *ct[4];
> > > dlist_head;
> > > };
> >
> > I'm not con
On Thu, Aug 5, 2021 at 08:35:46AM +0100, Simon Riggs wrote:
> If we drop a column we cascade that drop to all indexes and all
> constraints that mention that column, even if they include other
> columns also. We might expect that indexes should be dropped
> automatically, but the latter behavior f
Hi,
On 2021-08-03 16:50:24 +0900, Kyotaro Horiguchi wrote:
> At Mon, 2 Aug 2021 09:41:24 -0700, Andres Freund wrote in
> > - PostgresMainSingle() should probably not be in postgres.c. We could put it
> > into postinit.c or ..?
>
> PostgresMainSingle() looks like the single-process version of
>
Platon Pronko wrote:
> Maybe we can avoid making the header line longer than terminal width
> for \pset border 0 and \pset border 1? We already have terminal
> width calculated. Please see attached a patch with the proposed
> implementation.
+1 for doing something against these long lines
Hi,
Thanks Robert, Horiguchi-san for looking.
On 2021-08-04 16:34:52 -0400, Robert Haas wrote:
> On Mon, Aug 2, 2021 at 12:41 PM Andres Freund wrote:
> > - AuxiliaryProcessMain() is used for two independent tasks: Start bootstrap
> > /
> > checker mode and starting auxiliary processes. In HEA
čt 5. 8. 2021 v 20:56 odesílatel Platon Pronko
napsal:
> > it can be a fully new format - designed for simple copy from terminal.
> Some
> > like
> >
> > == record: 10 ==
> > proname
> > left
> > prosrc
> > $lalalal
> > ewqrwqerw
> > ew
it can be a fully new format - designed for simple copy from terminal. Some
like
== record: 10 ==
proname
left
prosrc
$lalalal
ewqrwqerw
ewqrwqerqrewq
$
===
no, it was proposed for psql
How is this better than "copy (..
čt 5. 8. 2021 v 20:48 odesílatel Platon Pronko
napsal:
> Hi!
>
> >> I don't think that would be a good idea. If somebody really just needs
> to
> >> copy,
> >> then wrapping the query in "copy (...) to stdout" already works nicely,
> >> no need to create a special mode just for that.
> >>
> >
> >
Hi!
I don't think that would be a good idea. If somebody really just needs to
copy,
then wrapping the query in "copy (...) to stdout" already works nicely,
no need to create a special mode just for that.
It is working well, but it is copy to file, not copy to clipboard.
Maybe I misunderstoo
čt 5. 8. 2021 v 20:30 odesílatel Platon Pronko
napsal:
> Hi!
>
> > I also find this annoying and would be happy to be rid of it.
>
> Have you tried "\pset format wrapped"? Pavel suggested it, and it
> solved most of the problem for me, for example.
> >>>
> >>> Yes, but it chang
Hi!
I also find this annoying and would be happy to be rid of it.
Have you tried "\pset format wrapped"? Pavel suggested it, and it
solved most of the problem for me, for example.
Yes, but it changes the data line output. Ideally, you should be able
to modify these independently.
I agree,
On Thu, 5 Aug 2021 at 17:04, Tom Lane wrote:
>
> It looks like castoroides is not happy with this patch:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides&dt=2021-08-01%2008%3A52%3A43
>
> Maybe there's some hidden C99 dependency in what you did?
> Although pademelon, which is
čt 5. 8. 2021 v 18:48 odesílatel Platon Pronko
napsal:
> Hi!
> >>> I also find this annoying and would be happy to be rid of it.
> >>
> >> Have you tried "\pset format wrapped"? Pavel suggested it, and it
> >> solved most of the problem for me, for example.
> >
> > Yes, but it changes the data li
Hi!
I also find this annoying and would be happy to be rid of it.
Have you tried "\pset format wrapped"? Pavel suggested it, and it
solved most of the problem for me, for example.
Yes, but it changes the data line output. Ideally, you should be able
to modify these independently.
I agree,
On Wed, Aug 4, 2021 at 3:44 PM Andres Freund wrote:
> On 2021-08-04 12:39:29 -0400, John Naylor wrote:
> > typedef struct cc_bucket
> > {
> > uint32 hashes[4];
> > catctup *ct[4];
> > dlist_head;
> > };
>
> I'm not convinced that the above the right idea though. Even if the hash
> matches, y
On 8/5/21 12:04 PM, Platon Pronko wrote:
> Hi!
>
>> I also find this annoying and would be happy to be rid of it.
>
> Have you tried "\pset format wrapped"? Pavel suggested it, and it
> solved most of the problem for me, for example.
Yes, but it changes the data line output. Ideally, you should
> I'm not sure. I think we need the value to be accurate during
> recovery, so I'm not sure whether replayEndTLI would get us there.
> Another approach might be to set ThisTimeLineID on standbys also.
> Actually just taking a fast look at the code I'm not quite sure why
> that isn't happening alrea
On Thu, Aug 5, 2021 at 6:28 AM Simon Riggs wrote:
> Hmm, there is no information in WAL to describe the line pointers
> being truncated by PageTruncateLinePointerArray(). We just truncate
> every time we see a XLOG_HEAP2_VACUUM record and presume it does the
> same thing as the original change.
>
Dean Rasheed writes:
> On Thu, 22 Jul 2021 at 16:19, Dean Rasheed wrote:
>> Thanks for looking. Barring any further comments, I'll push this in a few
>> days.
> So I have been testing this a lot over the last couple of days, and I
> have concluded that the patch works well as far as it goes, bu
Hi!
I also find this annoying and would be happy to be rid of it.
Have you tried "\pset format wrapped"? Pavel suggested it, and it solved most
of the problem for me, for example.
Best regards,
Platon Pronko
On 8/5/21 6:56 AM, Pavel Stehule wrote:
> Hi
>
> čt 5. 8. 2021 v 12:36 odesílatel Platon Pronko
> mailto:platon7pro...@gmail.com>> napsal:
>
> In expanded mode psql calculates the width of the longest field in
> all the output rows,
> and prints the header line according to it. This o
On 8/5/21 10:39 AM, Robert Haas wrote:
> On Thu, Aug 5, 2021 at 9:43 AM Andrew Dunstan wrote:
>> On 8/4/21 6:15 PM, Tom Lane wrote:
>>> Here's a little finger exercise that improves a case that's bothered me
>>> for awhile. In a POSIX regexp, parentheses cause capturing by default;
>>> you have
čt 5. 8. 2021 v 16:50 odesílatel Platon Pronko
napsal:
> Hi!
>
> > pspg supports copy cell to clipboard - you can copy complete cell
> >
> > but I am not sure if it is working well in extended mode. This mode is
> not
> > extra tested in pspg
>
> Thanks for the tip!
>
> I tried it out, in non-ext
Robert Haas writes:
> Well, I consider myself a pretty fair perl programmer, and I know
> there's a way to do that, but I never do it, and I would have had to
> look up the exact syntax. So +1 from me for anything automatic that
> avoids paying the overhead in some cases.
That's my feeling about
On Thursday, August 5, 2021 1:09 PM Masahiko Sawada
wrote
> I've reviewed v2 patch. Here are some comments:
>
> + if (type == ALTER_SUBSCRIPTION_SET_PUBLICATION ||
> + type == ALTER_SUBSCRIPTION_REFRESH)
> + drop_table = !bsearch(&relid, pubrel_local_oids,
>
On Thu, Aug 5, 2021 at 9:43 AM Andrew Dunstan wrote:
> On 8/4/21 6:15 PM, Tom Lane wrote:
> > Here's a little finger exercise that improves a case that's bothered me
> > for awhile. In a POSIX regexp, parentheses cause capturing by default;
> > you have to write the very non-obvious "(?:...)" if
čt 5. 8. 2021 v 16:32 odesílatel Platon Pronko
napsal:
> Hi!
>
> My apologies - I was using pspg incorrectly. If it's called via the pipe
> then all the column wrapping is ignored, and that's why I couldn't
> reproduce
> the issues. If instead pspg is used via "\setenv PAGER pspg", then I
> indee
Andrew Dunstan writes:
> I'm a bit worried about how you'll keep track of back-ref numbering
> since back-refs only count capturing groups, and you're silently turning
> a capturing group into a non-capturing group.
They're already numbered at this point, and we aren't changing the numbers
of the
On Tue, Aug 3, 2021 at 2:52 PM Tomas Vondra
wrote:
> How would this be different from the CFM just rejecting patches? It does
> not matter if there's an explicit number of patches that we allow to be
> moved to the next CF - someone still needs to make the decision, and I
> agree with Tom it proba
On Thu, Aug 5, 2021 at 7:41 AM Nitin Jadhav
wrote:
> This seems a little confusing. As we are setting
> last_startup_progress_timeout = now and then calling
> reset_startup_progress_timeout() which will calculate the next_time
> based on the value of last_startup_progress_timeout initially and
> c
On 8/5/21 8:49 AM, Tomas Vondra wrote:
> On 8/5/21 11:27 AM, Michael Banck wrote:
>> On Tue, Aug 03, 2021 at 11:55:50AM -0400, Bruce Momjian wrote:
>>> On Tue, Aug 3, 2021 at 04:53:40PM +0100, Simon Riggs wrote:
There are 273 patches in the queue for the Sept Commitfest already, so
it
čt 5. 8. 2021 v 15:30 odesílatel Platon Pronko
napsal:
> Hi!
>
> > a) with line cursor
>
> Tried in different configurations, seems that line cursor works fine.
>
> > b) format detection - I try to detect the header line - and I expect this
> > line has the most length of all lines. I use a line
On Thu, Aug 5, 2021 at 7:39 AM Dipesh Pandit wrote:
> Yes, we can avoid storing another copy of information. We can
> use XLogCtl's ThisTimeLineID on Primary. However,
> XLogCtl's ThisTimeLineID is not set to the current timeline ID on
> Standby server. It's value is set to '0'. Can we use XLogCtl
On 8/4/21 6:15 PM, Tom Lane wrote:
> Here's a little finger exercise that improves a case that's bothered me
> for awhile. In a POSIX regexp, parentheses cause capturing by default;
> you have to write the very non-obvious "(?:...)" if you don't want the
> matching substring to be reported by th
On Wed, 4 Aug 2021 at 15:39, Robert Haas wrote:
>
> On Tue, Aug 3, 2021 at 8:44 PM Peter Geoghegan wrote:
> > This time it's quite different: we're truncating the line pointer
> > array during pruning. Pruning often occurs opportunistically, during
> > regular query processing. In fact I'd say th
On 8/4/21 7:21 PM, Tomas Vondra wrote:
> On 8/5/21 1:05 AM, Andres Freund wrote:
>
>>
>>> The first one seems quite efficient in how it encodes the length
>>> into very
>>> few bits (which matters especially for small values). It's designed for
>>> integers with 1B, 2B, 4B or 8B, but it can be ex
On 8/5/21 8:39 AM, Andrey Borodin wrote:
...
Early commitfests recognized a rule that patch authors owed one review per
patch registered in the commitfest. If authors were holding to that, then
both submissions and reviews would slow during vacations, but the neglected
fraction of the commitfes
On 8/5/21 11:27 AM, Michael Banck wrote:
On Tue, Aug 03, 2021 at 11:55:50AM -0400, Bruce Momjian wrote:
On Tue, Aug 3, 2021 at 04:53:40PM +0100, Simon Riggs wrote:
There are 273 patches in the queue for the Sept Commitfest already, so
it seems clear the queue is not being cleared down each CF
čt 5. 8. 2021 v 13:14 odesílatel Platon Pronko
napsal:
> Hi!
>
> pspg looks nice :)
>
> > Your proposal breaks pspg
> >
> > https://github.com/okbob/pspg
>
> I tried the following (after the patch):
>
> ./psql template1 -c "select n, repeat('x', n) as long_column_name from
> unnest(array[42,210])
Thanks for the detailed explanation.
> +elapsed_ms = (seconds * 1000) + (useconds / 1000);
> +interval_in_ms = log_startup_progress_interval * 1000;
> +enable_timeout_after(LOG_STARTUP_PROGRESS_TIMEOUT,
> + (interval_in_ms - (elapsed_ms % interval_in_ms)));
>
>
Hi,
> I don't really understand why you are storing something in shared
> memory specifically for the archiver. Can't we use XLogCtl's
> ThisTimeLineID instead of storing another copy of the information?
Yes, we can avoid storing another copy of information. We can
use XLogCtl's ThisTimeLineID on
Hi
čt 5. 8. 2021 v 12:36 odesílatel Platon Pronko
napsal:
> In expanded mode psql calculates the width of the longest field in all the
> output rows,
> and prints the header line according to it. This often results in record
> header wrapping
> over several lines (see example below).
>
> This hu
In expanded mode psql calculates the width of the longest field in all the
output rows,
and prints the header line according to it. This often results in record header
wrapping
over several lines (see example below).
This huge record header is printed the same way before each record, even if al
On Wed, Aug 4, 2021 at 4:10 PM Amit Kapila wrote:
>
> On Tue, Aug 3, 2021 at 8:38 PM vignesh C wrote:
> >
> > Thanks for reporting this, this is fixed in the v18 patch attached.
> >
>
> I have started looking into this patch and below are some initial comments.
>
Few more comments:
=
Rebased.
v12-0002-Tests-to-replay-create-database-operation-on-sta.patch
Description: v12-0002-Tests-to-replay-create-database-operation-on-sta.patch
v12-0001-Support-node-initialization-from-backup-with-tab.patch
Description: v12-0001-Support-node-initialization-from-backup-with-tab.patch
On Tue, Jun 22, 2021 at 11:08 AM Paul Guo wrote:
>
> On Thu, Jun 17, 2021 at 3:19 PM Michael Paquier wrote:
> >
> > On Wed, Jun 02, 2021 at 05:02:10PM +0900, Michael Paquier wrote:
> > > On Wed, Jun 02, 2021 at 06:20:30PM +1200, Thomas Munro wrote:
> > > > The main thing I noticed was that Linux
Hi,
Based on the discussion in another thread[1], we plan to change the design like
the following:
allow users to specify a parallel-safety option for both partitioned and
non-partitioned relations but for non-partitioned relations if users didn't
specify, it would be computed automatically? If t
On Tue, Aug 03, 2021 at 11:55:50AM -0400, Bruce Momjian wrote:
> On Tue, Aug 3, 2021 at 04:53:40PM +0100, Simon Riggs wrote:
> > There are 273 patches in the queue for the Sept Commitfest already, so
> > it seems clear the queue is not being cleared down each CF as it was
> > before. We've been tr
Hello Fujii-san,
On Thu, 5 Aug 2021 16:16:48 +0900
Fujii Masao wrote:
>
>
> On 2021/08/01 14:50, Yugo NAGATA wrote:
> > When -C is not specified, the disconnection time is not measured even in
> > the patch for v14+. I don't think it is a problem because the
> > disconnection delay at the end
On Tuesday, August 3, 2021 3:49 PM Masahiko Sawada
wrote:
> I've attached new patches that incorporate all comments I got so far.
> Please review them.
Hi, I had a chance to look at the patch-set during my other development.
Just let me share some minor cosmetic things.
[1] unnatural wording ?
Hi Nagata-san,
Thank you for your reply.
> I'll investigate this more, but we may have to prohibit views on partitioned
> table and partitions.
I think this restriction is strict.
This feature is useful when the base table is large and partitioning is also
useful in such case.
I have several
On 2021/07/31 10:08, Fujii Masao wrote:
Barring any objection, I will commit the patch.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Thanks, for Your advice Tom.
I tried writing to temp file followed by mv, but it didn't bring the
desired effect.
I am going to follow Your minimal approach and I'll build src/port,
src/common, src/interfaces/libpq, then src/interfaces/ecpg, in series.
Regards,
-Filip-
st 4. 8. 2021 v 15:46
Hi WenJing
Thanks for the feedback,
I have tested the code, it seems okay, and regression tests got pass
and I have reviewed the code, and I don't find any issue anymore
Hello all
Review and comments for the patches V51 is welcome.
if there is no feedback, I'm going to changed the status
If we drop a column we cascade that drop to all indexes and all
constraints that mention that column, even if they include other
columns also. We might expect that indexes should be dropped
automatically, but the latter behavior for constraints seems like a
bug, since it can silently remove constra
At Thu, 5 Aug 2021 05:15:04 +, "Bossart, Nathan"
wrote in
> On 8/4/21, 9:05 PM, "Kyotaro Horiguchi" wrote:
> > By the way about the v3 patch,
> >
> > +#define InvalidXLogSegNo ((XLogSegNo) 0x)
> >
> > Like InvalidXLogRecPtr, the first valid segment number is 1 so we ca
On 2021/08/01 14:50, Yugo NAGATA wrote:
When -C is not specified, the disconnection time is not measured even in
the patch for v14+. I don't think it is a problem because the
disconnection delay at the end of benchmark almost doesn't affect the tps.
What about v13 or before? That is, in v13,
86 matches
Mail list logo
