On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
>
> On Thu, Mar 19, 2020 at 09:33:09PM +0900, Masahiko Sawada wrote:
> > Attached updated version patch. This patch incorporated the comments
> > and changed pg_upgrade so that we take over the master encryption key
> > from the old cluster to
Hi
I did another test
I use a pi estimation algorithm and it is little bit more realistic than
just almost empty cycle body - still probably nobody will calculate pi in
plpgsql.
CREATE OR REPLACE FUNCTION pi_est(n int)
RETURNS numeric AS $$
DECLARE
accum double precision DEFAULT 1.0;
c1
On Tue, Dec 31, 2019 at 8:35 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > With the attached patch, I propose to enable the colored output by
> > default in PG13.
>
> FWIW, I shall be setting NO_COLOR permanently if this gets committed.
> I wonder how many people there are who actually
On Thu, Mar 19, 2020 at 03:44:49PM -0700, Andres Freund wrote:
> But uh, unfortunately the vacuum delay code just sleeps without setting
> a wait event:
...
> Seems like it should instead use a new wait event in the PG_WAIT_TIMEOUT
> class?
>
> Given how frequently we run into trouble with
On Fri, Mar 20, 2020 at 6:32 PM Jürgen Purtz wrote:
> man pages: Sorry, if I confused someone with my poor English. I just
> want to express in my 'offline' mail that we don't have to worry about
> man page generation. The patch doesn't affect files in the /ref
> subdirectory from where man
On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> >> I can confirm there is still no mention of PG_COLORS in our
> >> documentation.
>
> > My mistake, PG_COLOR (not PG_COLORS) is documented properly.
>
> Yeah, but the point is precisely that pg_logging_init()
>
Bruce Momjian writes:
>> I can confirm there is still no mention of PG_COLORS in our
>> documentation.
> My mistake, PG_COLOR (not PG_COLORS) is documented properly.
Yeah, but the point is precisely that pg_logging_init()
also responds to PG_COLORS, which is not documented anywhere.
On Thu, Mar 19, 2020 at 10:15:57PM -0400, Bruce Momjian wrote:
> On Tue, Mar 3, 2020 at 02:31:01PM +0900, Michael Paquier wrote:
> > On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote:
> > > - The new entry in the documentation, specially as the PG_COLORS parameter
> > >
On Fri, Mar 20, 2020 at 11:32:25PM +0100, Jürgen Purtz wrote:
> > > +
> > > +File Segment
> > > +
> > > +
> > > + If a heap or index file grows in size over 1 GB, it will be split
> > 1GB is the default "segment size", which you should define.
>
> ???
"A <> or other
On 20.03.20 20:58, Justin Pryzby wrote:
On Thu, Mar 19, 2020 at 09:11:22PM -0300, Alvaro Herrera wrote:
+Aggregate
+
+
+ To combine a collection of data values into a single value, whose
+ value may not be of the same type as the original values.
+ Aggregate
man pages: Sorry, if I confused someone with my poor English. I just
want to express in my 'offline' mail that we don't have to worry about
man page generation. The patch doesn't affect files in the /ref
subdirectory from where man pages are created.
review process: Yes, it will be
On Fri, Feb 14, 2020 at 6:31 PM Thomas Munro wrote:
> On Wed, Jan 29, 2020 at 12:43 AM Fujii Masao
> wrote:
> > /*
> > - * do a TransactionId -> txid conversion for an XID near the given epoch
> > + * Do a TransactionId -> fxid conversion for an XID that is known to
> > precede
> > + * the
I am hacking some GIST code for a research project and wanted clarification
about what exactly a secondary split is in GIST. More specifically I am
wondering why the supportSecondarySplit function (which is in
src/backend/access/gist/gistsplit.c) can assume that the data is currently
on the left
On 2020-Mar-19, Daniel Gustafsson wrote:
> Moving this patch to Ready for Committer.
Thanks, pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Mar 19, 2020 at 09:33:09PM +0900, Masahiko Sawada wrote:
> Attached updated version patch. This patch incorporated the comments
> and changed pg_upgrade so that we take over the master encryption key
> from the old cluster to the new one if both enable key management.
We had a crypto team
On Thu, Mar 19, 2020 at 09:11:22PM -0300, Alvaro Herrera wrote:
> +Aggregate
> +
> +
> + To combine a collection of data values into a single value, whose
> + value may not be of the same type as the original values.
> + Aggregate Functions
> + combine multiple
čt 19. 3. 2020 v 23:57 odesílatel Nikita Glukhov
napsal:
> Attached 45th version of the patches.
>
> Nodes JsonFormat, JsonReturning, JsonPassing, JsonBehavior were fixed.
>
>
> On 17.03.2020 21:35, Pavel Stehule wrote:
>
>
> út 17. 3. 2020 v 1:55 odesílatel Nikita Glukhov
> napsal:
>
>>
On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote:
> Hello
>
> Yet another is missed in docs: total_time
Oh good catch! I rechecked many time the field, and totally missed that the
documentation is referring to the view, which has an additional column, and not
the function.
>
> It's hard to review work from a professional tech writer. I'm under the
> constant impression that I'm ruining somebody's perfect end product,
> making a fool of myself.
If it makes you feel better, it's a mix of definitions I wrote that Roger
proofed and restructured, ones that Jürgen had
Alvaro, I know that you are joking, but I want to impress on everyone:
please don't feel like anyone here is breaking anything when it comes to
modifying the content and structure of this glossary.
I do have technical writing experience, but everyone else here is a subject
matter expert when it
On 2020-Mar-20, Corey Huinker wrote:
> > Jürgen mentioned off-list that the man page doesn't build. I was going to
> > look into that, but if anyone has more familiarity with that, I'm listening.
> Looking at this some more, I'm not sure anything needs to be done for man
> pages.
Yeah, I don't
"Li, Zheng" writes:
> This patch enables correlated IN/Any subquery to be transformed to join, the
> transformation is allowed only when the correlated Var is in the where clause
> of the subquery. It covers the most common correlated cases and follows the
> same criteria that is followed by
Peter Eisentraut writes:
> I noticed that when you want to define EXEC_BACKEND, perhaps to do some
> non-Windows testing of that option, it's not clear how to do that. I
> would have expected it in pg_config_manual.h, but it's actually in
> configure.in and in MSBuildProject.pm. So if you
Hello,
I’ve recently tried to build an extension that employs C++ files and also
passes them to a linker to make a shared library. I’ve discovered a few
issues with them:
- in v10 CFLAGS_SL is not appended to the CXXFLAGS in Makefile.shlib,
resulting in cpp files compiled without -fPIC, leading
>
> Jürgen mentioned off-list that the man page doesn't build. I was going to
>> look into that, but if anyone has more familiarity with that, I'm listening.
>>
>
Looking at this some more, I'm not sure anything needs to be done for man
pages. man1 is for executables, man3 seems to be dblink and
On Fri, Mar 20, 2020 at 11:32 AM Peter Eisentraut
wrote:
> On 2020-03-19 16:38, Robert Haas wrote:
> > Incidentally, the wait-event handling in SaveSlotToPath() doesn't look
> > right for the early-exit cases either.
>
> There appear to be appropriate pgstat_report_wait_end() calls. What are
>
On 2020-03-19 16:38, Robert Haas wrote:
Incidentally, the wait-event handling in SaveSlotToPath() doesn't look
right for the early-exit cases either.
There appear to be appropriate pgstat_report_wait_end() calls. What are
you seeing?
--
Peter Eisentraut
I noticed that when you want to define EXEC_BACKEND, perhaps to do some
non-Windows testing of that option, it's not clear how to do that. I
would have expected it in pg_config_manual.h, but it's actually in
configure.in and in MSBuildProject.pm. So if you want to define it
yourself, you
On 2020-03-06 10:36, Daniel Verite wrote:
David Zhang wrote:
Thanks for your review, now the new patch with the error message in PG
style is attached.
The current status of the patch is "Needs review" at
https://commitfest.postgresql.org/27/2400/
If there's no more review to do,
On Fri, Mar 20, 2020 at 04:58:08PM +0530, Amit Kapila wrote:
> See, how the attached looks? I have written a commit message as well,
> see if I have missed anyone is from the credit list?
Thanks for looking again.
Couple tweaks:
+/* Phases of vacuum during which an error can occur. */
Can you
On 2020-Mar-14, Paul A Jungwirth wrote:
> On Fri, Mar 13, 2020 at 2:39 PM Alvaro Herrera
> wrote:
> > Here's the rebased version.
> >
> > I just realized I didn't include the API change I proposed in
> > https://postgr.es/m/20200306200343.GA625@alvherre.pgsql ...
>
> Thanks for your help with
On 2020-Mar-19, Tom Lane wrote:
> I think the key decision we'd have to make to move forward on this
> is to decide whether it's still project style to prefer the extra
> parens, or whether we want new code to do without them going
> forward. If we don't want to risk requiring __VA_ARGS__ for
Andres Freund writes:
> On 2020-03-19 22:32:30 -0400, Tom Lane wrote:
>> Could we get away with moving the compiler goalposts for the back
>> branches? I dunno, but it's a fact that we aren't testing anymore
>> with any compilers that would complain about unconditional use of
>> __VA_ARGS__. So
Hello
I was inactive for a while... Sorry.
>> BTW, I recheck the patchset.
>> I think codes are ready for committer but should we modify the
>> documentation?
>> {min,max,mean,stddev}_time is now obsoleted so it is better to modify it to
>> {min,max,mean,stddev}_exec_time and add
On Thu, 2020-03-19 at 23:20 -0700, Andres Freund wrote:
> I am not sure about b). In my mind, the objective is not to prevent
> > anti-wraparound vacuums, but to see that they have less work to do,
> > because previous autovacuum runs already have frozen anything older than
> >
On Fri, Mar 20, 2020 at 12:32 PM Amit Kapila wrote:
>
> On Fri, Mar 20, 2020 at 4:15 AM Andres Freund wrote:
> >
> > Hi,
> >
> > I was looking at [1], wanting to suggest a query to monitor what
> > autovacuum is mostly waiting on. Partially to figure out whether it's
> > mostly autovacuum cost
On Fri, Mar 20, 2020 at 4:15 AM Andres Freund wrote:
>
> Hi,
>
> I was looking at [1], wanting to suggest a query to monitor what
> autovacuum is mostly waiting on. Partially to figure out whether it's
> mostly autovacuum cost limiting.
>
> But uh, unfortunately the vacuum delay code just sleeps
On Fri, Mar 20, 2020 at 12:21 PM Justin Pryzby wrote:
>
> On Fri, Mar 20, 2020 at 11:24:25AM +0530, Amit Kapila wrote:
> > On Fri, Mar 20, 2020 at 5:59 AM Justin Pryzby wrote:
> > That makes sense. I have a few more comments:
> >
> > 1.
> > + VACUUM_ERRCB_PHASE_INDEX_CLEANUP,
> > +}
čt 19. 3. 2020 v 10:47 odesílatel Amit Langote
napsal:
> Hi Pavel,
>
> Sorry it took me a while to look at this.
>
> On Tue, Feb 25, 2020 at 4:28 AM Pavel Stehule
> wrote:
> > po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule
> napsal:
> >> But I found one issue - I don't know if this issue is
On Fri, Mar 13, 2020 at 10:57:43AM -0700, Andres Freund wrote:
> On 2020-03-13 10:53:17 -0700, Jeff Davis wrote:
> > On Fri, 2020-03-13 at 10:27 -0700, Andres Freund wrote:
> > > On 2020-03-13 10:15:46 -0700, Jeff Davis wrote:
> > > > Also, is there a reason you report two different memory values
ed to commit the
>> patch if it has this more simple syntax has he requested.
>>
>>
>>
>> What do you think ?
>>
>
> I removed TRANSACTIONAL from this clause, see attachement change.diff
>
> Updated patch attached.
>
> I hope it would be the last touch, making it fully ready for a commiter.
>>
>
> Thank you very much for review and testing
>
documentation fix
> Pavel
>
>>
schema-variables-20200320-2.patch.gz
Description: application/gzip
,
proname => 'pg_variable_is_visible', procost => '10', provolatile => 's',
prorettype => 'bool', proargtypes => 'oid', prosrc => 'pg_variable_is_visible' },
schema-variables-20200320.patch.gz
Description: application/gzip
On Fri, 20 Mar 2020 at 15:20, Andres Freund wrote:
>
> Hi,
>
> On 2020-03-19 06:45:48 +0100, Laurenz Albe wrote:
> > On Tue, 2020-03-17 at 18:02 -0700, Andres Freund wrote:
> > > I don't think a default scale factor of 0 is going to be ok. For
> > > large-ish tables this will basically cause
On Thu, Mar 19, 2020 at 3:34 PM Amit Langote wrote:
>
> Thank you Chris, Amit.
>
> On Thu, Mar 19, 2020 at 1:46 PM Amit Kapila wrote:
> > On Thu, Mar 19, 2020 at 3:55 AM Chris Bandy wrote:
> > >
> > >
> > > Sorry for these troubles. Attached are patches created using `git
> > > format-patch -n
On Fri, Mar 20, 2020 at 11:24:25AM +0530, Amit Kapila wrote:
> On Fri, Mar 20, 2020 at 5:59 AM Justin Pryzby wrote:
> That makes sense. I have a few more comments:
>
> 1.
> + VACUUM_ERRCB_PHASE_INDEX_CLEANUP,
> +} errcb_phase;
>
> Why do you need a comma after the last element in the above
On Thu, Mar 19, 2020 at 8:21 PM Chris Bandy wrote:
>
> On 3/18/20 11:46 PM, Amit Kapila wrote:
> > On Thu, Mar 19, 2020 at 3:55 AM Chris Bandy wrote:
> >>
> >>
> >> Sorry for these troubles. Attached are patches created using `git
> >> format-patch -n -v6` on master at 487e9861d0.
> >>
> >
> >
Hi,
On 2020-03-20 06:59:57 +0100, Laurenz Albe wrote:
> On Thu, 2020-03-19 at 15:17 -0700, Andres Freund wrote:
> > I am *VERY* doubtful that the attempt of using a large threshold, and a
> > tiny scale factor, is going to work out well. I'm not confident enough
> > in my gut feeling to full
On Fri, Mar 6, 2020 at 10:18 PM Fujii Masao
wrote:
>
> OK, so patch attached.
>
> This patch causes, if a promotion is triggered while recovery is paused,
> the paused state to end and a promotion to continue. OTOH, this patch
> makes pg_wal_replay_pause() and _resume() throw an error if it's
Hi,
On 2020-03-19 06:45:48 +0100, Laurenz Albe wrote:
> On Tue, 2020-03-17 at 18:02 -0700, Andres Freund wrote:
> > I don't think a default scale factor of 0 is going to be ok. For
> > large-ish tables this will basically cause permanent vacuums. And it'll
> > sometimes trigger for tables that
On Fri, 20 Mar 2020 at 01:38, Bruce Momjian wrote:
>
> On Fri, Mar 20, 2020 at 12:50:27AM +0900, Masahiko Sawada wrote:
> > On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote:
> > Well, the issue is if the user can control the user key, there is might
> > be
> > a way to make the user key
On Thu, 2020-03-19 at 14:38 -0700, Andres Freund wrote:
> > I am not sure about b). In my mind, the objective is not to prevent
> > anti-wraparound vacuums, but to see that they have less work to do,
> > because previous autovacuum runs already have frozen anything older than
> >
Hi,
Thanks for looking!
On 2020-03-20 18:23:03 +1300, Thomas Munro wrote:
> On Sun, Mar 1, 2020 at 9:36 PM Andres Freund wrote:
> > I'm still working on cleaning that part of the patch up, I'll post it in
> > a bit.
>
> I looked at that part on your public pgxact-split branch. In that
>
On Thu, 2020-03-19 at 15:17 -0700, Andres Freund wrote:
> I am doubtful it should be committed with the current settings. See below.
>
> > From 3ba4b572d82969bbb2af787d1bccc72f417ad3a0 Mon Sep 17 00:00:00 2001
> > From: Laurenz Albe
> > Date: Thu, 19 Mar 2020 20:26:43 +0100
> > Subject: [PATCH]
53 matches
Mail list logo
