On 2020/05/02 20:40, Amit Kapila wrote:
On Thu, Apr 30, 2020 at 7:46 PM Fujii Masao wrote:
On 2020/04/08 1:49, Fujii Masao wrote:
On 2020/04/07 20:21, David Steele wrote:
On 4/7/20 3:48 AM, Kyotaro Horiguchi wrote:
At Tue, 7 Apr 2020 12:15:00 +0900, Fujii Masao
wrote in
This doesn'
On Thu, 7 May 2020 at 03:28, Peter Geoghegan wrote:
>
> On Wed, May 6, 2020 at 2:28 AM Masahiko Sawada
> wrote:
> > I've attached the patch fixes this issue.
> >
> > With this patch, we don't skip only index cleanup phase when
> > performing an aggressive vacuum. The reason why I don't skip only
Hello Bruce,
* "DOCUMENT THE DEFAULT GENERATION METHOD"
=> The default is still to generate data client-side.
My point is that the docs are not clear about this.
Indeed.
Can you fix it?
Sure. Attached patch adds an explicit sentence about it, as it was only
hinted about in the default
Amit Kapila writes:
> Thanks, Juan and Davinder for verifying the latest patches. I think
> this patch is ready to commit unless someone else has any comments. I
> will commit and backpatch this early next week (probably on Monday)
> unless I see more comments.
Monday is a back-branch release wr
> 7 мая 2020 г., в 04:35, Bruce Momjian написал(а):
>
> On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
>>
>>
>>> 5 мая 2020 г., в 08:16, Bruce Momjian написал(а):
>>>
>>> I have committed the first draft of the PG 13 release notes. You can
>>> see them here:
>>>
>>>
On 2020/05/07 13:15, Fujii Masao wrote:
On 2020/05/02 11:29, Michael Paquier wrote:
On Thu, Apr 30, 2020 at 11:40:59PM +0900, Fujii Masao wrote:
Also the number of bytes can be added into and substracted from LSN using the
+(pg_lsn,numeric) and -(pg_lsn,numeric)
operators, respectively. Not
On Wed, May 6, 2020 at 11:01 PM Juan José Santamaría Flecha
wrote:
>
> On Wed, May 6, 2020 at 6:41 AM Amit Kapila wrote:
>>
>> On Wed, May 6, 2020 at 4:19 AM Juan José Santamaría Flecha
>> >
>> > I think that the definition of get_iso_localename() should be consistent
>> > across all versions, t
On Wed, May 06, 2020 at 12:17:03AM +0200, Juan José Santamaría Flecha wrote:
> Please forgive me if I am being too nitpicky, but I find the comments a
> little too verbose, a usage format might be more visual and easier to
> explain:
>
> Usage: build [[CONFIGURATION] COMPONENT]
>
> The options ar
On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote:
> On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
> > On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > > Allow skipping of WAL for new tables and indexes if wal_level is
> > > 'minimal' (Noah Misch)
> >
>
В Wed, 6 May 2020 21:23:57 -0300
Ranier Vilela пишет:
>
> The perl is:
> Win32 strawberry-perl 5.30.1.1
>
This perl would have problems when compiling PL/Perl (see my letter
about week ago), but it have no problems running various build scripts
for Postgres. I'm using it with MSVisualStudio 20
В Thu, 7 May 2020 09:14:33 +0900
Michael Paquier пишет:
> On Wed, May 06, 2020 at 03:58:15PM -0300, Ranier Vilela wrote:
> > Hacking pgbison.pl, to print PATH, shows that the path inside
> > pgbison.pl, returned to being the original, without the addition of
> > c:\perl\bin;c:\bin. my $out = $ENV
On Thu, May 07, 2020 at 09:48:35AM +0530, vignesh C wrote:
> I could not find any code reference to smgrdounlink, I feel it can be
> removed.
The last use of smgrdounlink() was b416691. I have just looked at
Debian Code Search and github, and could not find a hit with the
function being used in s
On 2020/05/03 1:59, Tomas Vondra wrote:
On Sat, May 02, 2020 at 12:55:00PM +0200, Tomas Vondra wrote:
On Sat, May 02, 2020 at 03:56:07PM +0900, Fujii Masao wrote:
...
Another thing I found is; pgstat_send_slru() should be called also by
other processes than backend? For example, since clo
On Wed, May 6, 2020 at 10:11 AM Amit Kapila wrote:
>
> > I think that the definition of get_iso_localename() should be consistent
> across all versions, that is HEAD like back-patched.
> >
>
> Fair enough. I have changed such that get_iso_localename is the same
> in HEAD as it is backbranch patc
On Thu, May 7, 2020 at 8:33 AM Peter Geoghegan wrote:
>
> I see that commit 33a94bae605edf3ceda6751916f0b1af3e88630a removed
> smgrdounlinkfork() because it was dead code. Should we also remove
> smgrdounlink() now? It also appears to be dead code.
>
I could not find any code reference to smgrdou
On 2020/05/07 11:21, Kyotaro Horiguchi wrote:
At Tue, 28 Apr 2020 12:56:19 +0900, Fujii Masao
wrote in
Yes. Attached is the updated version of the patch, which introduces
+(pg_lsn, numeric) and -(pg_lsn, numeric) operators.
To implement them, I added also numeric_pg_lsn() function that
conv
On 2020/05/02 11:29, Michael Paquier wrote:
On Thu, Apr 30, 2020 at 11:40:59PM +0900, Fujii Masao wrote:
Also the number of bytes can be added into and substracted from LSN using the
+(pg_lsn,numeric) and -(pg_lsn,numeric)
operators, respectively. Note that the calculated LSN should be in the
I see that commit 33a94bae605edf3ceda6751916f0b1af3e88630a removed
smgrdounlinkfork() because it was dead code. Should we also remove
smgrdounlink() now? It also appears to be dead code.
--
Peter Geoghegan
On Wed, May 6, 2020 at 12:19 AM Julien Rouhaud wrote:
>
> On Tue, May 5, 2020 at 12:44 PM Amit Kapila wrote:
> >
> > > >
> > > > Your patch looks mostly good to me. I have made slight modifications
> > > > which include changing the non-text format in show_wal_usage to use a
> > > > capital lett
At Tue, 28 Apr 2020 12:56:19 +0900, Fujii Masao
wrote in
> Yes. Attached is the updated version of the patch, which introduces
> +(pg_lsn, numeric) and -(pg_lsn, numeric) operators.
> To implement them, I added also numeric_pg_lsn() function that
> converts numeric to pg_lsn.
+into and subs
On Wed, May 06, 2020 at 07:35:34PM -0400, Bruce Momjian wrote:
> On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
> > I'm not sure, but probably it worth mentioning in "General performance"
> > section that TOAST (and everything pglz-compressed) decompression should be
> > signi
Em qua., 6 de mai. de 2020 às 21:14, Michael Paquier
escreveu:
> On Wed, May 06, 2020 at 03:58:15PM -0300, Ranier Vilela wrote:
> > Hacking pgbison.pl, to print PATH, shows that the path inside pgbison.pl
> ,
> > returned to being the original, without the addition of
> c:\perl\bin;c:\bin.
> > my
Em qua., 6 de mai. de 2020 às 21:08, Michael Paquier
escreveu:
> On Wed, May 06, 2020 at 02:11:34PM -0400, Andrew Dunstan wrote:
> > We assume perl, flex and bison are in the PATH. That doesn't seem
> > unreasonable, it's worked well for quite a long time.
>
> I recall that it is an assumption we
On Wed, May 06, 2020 at 03:58:15PM -0300, Ranier Vilela wrote:
> Hacking pgbison.pl, to print PATH, shows that the path inside pgbison.pl,
> returned to being the original, without the addition of c:\perl\bin;c:\bin.
> my $out = $ENV{PATH};
> print "Path after system call=$out\n";
> Path after syst
On Wed, May 06, 2020 at 02:11:34PM -0400, Andrew Dunstan wrote:
> We assume perl, flex and bison are in the PATH. That doesn't seem
> unreasonable, it's worked well for quite a long time.
I recall that it is an assumption we rely on since MSVC scripts are
around, and that's rather easy to configur
On Wed, May 6, 2020 at 03:18:54PM +0300, Alexander Korotkov wrote:
> On Tue, May 5, 2020 at 6:16 AM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
>
> Great, thank
On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
> On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > Allow skipping of WAL for new tables and indexes if wal_level is 'minimal'
> > (Noah Misch)
>
> Kyotaro Horiguchi authored that one. (I committed it.) The commit mess
On 2020-Apr-12, Tom Lane wrote:
> The only more-restrictive alternative, short of disabling
> the comments altogether, is
>
>* -Wimplicit-fallthrough=4 case sensitively matches one of the
>following regular expressions:
>
>*<"-fallthrough">
>
On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
>
>
> > 5 мая 2020 г., в 08:16, Bruce Momjian написал(а):
> >
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
> >
> > It st
On Wed, May 6, 2020 at 07:36:21AM +0200, Fabien COELHO wrote:
>
> Hello Bruce,
>
> > > * "DOCUMENT THE DEFAULT GENERATION METHOD"
> > > => The default is still to generate data client-side.
> >
> > My point is that the docs are not clear about this.
>
> Indeed.
>
> > Can you fix it?
>
> Su
On 5/6/20 6:28 PM, Andrew Dunstan wrote:
On 5/6/20 3:24 PM, Tom Lane wrote:
BTW, I looked around and could not find a package-provided ppport.h
at all on my Red Hat systems. What package is it in?
perl-Devel-PPPort contains a perl module that will write the file for
you like this:
perl
On 5/6/20 3:24 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I tried this out with ppport.h from perl 5.30.2 which is what's on my
>> Fedora 31 workstation. It compiled fine, no warnings and the tests all
>> ran fine.
>> So we could update it. I'm just not sure there would be any great
>> bene
On Wed, May 6, 2020 at 5:48 PM Ashwin Agrawal wrote:
> If pg_basebackup is not able to read BLCKSZ content from file, then it
> just emits a warning "could not verify checksum in file "" block
> X: read buffer size X and page size 8192 differ" currently but misses
> to error with "checksum err
If pg_basebackup is not able to read BLCKSZ content from file, then it
just emits a warning "could not verify checksum in file "" block
X: read buffer size X and page size 8192 differ" currently but misses
to error with "checksum error occurred". Only if it can read 8192 and
checksum mismatch h
On 2020-May-06, Jonathan S. Katz wrote:
> I know that 9.6 uses a different subset of the styles, and I recall the
> text being blue during the original conversion. For example, the "table"
> in the 9.6 docs has a class of "CALSTABLE" whereas in master, it is
> "table" (and we operate off of it as
On 5/6/20 5:18 PM, Alvaro Herrera wrote:
> Hello
>
> I think the recent changes to CSS might have broken things in the XSLT
> build; apparently the SGML tooling did things differently. Compare the
> screenshot of tables 67.2 and 67.3 ... 9.6 on the left, master on the
> right. Is the latter form
On Wed, May 6, 2020 at 1:06 PM Alvaro Herrera wrote:
> Good question. I agree that BRIN summarization is not at all related to
> what other index AMs do during the cleanup phase. However, if the
> index_cleanup feature is there to make it faster to process a table
> that's nearing wraparound haz
On 05/06/20 16:01, Chapman Flack wrote:
> I had assumed the patch applied to all of the forms U&'\',
> U&'\+##', E'\u', and E'\U##' ...
annnd that last form needs to have eight #s. (Can't be respelled with 4 ♭s.)
-Chap
On 2020-May-06, Peter Geoghegan wrote:
> Also, do we really want to skip summarization of BRIN indexes? This
> cleanup is rather dissimilar to the cleanup that takes place in most
> other AMs -- it isn't really that related to garbage collection (BRIN
> is rather unique in this respect). I think t
On 05/05/20 10:31, Bruce Momjian wrote:
> On Tue, May 5, 2020 at 09:20:39PM +0800, John Naylor wrote:
>> ... This patch is
>> about the server encoding, which formerly needed to be utf-8 for
>> non-ascii characters. (I think the client encoding doesn't matter as
>> long as ascii bytes are represen
Andrew Dunstan writes:
> I tried this out with ppport.h from perl 5.30.2 which is what's on my
> Fedora 31 workstation. It compiled fine, no warnings and the tests all
> ran fine.
> So we could update it. I'm just not sure there would be any great
> benefit from doing so until we want to use some
On Wed, May 6, 2020 at 11:28 AM Peter Geoghegan wrote:
> This approach has an obvious disadvantage: the patch really has to
> teach *every* index AM to do something with that state (most will
> simply do no work). It seems logical to have the index AM control what
> happens, though. This allows th
Em qua., 6 de mai. de 2020 às 15:19, Ranier Vilela
escreveu:
> Em qua., 6 de mai. de 2020 às 14:14, Victor Wagner
> escreveu:
>
>> В Wed, 6 May 2020 10:21:41 -0300
>> Ranier Vilela пишет:
>>
>> > Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
>> > escreveu:
>> >
>> > > On Tue, May 05, 20
On 2020-Apr-08, Andrew Gierth wrote:
> > "Alvaro" == Alvaro Herrera writes:
>
> >> This needs to be fixed in ruleutils, IMO, not by changing what the
> >> grammar accepts.
>
> Alvaro> Fair. I didn't change what the grammar accepts. I ended up only
> Alvaro> throwing an error in parse an
On Wed, May 6, 2020 at 2:28 AM Masahiko Sawada
wrote:
> I've attached the patch fixes this issue.
>
> With this patch, we don't skip only index cleanup phase when
> performing an aggressive vacuum. The reason why I don't skip only
> index cleanup phase is that index vacuum phase can be called mult
Em qua., 6 de mai. de 2020 às 14:14, Victor Wagner
escreveu:
> В Wed, 6 May 2020 10:21:41 -0300
> Ranier Vilela пишет:
>
> > Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
> > escreveu:
> >
> > > On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner wrote:
> > > > I agree, it is better.
On 5/6/20 1:14 PM, Victor Wagner wrote:
> В Wed, 6 May 2020 10:21:41 -0300
> Ranier Vilela пишет:
>
>> Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
>> escreveu:
>>
>>> On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner wrote:
I agree, it is better.
>>> Thanks, applied and
On 5/4/20 6:44 PM, Andrew Dunstan wrote:
> On 5/1/20 5:32 PM, Tom Lane wrote:
>> There are remaining instances of this antipattern in the flex-generated
>> scanners, which we can't do anything about; and in pl/plperl/ppport.h,
>> which we shouldn't do anything about because that's upstream-genera
On Wed, May 6, 2020 at 6:41 AM Amit Kapila wrote:
> On Wed, May 6, 2020 at 4:19 AM Juan José Santamaría Flecha
> >
> > I think that the definition of get_iso_localename() should be consistent
> across all versions, that is HEAD like back-patched.
> >
>
> Fair enough. I have changed such that get
В Wed, 6 May 2020 10:21:41 -0300
Ranier Vilela пишет:
> Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
> escreveu:
>
> > On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner wrote:
> > > I agree, it is better.
> >
> > Thanks, applied and back-patched down to 9.5. Now for the secon
On 2020-Apr-06, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Jan-14, Alvaro Herrera wrote:
> >> Hmm, it seems to be doing it differently. Maybe it should be acquiring
> >> locks on all objects in that nested loop and verified them for
> >> existence, so that when it calls performMultiple
On Mon, May 4, 2020 at 5:24 AM Amit Kapila wrote:
> If we want to move the calculation of size for tablespaces in the
> caller then I think we also need to do something about the progress
> reporting related to phase
> PROGRESS_BASEBACKUP_PHASE_ESTIMATE_BACKUP_SIZE.
Oh, good point. v2 attached.
Hi Bruce,
On Tue, May 5, 2020 at 12:16 PM Bruce Momjian wrote:
>
> I have committed the first draft of the PG 13 release notes. You can
> see them here:
>
> https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting. The community doc
> build shoul
On 2020-04-22 16:26, Peter Eisentraut wrote:
On 2020-04-22 01:56, Alvaro Herrera wrote:
I'm surprised that this hasn't applied yet, because:
On 2020-Apr-09, Peter Eisentraut wrote:
One thing to remember is that the current situation is broken. While you
can set index columns to have differen
On 2020-04-23 08:35, Masahiko Sawada wrote:
After investigating this issue, I think that current DDLs regarding
inherited tables and generated columns seem not to work fine.
Right, there were a number of combinations that were not properly
handled. The attached patch should fix them all. It'
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
The patch applies cleanly and works as expected.
Em qua., 6 de mai. de 2020 às 10:25, Ranier Vilela
escreveu:
> Em qua., 6 de mai. de 2020 às 10:21, Ranier Vilela
> escreveu:
>
>> Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
>> escreveu:
>>
>>> On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner wrote:
>>> > I agree, it is better.
Em qua., 6 de mai. de 2020 às 10:21, Ranier Vilela
escreveu:
> Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
> escreveu:
>
>> On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner wrote:
>> > I agree, it is better.
>>
>> Thanks, applied and back-patched down to 9.5. Now for the second
Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
escreveu:
> On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner wrote:
> > I agree, it is better.
>
> Thanks, applied and back-patched down to 9.5. Now for the second
> problem of this thread..
>
Sorry, no clue yet.
I hacked the perl sourc
On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner wrote:
> I agree, it is better.
Thanks, applied and back-patched down to 9.5. Now for the second
problem of this thread..
--
Michael
signature.asc
Description: PGP signature
On Tue, May 5, 2020 at 6:16 AM Bruce Momjian wrote:
>
> I have committed the first draft of the PG 13 release notes. You can
> see them here:
>
> https://momjian.us/pgsql_docs/release-13.html
Great, thank you!
It seems that opclass parameters (911e702077) are not reflected in the
releas
On Wed, May 06, 2020 at 11:14:49AM +0300, Alexander Korotkov wrote:
> You can also take a look at https://github.com/postgrespro/rum
Please note that we have also an extra, mostly-blank, template as of
src/test/modules/dummy_index_am/ which has been added in v13 for
mainly testing purposes, but yo
On Wed, May 6, 2020 at 8:35 AM 邱宇航 wrote:
>
> And one more question, what LogAccessExclusiveLocks in LogStandbySnapshot is
> used for?
>
As far as I understand, this is required to ensure that we have
acquired all the AccessExclusiveLocks on relations before we can say
standby has reached STANDB
On Wed, 6 May 2020 at 07:17, Masahiko Sawada
wrote:
>
> On Wed, 6 May 2020 at 07:14, Peter Geoghegan wrote:
> >
> > On Tue, May 5, 2020 at 2:52 PM Masahiko Sawada
> > wrote:
> > > So IIUC the problem is that since we skip both,
> > > oldst_btpo_xact could be seen as a "future" xid during vacuum.
On Tue, May 5, 2020 at 5:10 PM Tom Lane wrote:
>
> Benjamin Schaller writes:
> > Even though it's described as fairly complicated: If I would want to
> > define my own index method, what would be a good approach to do so?
>
> contrib/bloom would make a sensible template, perhaps.
+1
You can als
65 matches
Mail list logo
