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,
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
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
В 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 =
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
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
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
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
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
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
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
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
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
> >
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.
> >
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
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
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
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,
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
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
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?
>
>
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:
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
>>
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
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
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
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
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
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
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
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,
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
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
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
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
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
В 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
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
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
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
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.
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
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
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
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
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
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
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
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 message
noted characteristics, some of which may deserve mention in the
> 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 still needs markup, word wrap, and indenting. The community doc
> build should
Hi!
> 5 мая 2020 г., в 17:21, Benjamin Schaller
> написал(а):
>
> 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?
I'm working on presentation describing how to fork AM out of core to extension.
Hope
62 matches
Mail list logo
