On Fri, Jun 28, 2019 at 09:42:54AM -0400, Adam Berlin wrote:
> If we were to use this tool, would the community want to vendor the
> framework in the Postgres repository, or keep it in a separate repository
> that produces a versioned shared library?
Well, my take is that having a base infrastruct
On Tue, Jul 2, 2019 at 12:35 AM Alvaro Herrera
wrote:
> On 2019-Apr-19, Paul Guo wrote:
>
> > The below patch runs single mode Postgres if needed to make sure the
> target
> > is cleanly shutdown. A new option is added (off by default).
> > v2-0001-Ensure-target-clean-shutdown-at-beginning-of-pg_
Rebased, aligned with recent changes in pg_rewind/pg_basebackup and then
retested. Thanks.
On Mon, Jul 1, 2019 at 7:35 PM Thomas Munro wrote:
> On Fri, Apr 19, 2019 at 3:41 PM Paul Guo wrote:
> > I updated the patches as attached following previous discussions.
>
> Hi Paul,
>
> Could we please
On Mon, Jul 01, 2019 at 11:11:43PM +0200, Daniel Gustafsson wrote:
> I very much agree that functions operating on a buffer like this should have
> the size of the buffer in order to safeguard against overflow, so +1 on the
> general concept.
Thanks for the review!
> A few small comments:
>
> In
On Tue, Jul 2, 2019 at 4:44 AM Michael Paquier wrote:
>
> On Sat, Jun 29, 2019 at 11:24:49AM +0900, Michael Paquier wrote:
> > Thanks for the rebase (and the reminder..). I'll look at that once
> > v13 opens for business.
>
> And applied.
Thanks!
On Mon, Jul 01, 2019 at 07:56:29PM +1000, Haribabu Kommi wrote:
> We stopped the support of building with all the visual studio versions less
> than 2013. I updated the SDK versions accordingly.
I have spent some time looking around, and wikipedia-sensei has proved
to be helpful to grasp the rele
[ warning, drive-by comment ahead ]
Fabien COELHO writes:
> I notice that other distance tests do not test for commutativity. Are they
> also not implemented, or just not tested? If not implemented, I'd suggest
> to add them in the same batch.
Yeah ... just looking at operators named <->, I se
On Mon, Jul 1, 2019 at 7:28 PM Tom Lane wrote:
> Even more interesting, the same para also exists verbatim in
> v4r2's src/backend/access/nobtree/nobtpage.c, which is dated 1991-10-29
> in the same tarball. (If you're wondering, "nobtree" seems to stand
> for "no-overwrite btree"; so I suppose it
On Mon, Jul 01, 2019 at 06:14:20PM +0200, Julien Rouhaud wrote:
> On Mon, Jul 1, 2019 at 3:51 PM Alvaro Herrera
> wrote:
> >
> > Please don't reuse a file name as generic as "parallel.c" -- it's
> > annoying when navigating source. Maybe conn_parallel.c multiconn.c
> > connscripts.c admconnectio
On Mon, Jul 01, 2019 at 06:28:13PM +0200, Julien Rouhaud wrote:
> On Mon, Jul 1, 2019 at 4:10 PM Tom Lane wrote:
>> Couldn't we make this enormously simpler and less bug-prone by just
>> dictating that --jobs applies only to reindex-table operations?
I had the same argument about the first patch
On Sat, Jun 29, 2019 at 11:24:49AM +0900, Michael Paquier wrote:
> Thanks for the rebase (and the reminder..). I'll look at that once
> v13 opens for business.
And applied.
--
Michael
signature.asc
Description: PGP signature
Peter Geoghegan writes:
> On Sun, Jun 23, 2019 at 3:36 AM Thomas Munro wrote:
>> Pushed. Thanks!
> I wonder what the comment is supposed to mean.
> I think that it's addressing the situation prior to commit 70508ba7aed
> in 2003, which was the point when the "fast" root concept was
> introduced
On Sun, Jun 23, 2019 at 3:36 AM Thomas Munro wrote:
> Pushed. Thanks!
I wonder what the comment is supposed to mean.
I think that it's addressing the situation prior to commit 70508ba7aed
in 2003, which was the point when the "fast" root concept was
introduced. Prior to that commit, there was o
movead li writes:
> I applied the 'alter-table-with-recursive-process-utility-calls-wip.patch'
> on the master(e788e849addd56007a0e75f3b5514f294a0f3bca). And
> when I test the cases, I find it works well on 'alter table t1 add column
> f2 int not null, alter column f2 add generated always as iden
Andres Freund writes:
> Tom, any comments? Otherwise I'll go ahead, and commit after a round or
> two of polishing.
Sorry for not getting to this sooner --- I'll try to look tomorrow.
regards, tom lane
Hi,
On 2019-06-18 00:00:28 -0700, Andres Freund wrote:
> On 2019-06-13 16:23:34 -0700, Andres Freund wrote:
> > On June 13, 2019 3:38:47 PM PDT, Tom Lane wrote:
> > >Andres Freund writes:
> > >> I am too tired to look further into this. I suspect the only reason
> > >we
> > >> didn't previously
On Sun, Jun 30, 2019 at 9:07 AM Robert Haas wrote:
> On Mon, Jun 24, 2019 at 1:43 PM Alvaro Herrera
> wrote:
> > I think enlarging multixacts to 64 bits is a terrible idea. I would
> > rather get rid of multixacts completely; zheap is proposing not to use
> > multixacts at all, for example.
>
>
On Sat, Jun 22, 2019 at 11:01 AM Alexander Korotkov
wrote:
> 3. Change SLRU on-disk format to handle 64-bit xids and multixacts.
> In particular make SLRU page numbers 64-bit too. Add SLRU upgrade
> procedure to pg_upgrade.
+1 for doing this for the xid-indexed SLRUs so the segment file names
ar
Hi,
On 2019-06-29 22:15:19 +0200, Tomas Vondra wrote:
> I think we should consider changing the effective_io_concurrency default
> value, i.e. the guc that determines how many pages we try to prefetch in
> a couple of places (the most important being Bitmap Heap Scan).
Maybe we need improve the w
I spent some time experimenting with the idea mentioned upthread of
adding a macro to support deletion of a foreach loop's current element
(adjusting the loop's state behind the scenes). This turns out to work
really well: it reduces the complexity of fixing existing loops around
element deletions
On 2019-06-12 16:06, Tom Lane wrote:
> Peter Eisentraut writes:
> I checked around a bit ... all of the *BSD systems in the buildfarm
> report ELF_SYS='true', so it's safe to say that the code you want to
> remove is untested.
>
> Excavation in the various BSDens' change logs suggests that the la
On Fri, 2019-05-03 at 15:56 -0700, Paul Jungwirth wrote:
> Hello,
>
> I wrote an extension to add a range_agg function with similar
> behavior
> to existing *_agg functions, and I'm wondering if folks would like
> to
> have it in core? Here is the repo:
> https://github.com/pjungwir/range_agg
On 2019-Jul-02, Thomas Munro wrote:
> On Tue, Jul 2, 2019 at 8:34 AM Julien Rouhaud wrote:
> > Even if that's just me being delusional, I'd still prefer Alvaro's
> > approach to have distinct switches for each collation system.
>
> Hi Julien,
>
> Makes sense. But why use the name "glibc" in th
On Tue, Jul 2, 2019 at 8:34 AM Julien Rouhaud wrote:
> Even if that's just me being delusional, I'd still prefer Alvaro's
> approach to have distinct switches for each collation system.
Hi Julien,
Makes sense. But why use the name "glibc" in the code and user
interface? The name of the collati
On Mon, Jul 1, 2019 at 1:34 PM Julien Rouhaud wrote:
> I have a vague recollection that ICU was providing some backward
> compatibility so that even if you upgrade your lib you can still get
> the sort order that was active when you built your indexes, though
> maybe for a limited number of versio
> On 23 Jun 2019, at 15:25, Michael Paquier wrote:
> Attached is a refactoring patch for those interfaces, which introduces
> a set of overflow checks so as we cannot repeat errors of the past.
I’ve done a review of this submission. The patch applies cleanly, and passes
make check, ssl/scram te
On Mon, Jul 1, 2019 at 10:13 PM Daniel Verite wrote:
>
> > > I think you'd be better off to define and document this as "reindex
> > > only collation-sensitive indexes", without any particular reference
> > > to a reason why somebody might want to do that.
> >
> > We should still document that ind
On 2019-Jul-01, Daniel Verite wrote:
> But why exclude them?
> As a data point, in the last 5 years, the en_US collation in ICU
> had 7 different versions (across 11 major versions of ICU):
So we need a switch --include-rule=icu-collations?
(I mentioned "--exclude-rule=glibc" elsewhere in the th
Julien Rouhaud wrote:
> > I think you'd be better off to define and document this as "reindex
> > only collation-sensitive indexes", without any particular reference
> > to a reason why somebody might want to do that.
>
> We should still document that indexes based on ICU would be exluded
On Fri, Jun 28, 2019 at 1:47 PM Amit Kapila wrote:
> On Mon, Jun 24, 2019 at 11:26 PM Ashwin Agrawal
> wrote:
> >
> > On Mon, Jun 3, 2019 at 5:24 PM Ashwin Agrawal
> wrote:
> >>
> >> There were few more minor typos I had collected for table am, passing
> them along here.
> >>
> >> Some of the r
Hi,
On 7/1/19 2:44 PM, Tom Lane wrote:
Yup, here's a rebase against HEAD (and I also find that check-world shows
no problems).
Thanks - no further comments.
This is pretty much of a pain to maintain, since it changes
the API for lnext() which is, um, a bit invasive. I'd like to make a
deci
On Thu, May 30, 2019 at 8:07 AM DEV_OPS wrote:
>
> it's really cool and very good progress,
>
> I'm interesting if SIDM/JIT will be supported
>
That's something outside of Zedstore work directly at least now. The intent
is to work with current executor code or enhance it only wherever needed.
If
This is for design review. I have a patch (WIP) for Approach 1, and if
this discussion starts to converge on that approach I will polish and
post it.
Let's start at the beginning: why do we have two strategies -- hash
and sort -- for aggregating data? The two are more similar than they
first appea
On Sun, Jun 30, 2019 at 7:59 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Ashwin Agrawal [mailto:aagra...@pivotal.io]
> > The objective is to gather feedback on design and approach to the same.
> > The implementation has core basic pieces working but not close to
> compl
Jesper Pedersen writes:
> This needs a rebase. After that check-world passes w/ and w/o
> -DDEBUG_LIST_MEMORY_USAGE.
Yup, here's a rebase against HEAD (and I also find that check-world shows
no problems). This is pretty much of a pain to maintain, since it changes
the API for lnext() which is,
It strikes me that the way to avoid sentence construction is to have
each enum reloption declare a string that it uses to list the values it
accepts. So for example we would have
+#define GIST_OPTION_BUFFERING_ENUM_DEF { \
+ { "on", GIST_OPTION_BUFFERING_ON }, \
+ { "off",GIST_
It seems strange to have relation_reloptions which abstracts away the
need to know which function to call for each relkind, and separately
have a bunch of places that call the specific relkind. Why not just
call the specific function directly? It doesn't seem that we're gaining
any abstraction ..
Hello,
we use atoi for user argument processing in same place which return zero
for both invalid input and input value zero. In most case its ok because we
error out with appropriate error message for input zero but in same place
where we accept zero as valued input it case a problem by preceding
On 01.07.2019 13:41, Thomas Munro wrote:
On Tue, Mar 26, 2019 at 4:30 AM Nikita Glukhov wrote:
Fixed two bugs in patches 3 and 10 (see below).
Patch 3 was extracted from the main patch 5 (patch 4 in v9).
This patch no longer applies so marking Waiting on Author.
Attached 11th version of the
Hi Thomas
On Mon, Jul 1, 2019 at 1:31 PM Thomas Munro wrote:
> On Mon, Apr 8, 2019 at 8:26 PM Surafel Temesgen
> wrote:
> > agree
>
> Hi Surafel,
>
> A new Commitfest is starting. Can you please post a fresh rebase of this
> patch?
>
>
Thank you for informing. attach is a rebased patch against
Hi,
On 5/25/19 11:48 AM, Tom Lane wrote:
The cfbot noticed a set-but-not-used variable that my compiler hadn't
whined about. Here's a v5 to pacify it. No other changes.
This needs a rebase. After that check-world passes w/ and w/o
-DDEBUG_LIST_MEMORY_USAGE.
There is some unneeded MemoryC
Do we have an actual patch here?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-Apr-19, Paul Guo wrote:
> The below patch runs single mode Postgres if needed to make sure the target
> is cleanly shutdown. A new option is added (off by default).
> v2-0001-Ensure-target-clean-shutdown-at-beginning-of-pg_r.patch
Why do we need an option for this? Is there a reason not
On Mon, Jul 1, 2019 at 4:10 PM Tom Lane wrote:
>
> Michael Paquier writes:
> > - 0003 begins to be the actual fancy thing with the addition of a
> > --jobs option into reindexdb. The main issue here which should be
> > discussed is that when it comes to reindex of tables, you basically
> > are n
On Mon, Jul 1, 2019 at 3:51 PM Alvaro Herrera wrote:
>
> Please don't reuse a file name as generic as "parallel.c" -- it's
> annoying when navigating source. Maybe conn_parallel.c multiconn.c
> connscripts.c admconnection.c ...?
I could use scripts_parallel.[ch] as I've already used it in the #d
Justin Pryzby writes:
> I'm resending this patch, which still seems to be needed.
Yeah, clearly one copy of that text got missed out. Pushed that.
> Also, should this be removed ? Or at leat remove the parenthesized text,
> since
> non-system tables no longer have OIDs: "(use to avoid output
I'm resending this patch, which still seems to be needed.
Also, should this be removed ? Or at leat remove the parenthesized text, since
non-system tables no longer have OIDs: "(use to avoid output on system tables)"
https://www.postgresql.org/docs/devel/runtime-config-developer.html
trace_lock_
On 29/06/2019 00:23, Julien Rouhaud wrote:
> On Fri, Jun 28, 2019 at 10:16 PM Tom Lane wrote:
>>
>> Tomas Vondra writes:
>>> On Fri, Jun 28, 2019 at 03:03:19PM -0400, Tom Lane wrote:
I not only don't want that function in indxpath.c, I don't even want
it to be known/called from there.
On 01.07.2019 12:51, Thomas Munro wrote:
On Wed, Apr 10, 2019 at 12:52 AM Konstantin Knizhnik
wrote:
New version of the patching disabling autoprepare for rules and handling
planner error.
Hi Konstantin,
This doesn't apply. Could we please have a fresh rebase for the new Commitfest?
Thanks
On Mon, Jul 1, 2019 at 5:51 PM Alvaro Herrera wrote:
> On 2019-Jul-01, Alexander Korotkov wrote:
>
> > As I get we're currently need to make high-level decision of whether
> > we need this [1]. I was going to bring this topic up at last PGCon,
> > but I didn't manage to attend. Does it worth bot
Hi hackers,
I have found two minor issues with unified logging system for
command-line programs (commited by Peter cc8d415117), while was rebasing
my pg_rewind patch:
1) forgotten new-line symbol in pg_fatal call inside pg_rewind, which
will cause the following Assert in common/logging.c to
On 01.07.2019 12:57, Thomas Munro wrote:
On Thu, Mar 21, 2019 at 4:33 AM Konstantin Knizhnik
wrote:
New version of the patch (rebased + bug fixes) is attached to this mail.
Hi again Konstantin,
Interesting work. No longer applies -- please rebase.
Rebased version of the patch is attached
On 2019-Jul-01, Alexander Korotkov wrote:
> As I get we're currently need to make high-level decision of whether
> we need this [1]. I was going to bring this topic up at last PGCon,
> but I didn't manage to attend. Does it worth bothering Ildus with
> continuous rebasing assuming we don't have
Hi Thomas,
On 01.07.2019 15:02, Thomas Munro wrote:
Hi Alexey,
This no longer applies. Since the Commitfest is starting now, could
you please rebase it?
Thank you for a reminder. Rebased version of the patch is attached. I've
also modified my logging code in order to obey new unified loggi
Michael Paquier writes:
> - 0003 begins to be the actual fancy thing with the addition of a
> --jobs option into reindexdb. The main issue here which should be
> discussed is that when it comes to reindex of tables, you basically
> are not going to have any conflicts between the objects manipulat
Now that we have REINDEX CONCURRENTLY, I think reindexdb is going to
gain more popularity.
Please don't reuse a file name as generic as "parallel.c" -- it's
annoying when navigating source. Maybe conn_parallel.c multiconn.c
connscripts.c admconnection.c ...?
If your server crashes or is stopped
Hi!
> Andrey Borodin 于2019年6月29日周六 下午9:48写道：
> Hi!
> Please, do not use top-posting, i.e. reply style where you quote whole
> message under your response. It makes reading of archives terse.
>
> > 24 июня 2019 г., в 7:53, Binguo Bao написал(а):
> >
> >> This is not correct: L bytes of compresse
On Sun, 30 Jun 2019 at 17:54, David Rowley wrote:
> Any further thoughts on this Michael?
>
> Or Andres? Do you have a preference to which of the approaches
> (mentioned upthread) I use for the fix?
>
> If I don't hear anything I'll probably just push the first fix. The
> inefficiency does not af
Hello hackers,
It's now July everywhere on Earth, so I marked CF 2019-07 as
in-progress, and 2019-09 as open for bumping patches into. I pinged
most of the "Needs Review" threads that don't apply and will do a few
more tomorrow, and then I'll try to chase patches that fail on CI, and
then see wha
Hello
This change is discussed as open item for pg12. Seems we have nor objections
nor agreement. I attached updated version due merge conflict.
> Per discussion started here:
> https://www.postgresql.org/message-id/CA%2BTgmoZWSLUjVcc9KBSVvbn%3DU5QRgW1O-MgUX0y5CnLZOA2qyQ%40mail.gmail.com
regar
On Thu, Mar 28, 2019 at 6:49 AM Alexey Kondratov
wrote:
> Updated version of patch is attached.
Hi Alexey,
This no longer applies. Since the Commitfest is starting now, could
you please rebase it?
Thanks,
--
Thomas Munro
https://enterprisedb.com
On Tue, Mar 5, 2019 at 10:19 PM David Steele wrote:
> On 2/28/19 10:43 AM, Osumi, Takamichi wrote:
> > One past thread about introducing CREATE OR REPLACE TRIGGER into the syntax
> >
> > had stopped without complete discussion in terms of LOCK level.
> >
> > The past thread is this. I'd like to in
On Mon, Apr 1, 2019 at 4:36 AM Nikolay Shaplov wrote:
> В письме от понедельник, 18 марта 2019 г. 3:03:04 MSK пользователь Iwata, Aya
> написал:
> > This patch does not apply.
> Oh... Sorry... here goes new version
Hi Nikolay,
Could we please have a new rebase?
Thanks,
--
Thomas Munro
https:/
On Wed, Apr 3, 2019 at 2:12 AM Ibrar Ahmed wrote:
> I start looking at the patch, there is a couple of problems with the patch.
> The first one is the OID conflict, which I fixed on my machine. The second
> problem is assertion failure. I think you have not compiled the PostgreSQL
> code with t
On Fri, Apr 19, 2019 at 3:41 PM Paul Guo wrote:
> I updated the patches as attached following previous discussions.
Hi Paul,
Could we please have a fresh rebase now that the CF is here?
Thanks,
--
Thomas Munro
https://enterprisedb.com
Hello
Updated version attached. Merge conflict was about tests count in
001_stream_rep.pl. Nothing else was changed. My approach can be still
incorrect, any redesign ideas are welcome. Thanks in advance!
regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 84341
On Wed, Apr 17, 2019 at 10:23 PM Masahiko Sawada wrote:
> Sorry for the very late. Attached updated version patches.
Hello Sawada-san,
Can we please have a fresh rebase?
Thanks,
--
Thomas Munro
https://enterprisedb.com
On Tue, Apr 2, 2019 at 9:22 AM legrand legrand
wrote:
>
> >> case avg_tps pct_diff
> >> 089 278 --
> >> 188 745 0,6%
> >> 288 282 1,1%
> >> 386 660 2,9%
> >>
> >> This means that even in this extrem test case, the worst degradation is
> >> less
> >> than
On Tue, Mar 26, 2019 at 7:25 PM David Steele wrote:
> On 3/26/19 8:11 AM, Edmund Horner wrote:
> > Should I set update CF app to a) set the target version to 13, and/or
> > move it to next commitfest?
>
> If you plan to continue working on it in this CF then you can just
> change the target to PG1
On Mon, 27 May 2019 at 20:43, Antonin Houska wrote:
> I've spent some time looking into this.
Thank you for having a look at this.
> One problem I see is that SubLink can be in the JOIN/ON clause and thus it's
> not necessarily at the top of the join tree. Consider this example:
>
> CREATE TABLE
On Fri, May 17, 2019 at 6:48 PM Kyotaro HORIGUCHI
wrote:
> Fixed. Version 20.
Hello Horiguchi-san,
A new Commitfest is here. This doesn't apply (maybe just because of
the new improved pgindent). Could we please have a fresh rebase?
Thanks,
--
Thomas Munro
https://enterprisedb.com
On Mon, Jul 1, 2019 at 6:50 PM Thomas Munro wrote:
> On Sat, May 18, 2019 at 12:20 AM Robert Haas wrote:
> > On Tue, May 14, 2019 at 12:24 AM Amit Langote
> > wrote:
> > > He did mention that cases where the nullable side is provably empty can be
> > > handled by simply returning the path of the
Hi All,
There is an interesting issue: I created one replication slot,
specifying pgouput plugin and one publication "foobar". The
publication "foobar" was set to tables "foo1, foo2".
The slot was left unread, while the tables foo1 and foo2 get changed.
Then, I alter the publication "foobar" to r
On Sun, Mar 31, 2019 at 2:13 PM wrote:
> Thanks for review.
Hi Sergey,
A new Commitfest is here and this doesn't apply -- could you please
post a rebase?
Thanks,
--
Thomas Munro
https://enterprisedb.com
On Fri, May 3, 2019 at 6:06 AM Thomas Munro wrote:
> Added to commitfest.
Rebased.
--
Thomas Munro
https://enterprisedb.com
0001-Make-file_fdw-parallel-aware-v3.patch
Description: Binary data
On Sat, 29 Jun 2019 at 14:01, Tomas Vondra wrote:
>
> >However, it looks like the problem is with mcv_list_items()'s use
> >of %f to convert to text, which is pretty ugly.
>
> >>>There's one issue with the signature, though - currently the function
> >>>returns null flags as bool arra
On Wednesday, June 26, 2019 6:10 PM(GMT+9), Adrien Nayrat wrote:
> As far as I remember, you should see "relation" wait events (type lock) on
> standby server. This is due to startup process acquiring AccessExclusiveLock
> for the truncation and other backend waiting to acquire a lock to read the
>
> >> On 2/22/19 2:05 AM, Nikita Glukhov wrote:
> >>> Attached set of patches with some jsonb optimizations that were made
> >>> during
> >>> comparison of performance of ordinal jsonb operators and jsonpath
> >>> operators.
Hi Nikita,
This doesn't apply -- to attract reviewers, could we please ha
Hi, Thomas!
On Mon, Jul 1, 2019 at 1:22 PM Thomas Munro wrote:
>
> On Sat, Mar 16, 2019 at 12:52 AM Ildus Kurbangaliev
> wrote:
> > in my opinion this patch is usually skipped not because it is not
> > needed, but because of its size. It is not hard to maintain it until
> > commiters will have t
On Mon, Mar 25, 2019 at 8:30 PM Alexander Lakhin wrote:
> 25.03.2019 10:25, David Steele wrote:
> > If it doesn't attract more review or a committer during this CF, I
> > think we should mark it as rejected.
> Please, delay rejecting it till the end of the commitfest, I'll try to
> find some enth
On Tue, Mar 26, 2019 at 4:30 AM Nikita Glukhov wrote:
> >> Fixed two bugs in patches 3 and 10 (see below).
> >> Patch 3 was extracted from the main patch 5 (patch 4 in v9).
> >
> > This patch no longer applies so marking Waiting on Author.
> >
> Attached 11th version of the patches rebased onto cu
On Mon, Apr 8, 2019 at 8:26 PM Surafel Temesgen wrote:
> agree
Hi Surafel,
A new Commitfest is starting. Can you please post a fresh rebase of this patch?
Thanks,
--
Thomas Munro
https://enterprisedb.com
On Mon, Jul 1, 2019 at 10:55 AM Michael Paquier wrote:
>
> On Sun, Jun 30, 2019 at 11:45:47AM +0200, Julien Rouhaud wrote:
> > With the glibc 2.28 coming, all users will have to reindex almost
> > every indexes after a glibc upgrade to guarantee the lack of
> > corruption. Unfortunately, reindexd
On Sat, Mar 16, 2019 at 12:52 AM Ildus Kurbangaliev
wrote:
> in my opinion this patch is usually skipped not because it is not
> needed, but because of its size. It is not hard to maintain it until
> commiters will have time for it or I will get actual response that
> nobody is going to commit it.
On Mon, 3 Jun 2019 at 16:32, Haribabu Kommi
wrote:
>
>
> On Thu, Apr 11, 2019 at 9:13 AM Haribabu Kommi
> wrote:
>
>> I fixed all the comments that you have raised above and attached the
>> updated
>> patches.
>>
>
> Rebased patches are attached.
>
Rebased patches are attached.
Regards,
Hariba
On Thu, Mar 21, 2019 at 4:33 AM Konstantin Knizhnik
wrote:
> New version of the patch (rebased + bug fixes) is attached to this mail.
Hi again Konstantin,
Interesting work. No longer applies -- please rebase.
--
Thomas Munro
https://enterprisedb.com
On Thu, 27 Jun 2019 at 17:28, Michael Paquier wrote:
> 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
> us
On Tue, May 21, 2019 at 9:12 PM Antonin Houska wrote:
> Robert Haas wrote:
> > It seems to me that it's better to unwind the stack i.e. have the
> > function return the error information to the caller and let the caller
> > do as it likes.
>
> Thanks for a hint. The next version tries to do that.
On Wed, Apr 10, 2019 at 12:52 AM Konstantin Knizhnik
wrote:
> New version of the patching disabling autoprepare for rules and handling
> planner error.
Hi Konstantin,
This doesn't apply. Could we please have a fresh rebase for the new Commitfest?
Thanks,
--
Thomas Munro
https://enterprisedb.c
On Sat, May 18, 2019 at 12:20 AM Robert Haas wrote:
> On Tue, May 14, 2019 at 12:24 AM Amit Langote
> wrote:
> > He did mention that cases where the nullable side is provably empty can be
> > handled by simply returning the path of the non-nullable side with
> > suitable projection path added on
> On 28 Jun 2019, at 17:30, Tom Lane wrote:
> > Yeah, I think the feature as-proposed is a shotgun that's much more likely
> > to cause problems than solve them. Almost certainly, what people would
> > really need is the ability to dump individual foreign tables' data not
> > everything. (I al
On Mon, Mar 25, 2019 at 9:39 PM David Steele wrote:
> It's not clear to me that all of Michael's and Álvaro's issues have been
> addressed, so I've marked this Waiting on Author.
Hi Nikolay,
To help reviewers for the Commitfest that is starting, could you
please rebase this patch?
--
Thomas Mu
On Tue, Mar 19, 2019 at 1:04 PM Matheus de Oliveira
wrote:
> Sorry for the long delay. I've rebased the patch to current master (at
> f2004f19ed now), attached as postgresql-alter-constraint.v4.patch. All tests
> passed cleanly.
Hi Matheus,
As the commitfest is starting, could you please send
On Sun, Jun 30, 2019 at 11:45:47AM +0200, Julien Rouhaud wrote:
> With the glibc 2.28 coming, all users will have to reindex almost
> every indexes after a glibc upgrade to guarantee the lack of
> corruption. Unfortunately, reindexdb is not ideal for that as it's
> processing everything using a si
On Mon, Jul 1, 2019 at 7:53 PM Thomas Munro wrote:
> 3. Recognise UNDO_SHARED record set boundaries differently. Whereas
> undolog.c recognises transaction boundaries automatically for the
> other categories (UNDO_PERMANENT, UNDO_UNLOGGED, UNDO_TEMP), for
> UNDO_SHARED the
... set of records in
> On 29 Jun 2019, at 04:23, Michael Paquier wrote:
>
> On Fri, Jun 28, 2019 at 08:47:33PM +0200, Julien Rouhaud wrote:
>> On Fri, Jun 28, 2019 at 4:37 PM Daniel Gustafsson wrote:
>>> backend/libpq/be-secure-gssapi.c is including both libpq-be.h and libpq.h,
>>> which makes libpq-be.h superfluous
Hello,
my_gripe> But, still fluctulates by around 5%..
my_gripe>
my_gripe> If this level of the degradation is still not acceptable, that
my_gripe> means that nothing can be inserted in the code path and the new
my_gripe> code path should be isolated from existing code by using indirect
my_gripe
97 matches
Mail list logo
