On Mon, May 4, 2020 at 7:58 AM Michael Paquier wrote:
>
> > Warning from build.pl
> > Use of uninitialized value $ARGV[0] in uc at build.pl line 44.
> > Use of uninitialized value $ARGV[0] in uc at build.pl line 48.
>
> Hmm. We have buildfarm machines using the MSVC scripts and Python,
> see for
On Fri, May 1, 2020 at 3:52 AM Bruce Momjian wrote:
>
> On Thu, Apr 30, 2020 at 09:51:10PM -0400, Tom Lane wrote:
> > John Naylor writes:
> > > As I understand it, the point of having "do {} while (0)" in a
> > > multi-statement macro is to turn it into a simple statement.
> >
> > Right.
> >
> >
On Wed, Apr 29, 2020 at 9:57 PM Robert Haas wrote:
>
> Hi,
>
> I think it's not good that do_pg_start_backup() takes a flag which
> tells it to call back into basebackup.c's sendTablespace(). This means
> that details which ought to be private to basebackup.c leak out and
> become visible to other
Em seg., 4 de mai. de 2020 às 02:58, Michael Paquier
escreveu:
> On Sun, May 03, 2020 at 04:23:24PM -0300, Ranier Vilela wrote:
> > I don't know if it applies to the same case, but from the moment I
> > installed python on the development machine, the Postgres build stopped
> > working correctly.
On Fri, May 1, 2020 at 8:41 PM Dilip Kumar wrote:
>
> On Thu, Apr 30, 2020 at 12:31 PM Amit Kapila wrote:
> >
> >
> > But can't they access other catalogs like pg_publication*? I think
> > the basic thing we want to ensure here is that all historic accesses
> > always use systable* APIs to acces
On Mon, May 04, 2020 at 09:45:54AM +0200, Juan José Santamaría Flecha wrote:
> I think these are two different issues, python PATH and build.pl warnings.
> For the later, you can check woodloose logs and see the warning after
> commit 8f00d84afc.
Oh, indeed. I somewhat managed to miss these in th
On Thu, Apr 30, 2020 at 4:15 PM Amit Kapila wrote:
> On Wed, Apr 29, 2020 at 6:11 PM Suraj Kharage
> wrote:
> >
> > Hi,
> >
> > We at EnterpriseDB did some performance testing around this parallel
> backup to check how this is beneficial and below are the results. In this
> testing, we run the b
On Thu, Apr 30, 2020 at 5:07 AM Amit Kapila wrote:
> >
> > I was not aware of how many switches IsoLocaleName() already had before
> trying to backpatch. I think offering an alternative might be a cleaner
> approach, I will work on that.
> >
>
> Okay, thanks. The key point to keep in mind is to
On Mon, May 4, 2020 at 2:18 PM Michael Paquier wrote:
> On Mon, May 04, 2020 at 09:45:54AM +0200, Juan José Santamaría Flecha
> wrote:
> > I think these are two different issues, python PATH and build.pl
> warnings.
> > For the later, you can check woodloose logs and see the warning after
> > com
On Mon, May 4, 2020 at 6:10 AM Amit Kapila wrote:
>
> On Thu, Apr 30, 2020 at 2:19 PM Julien Rouhaud wrote:
> >
> > Here's the patch. I included the content of
> > v3-fix_explain_wal_output.patch you provided before, and tried to
> > consistently replace full page writes/fpw to full page images/
Hi Tom,
On Fri, May 1, 2020 at 2:32 PM Tom Lane wrote:
>
> Grepping showed me that there were some not-do-while macros that
> also had trailing semicolons. These seem just as broken, so I
> fixed 'em all.
>
I'm curious: *How* are you able to discover those occurrences with grep?
I understand how
Jesse Zhang writes:
> On Fri, May 1, 2020 at 2:32 PM Tom Lane wrote:
>> Grepping showed me that there were some not-do-while macros that
>> also had trailing semicolons. These seem just as broken, so I
>> fixed 'em all.
> I'm curious: *How* are you able to discover those occurrences with grep?
On Sun, May 3, 2020 at 1:49 PM Andres Freund wrote:
> > > The run-to-run variations between the runs without cache control are
> > > pretty large. So this is probably not the end-all-be-all numbers. But I
> > > think the trends are pretty clear.
> >
> > Could you be explicit about what you think t
On 2020-05-01 17:44, Robert Haas wrote:
On Fri, May 1, 2020 at 10:51 AM Pavel Stehule wrote:
+1
+1 from me, too, but I have a few suggestions:
+DropGenericById(const ObjectAddress *object)
How about "Generic" -> "Object" or "Generic" -> "ObjectAddress"?
Changed to "Object", that also matc
Hi,
On 2020-05-04 14:04:32 -0400, Robert Haas wrote:
> OK, thanks. Let me see if I can summarize here. On the strength of
> previous experience, you'll probably tell me that some parts of this
> summary are wildly wrong or at least "not quite correct" but I'm going
> to try my best.
> - Server-si
I've now completed updating chapter 9 for the new layout,
and the results are visible at
https://www.postgresql.org/docs/devel/functions.html
There is more to do --- for instance, various contrib modules
have function/operator tables that should be synced with this
design. But this seemed like a
On 5/4/20 5:22 PM, Tom Lane wrote:
> I've now completed updating chapter 9 for the new layout,
> and the results are visible at
> https://www.postgresql.org/docs/devel/functions.html
> There is more to do --- for instance, various contrib modules
> have function/operator tables that should be sync
On Tue, May 5, 2020 at 5:53 AM Bossart, Nathan wrote:
> I believe I've discovered a race condition between the startup and
> checkpointer processes that can cause a CRC mismatch in the pg_control
> file. If a cluster crashes at the right time, the following error
> appears when you attempt to res
"Jonathan S. Katz" writes:
> On 5/4/20 5:22 PM, Tom Lane wrote:
>> I've now completed updating chapter 9 for the new layout,
>> and the results are visible at
>> https://www.postgresql.org/docs/devel/functions.html
> This is already much better. I've skimmed through a few of the pages, I
> can s
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-generated
> code. (I wonder though if there's a n
Fix possible overflow when converting, possible negative number to uint16.
postingoff can be -1,when converts to uint16, overflow can raise.
Otherwise, truncation can be occurs, losing precision, from int (31 bits)
to uint16 (15 bits)
There is a little confusion in the parameters of some functions
On Wed, Apr 29, 2020 at 4:44 PM David Kimura wrote:
>
> Following patch adds logic to create a batch 0 file for serial hash join so
> that even in pathalogical case we do not need to exceed work_mem.
Updated the patch to spill batch 0 tuples after it is marked as fallback.
A couple questions fro
As of HEAD, building the PDF docs for A4 paper draws 538 "contents
... exceed the available area" warnings. While this is a nice step
forward from where we were (v12 has more than 1500 such warnings),
we're far from done fixing that issue.
A large chunk of the remaining warnings are about tables
On 5/4/20 9:52 PM, Tom Lane wrote:
> As of HEAD, building the PDF docs for A4 paper draws 538 "contents
> ... exceed the available area" warnings. While this is a nice step
> forward from where we were (v12 has more than 1500 such warnings),
> we're far from done fixing that issue.
>
> A large ch
On 5/4/20 6:39 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 5/4/20 5:22 PM, Tom Lane wrote:
>> It does look better, but things look a bit smushed together on the pgweb
>> front.
>
> Yeah. There's less smushing of function signatures when building the
> docs without STYLE=website, so t
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 happen in a few hours.
--
Bruce Momjian https://momjian.us
Ent
On Mon, May 4, 2020 at 5:16 PM Amit Kapila wrote:
>
> On Fri, May 1, 2020 at 8:41 PM Dilip Kumar wrote:
> >
> 5. Shouldn't we add a check in table_scan_sample_next_block and
> table_scan_sample_next_tuple APIs as well?
I am not sure that we need to do that, Because generally, we want to
avoid
On Tue, 5 May 2020 at 15:16, 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 should happen in a
On Tue, 5 May 2020 at 16:10, David Rowley wrote:
> In previous years, during the development of this you've had HTML
> comments to include the commit details. Are you going to do that this
> year? or did they just disappear in some compilation phase you've
> done?
Never mind. I just saw them all
On Tue, May 5, 2020 at 3: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 should happen in a
On Tue, May 5, 2020 at 9:27 AM Dilip Kumar wrote:
>
> On Mon, May 4, 2020 at 5:16 PM Amit Kapila wrote:
> >
> > On Fri, May 1, 2020 at 8:41 PM Dilip Kumar wrote:
> > >
>
> > 5. Shouldn't we add a check in table_scan_sample_next_block and
> > table_scan_sample_next_tuple APIs as well?
>
> I am no
On Tue, May 5, 2020 at 10:25 AM Amit Kapila wrote:
>
> On Tue, May 5, 2020 at 9:27 AM Dilip Kumar wrote:
> >
> > On Mon, May 4, 2020 at 5:16 PM Amit Kapila wrote:
> > >
> > > On Fri, May 1, 2020 at 8:41 PM Dilip Kumar wrote:
> > > >
> >
> > > 5. Shouldn't we add a check in table_scan_sample_nex
On Tue, May 5, 2020 at 10:31 AM Dilip Kumar wrote:
>
> On Tue, May 5, 2020 at 10:25 AM Amit Kapila wrote:
> >
> > On Tue, May 5, 2020 at 9:27 AM Dilip Kumar wrote:
> > >
> > > On Mon, May 4, 2020 at 5:16 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Fri, May 1, 2020 at 8:41 PM Dilip Kumar
>
Hello Bruce,
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 happen in a few hours.
Thanks for working on this.
* Add
Hi
út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian napsal:
> 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 happe
Hello Tom,
oid oid
Row identifier
adrelid oid (references pg_class.oid)
The table this column belongs to
adnum int2 (references pg_attribute.attnum)
The number of the column
adbin pg_node_tree
The column default value, in nodeToString() representation. Use
Hi,
On Tue, May 5, 2020 at 7:47 AM Pavel Stehule wrote:
>
> Hi
>
> út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian napsal:
>>
>> 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
On Fri, May 01, 2020 at 12:48:17PM +0300, Victor Wagner wrote:
> Maybe. But probably original author of this code was afraid of using
> too long chain of ->{} in the string substitution.
>
> So, I left this style n place.
>
> Nonetheless, using qq wouldn't save us from doubling backslashes.
Loo
38 matches
Mail list logo
