On Wed, Jun 26, 2019 at 10:29:05PM +1000, Haribabu Kommi wrote:
> Thanks for the review. Yes, that patch applies till 9.5, it is my mistake
> in naming the patch.
I have been able to finally set up an environment with VS 2019 (as
usual this stuff needs time, anyway..), and I can confirm that the
p
Hi, Michael-san.
> From: Michael Paquier
> On Wed, Jun 26, 2019 at 04:13:36AM +, nagaura.ryo...@fujitsu.com wrote:
> > I don't think that the rest one of my proposals has been rejected
> > completely, so I want to restart discussion.
> I recall on the matter that there was consensus that nobo
Hello,
The attached patch include the fix for all the comment given
regards
Surafel
On Mon, Apr 1, 2019 at 12:34 AM Andres Freund wrote:
> Hi,
>
> On 2019-03-29 12:04:50 +0300, Surafel Temesgen wrote:
>
> > + if (node->limitOption == PERCENTAGE)
> > +
Hello hackers,
While working on pg_dump I noticed the extra quote_all_identifiers in
_dumpOptions struct. I attached the patch.
It came from refactoring by 0eea8047bf. There is also a discussion:
https://www.postgresql.org/message-id/CACw0%2B13ZUcXbj9GKJNGZTkym1SXhwRu28nxHoJMoX5Qwmbg_%2Bw%40ma
On Thu, Jun 27, 2019 at 6:00 AM Tom Lane wrote:
> =?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=
> writes:
> > I'm looking at PostGIS geometry GiST index build times and try to
> optimize
> > withing the current GiST framework. The function that shows a lot on my
> > flame graphs is penalty
Hi,
I think commit 83e176ec1, which moved block sampling functions to
utils/misc/sampling.c, forgot to update this comment in
commands/analyze.c: "This algorithm is from Jeff Vitter's paper (see
full citation below)"; since the citation was also moved to
utils/misc/sampling.c, I think the "see ful
On Thu, Jun 27, 2019 at 12:04:30AM -0400, Tom Lane wrote:
Tomas Vondra writes:
OK. Attached is a patch ditching the alignment in serialized data. I've
ditched the macros to access parts of serialized data, and everything
gets copied.
I lack energy to actually read this patch right now, and I
On 26/06/2019 06:07, Thomas Munro wrote:
On Wed, Jun 26, 2019 at 2:33 PM Michael Paquier wrote:
On Tue, Jun 25, 2019 at 02:38:43PM +0500, Andrey Borodin wrote:
I feel a little uncomfortable with number 0x7fff right in code.
PG_INT32_MAX...
MaxTransactionId / 2?
Yeah, that makes sense
On several popular operating systems, we can use relative rpaths, using
the $ORIGIN placeholder, so that the resulting installation is
relocatable. Then we also don't need to set LD_LIBRARY_PATH during make
check.
This implementation will use a relative rpath if bindir and libdir are
under the sa
> On 27 Jun 2019, at 13:05, Etsuro Fujita wrote:
> since the citation was also moved to
> utils/misc/sampling.c, I think the "see full citation below" part
> should be updated accordingly. Attached is a patch for that.
Agreed, nice catch!
cheers ./daniel
> 27 июня 2019 г., в 16:38, Heikki Linnakangas написал(а):
>
> I haven't done any testing on this yet. Andrey, would you happen to have an
> environment ready to test this?
Thanks!
I will do some testing this evening (UTC+5). But I'm not sure I can reliably
test wraparound of xids...
I wil
Hi,
I searched the mailing list but found nothing. Any reason why
TupleDescAttr is a macro and not a static inline?
Rather than adding an Assert attached POC replace TupleDescAttr macro
by a static inline function with AssertArg.
It:
- Factorize Assert.
- Trigger an Assert in JIT_deform if natts
On Wed, 19 Jun 2019 at 20:04, Alexander Korotkov
wrote:
>
> On Wed, Jun 19, 2019 at 7:07 PM Thom Brown wrote:
> > On Thu, 13 Jun 2019 at 14:59, Thom Brown wrote:
> > >
> > > Hi,
> > >
> > > I've been reading through the documentation regarding jsonpath and
> > > jsonb_path_query etc., and I have
The ssl_ciphers GUC for configuring cipher suites sets the default value based
on USE_SSL but it’s actually an OpenSSL specific value. As with other such
changes, it works fine now but will become an issue should we support other TLS
backends. Attached patch fixes this.
cheers ./daniel
opens
Hi,
Here is a patch for the pg_receivewal documentation to highlight that
WAL isn't acknowledged to be applied.
I'll add a CF entry for it.
Best regards,
Jesper
>From 138e09c74db5ea08fd03b4e77853e2ca01742512 Mon Sep 17 00:00:00 2001
From: jesperpedersen
Date: Thu, 27 Jun 2019 09:54:44 -0400
Hi all,
Being interested by this feature, I did a patch review.
This features adds the GUC "max_slot_wal_keep_size". This is the maximum amount
of WAL that can be kept in "pg_wal" by active slots.
If the amount of WAL is superior to this limit, the slot is deactivated and
its status (new filed i
Does anyone know why there is no PG 12 stable branch in our git tree?
$ git branch -l
REL9_4_STABLE
REL9_5_STABLE
REL9_6_STABLE
REL_10_STABLE
REL_11_STABLE
master
They exist for earlier releases. Is this a problem?
--
Bruce
On Thu, Jun 27, 2019 at 10:28:40AM -0400, Bruce Momjian wrote:
> Does anyone know why there is no PG 12 stable branch in our git tree?
>
> $ git branch -l
> REL9_4_STABLE
> REL9_5_STABLE
> REL9_6_STABLE
> REL_10_STABLE
> REL_11_STABLE
> master
Bruce Momjian writes:
> Does anyone know why there is no PG 12 stable branch in our git tree?
For the record, I'm intending to make the branch as soon as the
July CF starts (i.e., first thing Monday).
regards, tom lane
On Thu, Jun 27, 2019 at 10:28:40AM -0400, Bruce Momjian wrote:
Does anyone know why there is no PG 12 stable branch in our git tree?
$ git branch -l
REL9_4_STABLE
REL9_5_STABLE
REL9_6_STABLE
REL_10_STABLE
REL_11_STABLE
master
T
On Thu, Jun 27, 2019 at 01:53:52PM +0200, Daniel Gustafsson wrote:
On 27 Jun 2019, at 13:05, Etsuro Fujita wrote:
since the citation was also moved to
utils/misc/sampling.c, I think the "see full citation below" part
should be updated accordingly. Attached is a patch for that.
Agreed, nice
On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
wrote:
On 2019-04-12 19:52, Robert Treat wrote:
> It is clear to me that the docs are wrong, but I don't see anything
> inherently incorrect about the code itself. Do you have suggest
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> In general, the point I'm trying to make is that our policy should
> Tom> be "Ties are broken arbitrarily, and if you don't like the choice
> Tom> that initdb makes, here's how to fix it".
> Yes, you've repeated that point at some lengt
> 27 июня 2019 г., в 16:38, Heikki Linnakangas написал(а):
>
> I haven't done any testing on this yet. Andrey, would you happen to have an
> environment ready to test this?
Patches do not deadlock and delete pages on "rescan test" - setup that we used
to detect "left jumps" in during develo
On Tue, Jun 25, 2019 at 8:18 PM Tom Lane wrote:
> As long as we have a trivial and obviously apolitical rule like
> alphabetical order, I think we can skate over such things; but the minute
> we have any sort of human choices involved there, we're going to be
> getting politically driven requests
On Tue, Jun 25, 2019 at 11:33 PM Tom Lane wrote:
> Comments?
LGTM.
s/must/should/ ?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, 27 Jun 2019 at 12:50, Tomas Vondra
wrote:
> On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
> >On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
> > wrote:
> >>
> >> On 2019-04-12 19:52, Robert Treat wrote:
> >> > It is clear to me that the docs are wrong, but I don't see any
Robert Haas writes:
> I'm kind of unsure what to think about this whole debate
> substantively. If Andrew is correct that zone.tab or zone1970.tab is a
> list of time zone names to be preferred over alternatives, then it
> seems like we ought to prefer them.
It's not really clear to me that the I
Hello,
I just realized that 7e534adcdc7 broke support for hypothetical
indexes using BRIN am. Attached patch fix the issue.
There's no interface to provide the hypothetical pagesPerRange value,
so I used the default one, and used simple estimates.
I'll add this patch to the next commitfest.
dif
On Tue, Jun 25, 2019 at 4:00 PM Amit Kapila wrote:
> [ new patches ]
I happened to open up 0001 from this series, which is from Thomas, and
I do not think that the pg_buffercache changes are correct. The idea
here is that the customer might install version 1.3 or any prior
version on an old rele
Hi, thanks for the patch.
On 2019-Jun-27, Julien Rouhaud wrote:
> I just realized that 7e534adcdc7 broke support for hypothetical
> indexes using BRIN am. Attached patch fix the issue.
>
> There's no interface to provide the hypothetical pagesPerRange value,
> so I used the default one, and use
On Thu, Jun 27, 2019 at 01:46:47PM -0400, Dave Cramer wrote:
On Thu, 27 Jun 2019 at 12:50, Tomas Vondra
wrote:
On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
>On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
> wrote:
>>
>> On 2019-04-12 19:52, Robert Treat wrote:
>> > It is clea
On Thu, Jun 27, 2019 at 8:14 PM Alvaro Herrera wrote:
>
> Hi, thanks for the patch.
Thanks for looking at it!
> On 2019-Jun-27, Julien Rouhaud wrote:
>
> > I just realized that 7e534adcdc7 broke support for hypothetical
> > indexes using BRIN am. Attached patch fix the issue.
> >
> > There's no
> 13 мая 2019 г., в 12:14, Michael Paquier написал(а):
>
> Decompression can matter a lot for mostly-read workloads and
> compression can become a bottleneck for heavy-insert loads, so
> improving compression or decompression should be two separate
> problems, not two problems linked. Any impr
On Thu, 27 Jun 2019 at 14:20, Tomas Vondra
wrote:
> On Thu, Jun 27, 2019 at 01:46:47PM -0400, Dave Cramer wrote:
> >On Thu, 27 Jun 2019 at 12:50, Tomas Vondra
> >wrote:
> >
> >> On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
> >> >On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
>
On 2019-Jun-27, Julien Rouhaud wrote:
> On Thu, Jun 27, 2019 at 8:14 PM Alvaro Herrera
> wrote:
> > I think it would look nicer to have a routine parallel to brinGetStats()
> > (brinGetStatsHypothetical?), instead of polluting selfuncs.c with these
> > gory details.
>
> I'm not opposed to it,
Alvaro Herrera writes:
> On 2019-Jun-27, Julien Rouhaud wrote:
>> On Thu, Jun 27, 2019 at 8:14 PM Alvaro Herrera
>> wrote:
>>> I think it would look nicer to have a routine parallel to brinGetStats()
>>> (brinGetStatsHypothetical?), instead of polluting selfuncs.c with these
>>> gory details.
>
Hi,
I noticed that the create_upper_paths_hook is never called for partially
grouped rels. Is this intentional or a bug? Only the FDW routine's
GetForeignUpperPaths hook is called for partially grouped rels. This seems
odd since the regular create_upper_paths_hook gets called for all other
upper r
=?UTF-8?Q?Erik_Nordstr=C3=B6m?= writes:
> I noticed that the create_upper_paths_hook is never called for partially
> grouped rels. Is this intentional or a bug? Only the FDW routine's
> GetForeignUpperPaths hook is called for partially grouped rels. This seems
> odd since the regular create_upper_
On 2019-Jun-27, Tom Lane wrote:
> FWIW, the proposed patch doesn't seem to me like it adds much more
> BRIN-specific knowledge to brincostestimate than is there already.
It's this calculation that threw me off:
statsData.revmapNumPages = (indexRanges / REVMAP_PAGE_MAXITEMS) + 1;
ISTM that
Alvaro Herrera writes:
> On 2019-Jun-27, Tom Lane wrote:
>> FWIW, the proposed patch doesn't seem to me like it adds much more
>> BRIN-specific knowledge to brincostestimate than is there already.
> It's this calculation that threw me off:
> statsData.revmapNumPages = (indexRanges / REVMAP_
On 2019-Jun-27, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Jun-27, Tom Lane wrote:
> >> FWIW, the proposed patch doesn't seem to me like it adds much more
> >> BRIN-specific knowledge to brincostestimate than is there already.
>
> > It's this calculation that threw me off:
> > stat
Alvaro Herrera writes:
> On 2019-Jun-27, Tom Lane wrote:
>> Um ... it's accounting for revmap pages already (which is why it needs
>> this field set), so hasn't that ship sailed?
> Yes, but does it need to know how many items there are in a revmap page?
Dunno, I just can't get excited about expo
On 2019-Jun-27, Tom Lane wrote:
> Dunno, I just can't get excited about exposing REVMAP_PAGE_MAXITEMS.
> Especially not since we seem to agree on the long-term solution here,
> and what you're suggesting to Julien doesn't particularly fit into
> that long-term solution.
Well, it was brin_page.h,
Thanks for the quick response. I do think this might be a separate issue
because in the set_rel_pathlist_hook case, that hook is actually called at
one point. In this case there is simply no place in the PostgreSQL code
where a call is made to create_upper_paths_hook for the
UPPERREL_PARTIAL_GROUP_
Robert Haas writes:
> On Tue, Jun 25, 2019 at 11:33 PM Tom Lane wrote:
>> Comments?
> LGTM.
Thanks for looking!
> s/must/should/ ?
Sure, if you like.
Further on the rolenames test mess: I started to work on removing
that script's creation of out-of-spec user names, but my heart just
sank to
On 27/06/2019 20:15, Andrey Borodin wrote:
But I have stupid question again, about this code:
https://github.com/x4m/postgres_g/commit/096d5586537d29ff316ca8ce074bbe1b325879ee#diff-754126824470cb8e68fd5e32af6d3bcaR417
nextFullXid = ReadNextFullTransactionId();
On 2019-Jun-27, Tom Lane wrote:
> Further on the rolenames test mess: I started to work on removing
> that script's creation of out-of-spec user names, but my heart just
> sank to the floor when I noticed that it was also doing stuff like
> this:
>
> ALTER USER ALL SET application_name to 'SLAP';
On Thu, Jun 27, 2019 at 11:38 PM Heikki Linnakangas wrote:
> * I moved the logic to extend a 32-bit XID to 64-bits to a new helper
> function in varsup.c.
I'm a bit uneasy about making this into a generally available function
for reuse. I think we should instead come up with a very small number
My previous patch missed a 1-line hunk, so resending.
>From 29e4c0b9700b9dee5f6ff2abc442e08e5221eb93 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 30 Apr 2019 19:05:53 -0500
Subject: [PATCH v3] print table associated with given TOAST table
---
src/bin/psql/describe.c | 22 +
On Fri, Feb 8, 2019 at 4:58 AM Thomas Munro
wrote:
> On Thu, May 17, 2018 at 3:49 AM Heikki Linnakangas wrote:
> > On 14/05/18 02:15, Thomas Munro wrote:
> > > The first sentence of that comment is no longer true as of commit
> > > c01262a8 (2013). As for whether it's necessary to predicate-lock
> "Tom" == Tom Lane writes:
> Robert Haas writes:
>> I'm kind of unsure what to think about this whole debate
>> substantively. If Andrew is correct that zone.tab or zone1970.tab is
>> a list of time zone names to be preferred over alternatives, then it
>> seems like we ought to prefer
On Thu, Jun 27, 2019 at 4:33 PM Thomas Munro wrote:
> Here's a patch I'd like to commit to fix the comment. We could look
> at improving the actual code after
> https://commitfest.postgresql.org/23/2169/ is done.
>
Change looks good to me.
> I wonder if it might be possible to avoid page lock
Hi!
On Mon, Jun 24, 2019 at 6:27 PM Andres Freund wrote:
> On June 24, 2019 8:19:13 AM PDT, Robert Haas wrote:
> >On Fri, Jun 21, 2019 at 7:01 PM Alexander Korotkov
> > wrote:
> >> On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro
> >wrote:
> >> > Thanks for the reviews! Pushed.
> >>
> >> Any ideas
Hello hackers,
The first Commitfest[1] for the next major release of PostgreSQL
begins in a few days, and runs for the month of July. There are 218
patches registered[2] right now, and I'm sure we'll see some more at
the last minute. PostgreSQL 13 needs you!
I volunteered to be the CF manager f
On Mon, Jun 24, 2019 at 8:43 PM Alvaro Herrera wrote:
>
> On 2019-Jun-22, Alexander Korotkov wrote:
>
> > 2. Also introduce FullMultixactId, and apply to MultixactId the
> > similar change as #1.
> > 3. Change SLRU on-disk format to handle 64-bit xids and multixacts.
> > In particular make SLRU pa
On Thu, Jun 27, 2019 at 4:57 PM Thom Brown wrote:
> On Wed, 19 Jun 2019 at 20:04, Alexander Korotkov
> wrote:
> > On Wed, Jun 19, 2019 at 7:07 PM Thom Brown wrote:
> > > On Thu, 13 Jun 2019 at 14:59, Thom Brown wrote:
> > > Also, this example doesn't work:
> > >
> > > '$.track ? (@.segments[*]
On Tue, Jun 25, 2019 at 6:38 PM Liudmila Mantrova
wrote:
> Thank you for the catch! Please see the modified version of patch 0004
> attached.
I tried to review and revise the part related to filters, but I failed
because I don't understand the notions used in the documentation.
What is the diffe
On Fri, Jun 28, 2019 at 1:02 AM Tomas Vondra
wrote:
> On Thu, Jun 27, 2019 at 01:53:52PM +0200, Daniel Gustafsson wrote:
> >> On 27 Jun 2019, at 13:05, Etsuro Fujita wrote:
> >
> >> since the citation was also moved to
> >> utils/misc/sampling.c, I think the "see full citation below" part
> >> sh
On 2019-Jun-28, Alexander Korotkov wrote:
> On Tue, Jun 25, 2019 at 6:38 PM Liudmila Mantrova
> wrote:
> > Thank you for the catch! Please see the modified version of patch 0004
> > attached.
>
> I tried to review and revise the part related to filters, but I failed
> because I don't understand
On Fri, Jun 28, 2019 at 12:55 PM Ashwin Agrawal wrote:
> Change looks good to me.
Pushed, thanks.
--
Thomas Munro
https://enterprisedb.com
On Thu, Jun 27, 2019 at 10:09 PM Alvaro Herrera
wrote:
>
> On 2019-Jun-27, Tom Lane wrote:
>
> > Dunno, I just can't get excited about exposing REVMAP_PAGE_MAXITEMS.
> > Especially not since we seem to agree on the long-term solution here,
> > and what you're suggesting to Julien doesn't particula
On Fri, Jun 28, 2019 at 8:10 AM Alvaro Herrera wrote:
>
> On 2019-Jun-28, Alexander Korotkov wrote:
>
> > On Tue, Jun 25, 2019 at 6:38 PM Liudmila Mantrova
> > wrote:
> > > Thank you for the catch! Please see the modified version of patch 0004
> > > attached.
> >
> > I tried to review and revise
On 2019-06-12 15:34, Tom Lane wrote:
> A bigger objection might be that this would leave us with no obvious-
> to-the-untrained-eye declaration point for either the struct name or
> the two typedef names. That might make tools like ctags sad. Perhaps
> it's not really any worse than today, but it
On Wed, Jun 26, 2019 at 10:29:05PM +1000, Haribabu Kommi wrote:
> Thanks for the review. Yes, that patch applies till 9.5, it is my mistake
> in naming the patch.
I have been able to finally set up an environment with VS 2019 (as
usual this stuff needs time, anyway..), and I can confirm that the
p
Hi, Michael-san.
> From: Michael Paquier
> On Wed, Jun 26, 2019 at 04:13:36AM +, nagaura.ryo...@fujitsu.com wrote:
> > I don't think that the rest one of my proposals has been rejected
> > completely, so I want to restart discussion.
> I recall on the matter that there was consensus that nobo
Hello,
The attached patch include the fix for all the comment given
regards
Surafel
On Mon, Apr 1, 2019 at 12:34 AM Andres Freund wrote:
> Hi,
>
> On 2019-03-29 12:04:50 +0300, Surafel Temesgen wrote:
>
> > + if (node->limitOption == PERCENTAGE)
> > +
Hello hackers,
While working on pg_dump I noticed the extra quote_all_identifiers in
_dumpOptions struct. I attached the patch.
It came from refactoring by 0eea8047bf. There is also a discussion:
https://www.postgresql.org/message-id/CACw0%2B13ZUcXbj9GKJNGZTkym1SXhwRu28nxHoJMoX5Qwmbg_%2Bw%40ma
On Thu, Jun 27, 2019 at 6:00 AM Tom Lane wrote:
> =?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=
> writes:
> > I'm looking at PostGIS geometry GiST index build times and try to
> optimize
> > withing the current GiST framework. The function that shows a lot on my
> > flame graphs is penalty
Hi,
I think commit 83e176ec1, which moved block sampling functions to
utils/misc/sampling.c, forgot to update this comment in
commands/analyze.c: "This algorithm is from Jeff Vitter's paper (see
full citation below)"; since the citation was also moved to
utils/misc/sampling.c, I think the "see ful
On Thu, Jun 27, 2019 at 12:04:30AM -0400, Tom Lane wrote:
Tomas Vondra writes:
OK. Attached is a patch ditching the alignment in serialized data. I've
ditched the macros to access parts of serialized data, and everything
gets copied.
I lack energy to actually read this patch right now, and I
On 26/06/2019 06:07, Thomas Munro wrote:
On Wed, Jun 26, 2019 at 2:33 PM Michael Paquier wrote:
On Tue, Jun 25, 2019 at 02:38:43PM +0500, Andrey Borodin wrote:
I feel a little uncomfortable with number 0x7fff right in code.
PG_INT32_MAX...
MaxTransactionId / 2?
Yeah, that makes sense
On several popular operating systems, we can use relative rpaths, using
the $ORIGIN placeholder, so that the resulting installation is
relocatable. Then we also don't need to set LD_LIBRARY_PATH during make
check.
This implementation will use a relative rpath if bindir and libdir are
under the sa
> On 27 Jun 2019, at 13:05, Etsuro Fujita wrote:
> since the citation was also moved to
> utils/misc/sampling.c, I think the "see full citation below" part
> should be updated accordingly. Attached is a patch for that.
Agreed, nice catch!
cheers ./daniel
> 27 июня 2019 г., в 16:38, Heikki Linnakangas написал(а):
>
> I haven't done any testing on this yet. Andrey, would you happen to have an
> environment ready to test this?
Thanks!
I will do some testing this evening (UTC+5). But I'm not sure I can reliably
test wraparound of xids...
I wil
Hi,
I searched the mailing list but found nothing. Any reason why
TupleDescAttr is a macro and not a static inline?
Rather than adding an Assert attached POC replace TupleDescAttr macro
by a static inline function with AssertArg.
It:
- Factorize Assert.
- Trigger an Assert in JIT_deform if natts
On Wed, 19 Jun 2019 at 20:04, Alexander Korotkov
wrote:
>
> On Wed, Jun 19, 2019 at 7:07 PM Thom Brown wrote:
> > On Thu, 13 Jun 2019 at 14:59, Thom Brown wrote:
> > >
> > > Hi,
> > >
> > > I've been reading through the documentation regarding jsonpath and
> > > jsonb_path_query etc., and I have
The ssl_ciphers GUC for configuring cipher suites sets the default value based
on USE_SSL but it’s actually an OpenSSL specific value. As with other such
changes, it works fine now but will become an issue should we support other TLS
backends. Attached patch fixes this.
cheers ./daniel
opens
Hi,
Here is a patch for the pg_receivewal documentation to highlight that
WAL isn't acknowledged to be applied.
I'll add a CF entry for it.
Best regards,
Jesper
>From 138e09c74db5ea08fd03b4e77853e2ca01742512 Mon Sep 17 00:00:00 2001
From: jesperpedersen
Date: Thu, 27 Jun 2019 09:54:44 -0400
Hi all,
Being interested by this feature, I did a patch review.
This features adds the GUC "max_slot_wal_keep_size". This is the maximum amount
of WAL that can be kept in "pg_wal" by active slots.
If the amount of WAL is superior to this limit, the slot is deactivated and
its status (new filed i
Does anyone know why there is no PG 12 stable branch in our git tree?
$ git branch -l
REL9_4_STABLE
REL9_5_STABLE
REL9_6_STABLE
REL_10_STABLE
REL_11_STABLE
master
They exist for earlier releases. Is this a problem?
--
Bruce
On Thu, Jun 27, 2019 at 10:28:40AM -0400, Bruce Momjian wrote:
> Does anyone know why there is no PG 12 stable branch in our git tree?
>
> $ git branch -l
> REL9_4_STABLE
> REL9_5_STABLE
> REL9_6_STABLE
> REL_10_STABLE
> REL_11_STABLE
> master
Bruce Momjian writes:
> Does anyone know why there is no PG 12 stable branch in our git tree?
For the record, I'm intending to make the branch as soon as the
July CF starts (i.e., first thing Monday).
regards, tom lane
On Thu, Jun 27, 2019 at 10:28:40AM -0400, Bruce Momjian wrote:
Does anyone know why there is no PG 12 stable branch in our git tree?
$ git branch -l
REL9_4_STABLE
REL9_5_STABLE
REL9_6_STABLE
REL_10_STABLE
REL_11_STABLE
master
T
On Thu, Jun 27, 2019 at 01:53:52PM +0200, Daniel Gustafsson wrote:
On 27 Jun 2019, at 13:05, Etsuro Fujita wrote:
since the citation was also moved to
utils/misc/sampling.c, I think the "see full citation below" part
should be updated accordingly. Attached is a patch for that.
Agreed, nice
On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
wrote:
On 2019-04-12 19:52, Robert Treat wrote:
> It is clear to me that the docs are wrong, but I don't see anything
> inherently incorrect about the code itself. Do you have suggest
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> In general, the point I'm trying to make is that our policy should
> Tom> be "Ties are broken arbitrarily, and if you don't like the choice
> Tom> that initdb makes, here's how to fix it".
> Yes, you've repeated that point at some lengt
> 27 июня 2019 г., в 16:38, Heikki Linnakangas написал(а):
>
> I haven't done any testing on this yet. Andrey, would you happen to have an
> environment ready to test this?
Patches do not deadlock and delete pages on "rescan test" - setup that we used
to detect "left jumps" in during develo
On Tue, Jun 25, 2019 at 8:18 PM Tom Lane wrote:
> As long as we have a trivial and obviously apolitical rule like
> alphabetical order, I think we can skate over such things; but the minute
> we have any sort of human choices involved there, we're going to be
> getting politically driven requests
On Tue, Jun 25, 2019 at 11:33 PM Tom Lane wrote:
> Comments?
LGTM.
s/must/should/ ?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, 27 Jun 2019 at 12:50, Tomas Vondra
wrote:
> On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
> >On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
> > wrote:
> >>
> >> On 2019-04-12 19:52, Robert Treat wrote:
> >> > It is clear to me that the docs are wrong, but I don't see any
Robert Haas writes:
> I'm kind of unsure what to think about this whole debate
> substantively. If Andrew is correct that zone.tab or zone1970.tab is a
> list of time zone names to be preferred over alternatives, then it
> seems like we ought to prefer them.
It's not really clear to me that the I
Hello,
I just realized that 7e534adcdc7 broke support for hypothetical
indexes using BRIN am. Attached patch fix the issue.
There's no interface to provide the hypothetical pagesPerRange value,
so I used the default one, and used simple estimates.
I'll add this patch to the next commitfest.
dif
On Tue, Jun 25, 2019 at 4:00 PM Amit Kapila wrote:
> [ new patches ]
I happened to open up 0001 from this series, which is from Thomas, and
I do not think that the pg_buffercache changes are correct. The idea
here is that the customer might install version 1.3 or any prior
version on an old rele
Hi, thanks for the patch.
On 2019-Jun-27, Julien Rouhaud wrote:
> I just realized that 7e534adcdc7 broke support for hypothetical
> indexes using BRIN am. Attached patch fix the issue.
>
> There's no interface to provide the hypothetical pagesPerRange value,
> so I used the default one, and use
On Thu, Jun 27, 2019 at 01:46:47PM -0400, Dave Cramer wrote:
On Thu, 27 Jun 2019 at 12:50, Tomas Vondra
wrote:
On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
>On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
> wrote:
>>
>> On 2019-04-12 19:52, Robert Treat wrote:
>> > It is clea
On Thu, Jun 27, 2019 at 8:14 PM Alvaro Herrera wrote:
>
> Hi, thanks for the patch.
Thanks for looking at it!
> On 2019-Jun-27, Julien Rouhaud wrote:
>
> > I just realized that 7e534adcdc7 broke support for hypothetical
> > indexes using BRIN am. Attached patch fix the issue.
> >
> > There's no
> 13 мая 2019 г., в 12:14, Michael Paquier написал(а):
>
> Decompression can matter a lot for mostly-read workloads and
> compression can become a bottleneck for heavy-insert loads, so
> improving compression or decompression should be two separate
> problems, not two problems linked. Any impr
On Thu, 27 Jun 2019 at 14:20, Tomas Vondra
wrote:
> On Thu, Jun 27, 2019 at 01:46:47PM -0400, Dave Cramer wrote:
> >On Thu, 27 Jun 2019 at 12:50, Tomas Vondra
> >wrote:
> >
> >> On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
> >> >On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
>
On 2019-Jun-27, Julien Rouhaud wrote:
> On Thu, Jun 27, 2019 at 8:14 PM Alvaro Herrera
> wrote:
> > I think it would look nicer to have a routine parallel to brinGetStats()
> > (brinGetStatsHypothetical?), instead of polluting selfuncs.c with these
> > gory details.
>
> I'm not opposed to it,
1 - 100 of 128 matches
Mail list logo
