(2019/01/23 20:35), Etsuro Fujita wrote:
> Attached is an updated version of the patch.
>
> Changes:
> * Fixed a stupid bug in the case when use_remote_estimate
> * Fixed a typo in a comment I added
> * Modified comments I added a little bit further
> * Added the commit message
>
> If there are n
On Wed, Jan 23, 2019 at 1:35 AM, Amit Langote wrote:
> Rebased due to the heap_open/close() -> table_open/close() change.
Maybe there are not many things I can point out through reviewing the patch, so
I ran the performance test against v17 patches instead of reviewing codes.
There are already a
Kyotaro HORIGUCHI writes:
> With the attached patch, external modules are loaded RTLD_LOCAL
> by default. PG_MODULE_EXPORT_SYMBOL in a module source files let
> it loaded RTLD_GLOBAL. I suppose this is the change with the
> least impact on existing modules because I believe most of them
> don't ne
Hello.
At Mon, 26 Feb 2018 23:50:41 +0200, Ants Aasma wrote in
> On Mon, Feb 26, 2018 at 11:28 PM, Andres Freund wrote:
> > So RTLD_LOCAL is out of the question, but I think we can get a good bit
> > of the benefit by either specifying -Wl,-Bsymbolic at shlib build time,
> > or RTLD_DEEPBIND a
Oh, I just noticed something else: several of the ecpg test programs
contain
#ifdef WIN32
#ifdef _MSC_VER/* requires MSVC */
_configthreadlocale(_ENABLE_PER_THREAD_LOCALE);
#endif
#endif
Surely this is a kluge that we could now remove? We've protected the
only setlocale c
On Thu, Jan 24, 2019 at 3:39 AM John Naylor wrote:
>
> On Mon, Jan 21, 2019 at 6:32 AM Amit Kapila wrote:
> > Also, another case to think in this regard is the upgrade for standby
> > servers, if you read below paragraph from the user manual [1], you
> > will see what I am worried about?
> >
> >
On 2019/01/24 12:03, Alvaro Herrera wrote:
> On 2019-Jan-24, Amit Langote wrote:
>
>> Fixed in the attached. We don't support inheriting EXCLUSION constraints
>> yet, so no need to consider their indexes.
>
> Looks good, pushed.
Thank you.
Regards,
Amit
I wrote:
> This suggests that, rather than throwing up our hands if the initial
> _configthreadlocale call returns -1, we should act as though the function
> doesn't exist, and just soldier on the same as before. The code in there
> assumes that -1 is a can't-happen case and doesn't try to recover
On Wed, Jan 23, 2019 at 9:18 PM John Naylor wrote:
>
> On Wed, Jan 23, 2019 at 7:09 AM Amit Kapila wrote:
> > I think the first two patches (a) removal of dead code in bootstrap
> > and (b) the core patch to avoid creation of FSM file for the small
> > table are good now. I have prepared the pat
Andrew Dunstan writes:
> On 1/23/19 6:01 PM, Tom Lane wrote:
>> Perhaps there's some sort of setup that MinGW's version needs that
>> we're not doing?
> This seems to suggest something worse: https://reviews.llvm.org/D40181
> Not sure I fully understand what's happening here, though.
Me either,
On 2019-Jan-24, Amit Langote wrote:
> Fixed in the attached. We don't support inheriting EXCLUSION constraints
> yet, so no need to consider their indexes.
Looks good, pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Traini
On Tue, Jan 22, 2019 at 9:59 PM Haribabu Kommi wrote:
>
>
> Thanks for the latest patch. I have some more minor comments.
Thank you for reviewing the patch.
>
> + Execute index vacuum and cleanup index in parallel with
>
> Better to use vacuum index and cleanup index? This is in same with
>
On Wed, 23 Jan 2019 at 12:46, David Rowley wrote:
> (Stopped in statext_mcv_build(). Need to take a break)
Continuing...
27. statext_mcv_build() could declare the int j,k variables in the
scope that they're required in.
28. "an array"
* build array of SortItems for distinct groups and counts
On 2019/01/24 6:10, Alvaro Herrera wrote:
> Hello
>
> On 2019-Jan-23, Amit Langote wrote:
>
>> It seems that ATExecDetachPartition misses to mark a child's primary key
>> constraint entry (if any) as local (conislocal=true, coninhcount=0), which
>> causes this:
>>
>> create table p (a int primary
On Thu, 24 Jan 2019 at 13:38, John Naylor wrote:
>
> On Tue, Jan 22, 2019 at 4:31 PM David Rowley
> wrote:
> > Thanks. I've attached a rebased version.
>
> Hmm, now instead of an 85x speedup over master in the 10k partition
> case, I only get 20x. Anyone else see this?
What's it like with fsync
On Tue, Jan 22, 2019 at 4:31 PM David Rowley
wrote:
> Thanks. I've attached a rebased version.
Hmm, now instead of an 85x speedup over master in the 10k partition
case, I only get 20x. Anyone else see this?
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 1/23/19 6:01 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I have just spent a large amount of time testing the committed fix with
>> a number of versions of gcc. It blows up on any compiler modern enough
>> to know about _configthreadlocale
> Bleah. Since the regular Windows buildfarm mem
On Thu, 24 Jan 2019 at 04:45, Fabien COELHO wrote:
> I still do not understand the need for another variable.
>
>int ninserts = 0; // default is to use copy
>while (getopt...)
>{
> switch (...) {
>case "--inserts":
> if (ninserts == 0) ninserts = 1;
> br
On Wed, Jan 23, 2019 at 05:35:02PM +0900, Kyotaro HORIGUCHI wrote:
> At Mon, 21 Jan 2019 17:22:55 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20190121.172255.226467552.horiguchi.kyot...@lab.ntt.co.jp>
> > An option is an additional PGPROC member and interface functions.
> >
> >
On Tue, Jan 22, 2019 at 05:08:52PM +0900, Michael Paquier wrote:
> While working on REINDEX CONCURRENTLY, I have noticed that
> index_build() does not need its argument isprimary. Perhaps it is
> not worth bothering, but for the REINDEX CONCURRENTLY business this
> removes the need to open an inde
Andrew Dunstan writes:
> I have just spent a large amount of time testing the committed fix with
> a number of versions of gcc. It blows up on any compiler modern enough
> to know about _configthreadlocale
Bleah. Since the regular Windows buildfarm members seem happy, this
evidently means that M
On 1/22/19 12:50 PM, Andrew Dunstan wrote:
> On 1/21/19 10:00 PM, Andrew Dunstan wrote:
>> On 1/21/19 3:25 PM, Tom Lane wrote:
>>> "Joshua D. Drake" writes:
On 1/21/19 12:05 PM, Tom Lane wrote:
> Is there a newer version of mingw that does have this functionality?
Apparently this c
On Mon, Jan 21, 2019 at 6:32 AM Amit Kapila wrote:
> Also, another case to think in this regard is the upgrade for standby
> servers, if you read below paragraph from the user manual [1], you
> will see what I am worried about?
>
> "What this does is to record the links created by pg_upgrade's lin
On 2019-Jan-22, Amit Langote wrote:
> On 2019/01/22 8:30, Alvaro Herrera wrote:
> > Hi Amit,
> >
> > Will you please rebase 0002? Please add your proposed tests cases to
> > it, too.
>
> Done. See the attached patches for HEAD and PG 11.
I'm not quite sure I understand why the one in DefineIn
Hello
On 2019-Jan-23, Amit Langote wrote:
> It seems that ATExecDetachPartition misses to mark a child's primary key
> constraint entry (if any) as local (conislocal=true, coninhcount=0), which
> causes this:
>
> create table p (a int primary key) partition by list (a);
> create table p2 partiti
On Jan 23, 2019, at 6:46 AM, Tom Lane wrote:
>
> Oleksandr Shulgin writes:
>> On Wed, Jan 23, 2019 at 9:44 AM Donald Dong wrote:
>>> 1. Enumerate all the plans
>
>> So enumerating all possible plans stops being practical for even slightly
>> complicated queries.
>
> Yes. You can *not* disabl
On Mon, Jan 14, 2019 at 2:37 PM Peter Geoghegan wrote:
> The fix here must be to normalize index tuples that are compressed
> within amcheck, both during initial fingerprinting, and during
> subsequent probes of the Bloom filter in bt_tuple_present_callback().
I happened to talk to Andres about t
On 1/23/19 12:25 PM, Andres Freund wrote:
> On 2019-01-23 12:22:23 -0500, Chapman Flack wrote:
>> ArchiveEntry(fout, dbCatId, dbDumpId, .tag = datname, .owner = dba,
>> .desc = "DATABASE", .section = SECTION_PRE_DATA,
>> .defn = creaQry->data, .dropStmt = delQry->data);
Hi,
On 2019-01-23 13:17:26 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2019 at 9:01 PM Vik Fearing
> wrote:
> > I don't want a situation like this:
> > CREATE INDEX CONCURRENTLY ...
> > DROP INDEX CONCURRENTLY ...
> > REINDEX INDEX (CONCURRENTLY) ...
> >
> > All three should be the s
Andres Freund writes:
> Btw, do you have an opionion on keeping catId / dumpId outside/inside
> the argument struct?
I'd go for outside, since they're not optional. Not dead set on that
though.
regards, tom lane
st 23. 1. 2019 19:17 odesílatel Robert Haas napsal:
> On Fri, Jan 18, 2019 at 9:01 PM Vik Fearing
> wrote:
> > I don't want a situation like this:
> > CREATE INDEX CONCURRENTLY ...
> > DROP INDEX CONCURRENTLY ...
> > REINDEX INDEX (CONCURRENTLY) ...
> >
> > All three should be the sa
On Fri, Jan 18, 2019 at 9:01 PM Vik Fearing wrote:
> I don't want a situation like this:
> CREATE INDEX CONCURRENTLY ...
> DROP INDEX CONCURRENTLY ...
> REINDEX INDEX (CONCURRENTLY) ...
>
> All three should be the same, and my suggestion is to add the
> parenthesized version to CREATE
On 2019-01-23 12:32:06 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-23 13:58:07 -0300, Alvaro Herrera wrote:
> >> It does. How does pgindent behave with it?
>
> > It craps out:
> > Error@3649: Unbalanced parens
> > Warning@3657: Extra )
>
> > But that can be worked around with
Andres Freund writes:
> On 2019-01-23 13:58:07 -0300, Alvaro Herrera wrote:
>> It does. How does pgindent behave with it?
> It craps out:
> Error@3649: Unbalanced parens
> Warning@3657: Extra )
> But that can be worked around with something like
> te = ArchiveEntry(fout, tdinfo->dobj.c
On 2019-01-23 12:22:23 -0500, Chapman Flack wrote:
> On 1/23/19 12:10 PM, Andres Freund wrote:
> > On 2019-01-23 12:05:10 -0500, Chapman Flack wrote:
> >> [1] https://github.com/NetBSD/src/blob/trunk/sys/sys/midiio.h#L709
>
> > I'm not really seeing this being more than obfuscation in this case. T
On 2019-01-23 13:58:07 -0300, Alvaro Herrera wrote:
> Hello
>
> On 2019-Jan-23, Andres Freund wrote:
>
> > > All the arguments, except Archive, CatalogId and DumpId I've moved
> > > into the ArchiveOpts structure. Not all of them could be empty before, but
> > > anyway it seems better for consist
On 1/23/19 12:10 PM, Andres Freund wrote:
> On 2019-01-23 12:05:10 -0500, Chapman Flack wrote:
>> [1] https://github.com/NetBSD/src/blob/trunk/sys/sys/midiio.h#L709
> I'm not really seeing this being more than obfuscation in this case. The
> only point of the macro is to set the .tag and .op eleme
Attached is a patch that refactors DELETE triggers to fire at the statement
level.
I chose delete triggers partly out of simplicity, and partly because there
some before/after row linkage in the ON UPDATE CASCADE cases where
statement level triggers might not be feasible as we have currently
imple
Hi,
On 2019-01-23 12:05:10 -0500, Chapman Flack wrote:
> On 1/23/19 10:12 AM, Dmitry Dolgov wrote:
> > To make this discussion a bit more specific, I've created a patch of how
> > it can look like.
> A little bit of vararg-macro action can make such a design look
> even tidier, cf. [1].
> [1] htt
Hi,
On 2019-01-23 13:58:07 -0300, Alvaro Herrera wrote:
> I'd use ArchiveEntryOpts as struct name; ArchiveOpts sounds wrong.
Brevity would be of some advantage IMO, because it'll probably determine
how pgindent indents the arguments, because the struct name will be in
the arguments.
> Also, the
Chapman Flack writes:
> Or are compilers without vararg macros still in the supported mix?
No.
regards, tom lane
On 1/23/19 10:12 AM, Dmitry Dolgov wrote:
> To make this discussion a bit more specific, I've created a patch of how
> it can look like.
A little bit of vararg-macro action can make such a design look
even tidier, cf. [1].
Or are compilers without vararg macros still in the supported mix?
-Chap
Hello
On 2019-Jan-23, Andres Freund wrote:
> > All the arguments, except Archive, CatalogId and DumpId I've moved
> > into the ArchiveOpts structure. Not all of them could be empty before, but
> > anyway it seems better for consistency and readability. Some of the
> > arguments
> > had empty str
Andres Freund writes:
> On 2019-01-23 12:01:10 +0900, Michael Paquier wrote:
>> I am not sure if anybody uses them for anything automatically, still I
>> find myself from time to time looking at them to remember on which
>> path the file is located when opened in emacs.
> I often want to know tha
Hi,
On 2019-01-23 18:45:42 +0200, Heikki Linnakangas wrote:
> To re-iterate what I said earlier in this thread, I think the next step here
> is to write a patch that modifies xlog.c to use plain old mmap()/msync() to
> memory-map the WAL files, to replace the WAL buffers. Let's see what the
> perf
Hi,
On 2019-01-23 16:12:15 +0100, Dmitry Dolgov wrote:
> To make this discussion a bit more specific, I've created a patch of how it
> can
> look like.
Thanks.
> All the arguments, except Archive, CatalogId and DumpId I've moved
> into the ArchiveOpts structure. Not all of them could be empty b
On 10/12/2018 23:37, Dmitry Dolgov wrote:
On Thu, Nov 29, 2018 at 6:48 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
On Tue, Oct 2, 2018 at 4:53 AM Michael Paquier wrote:
On Mon, Aug 06, 2018 at 06:00:54PM +0900, Yoshimi Ichiyanagi wrote:
The libpmem's pmem_map_file() supported 2M/1G(the s
Hi,
On 2019-01-23 12:01:10 +0900, Michael Paquier wrote:
> On Tue, Jan 22, 2019 at 05:49:46PM -0800, Andres Freund wrote:
> > On 2019-01-23 14:43:15 +1300, Thomas Munro wrote:
> >> The function name comments are similar, though less consistent so I'm
> >> too lazy to write a script to find one tha
On 2019-01-23 14:20:52 +0200, Heikki Linnakangas wrote:
> On 23/01/2019 01:03, maayan mordehai wrote:
> > hello,
> >
> > I'm Maayan, I'm in a DBA team that uses postgresql.
> > I saw in the documentation on wals:
> > https://www.postgresql.org/docs/10/wal-intro.html
> > In the tip box that, it's b
On Wed, Jan 23, 2019 at 7:09 AM Amit Kapila wrote:
> I think the first two patches (a) removal of dead code in bootstrap
> and (b) the core patch to avoid creation of FSM file for the small
> table are good now. I have prepared the patches along with commit
> message. There is no change except f
Hello David,
I thought about this and looked into it, but I decided it didn't look
like a smart thing to do. The reason is that if --inserts sets
dump_inserts to 1 then --rows-per-insert sets it to something else
that's likely fine, but if that happens in the opposite order then the
--rows-pe
> On 2019-01-17 09:29:04 -0800, Andres Freund wrote:
> On 2019-01-17 10:23:39 -0500, Tom Lane wrote:
> > I don't buy the argument that this would move the goalposts in terms
> > of how much work it is to add a new argument. You'd still end up
> > touching every call site.
>
> Why? A lot of argumen
Oleksandr Shulgin writes:
> On Wed, Jan 23, 2019 at 9:44 AM Donald Dong wrote:
>> 1. Enumerate all the plans
> So enumerating all possible plans stops being practical for even slightly
> complicated queries.
Yes. You can *not* disable the planner's aggressive pruning of losing
paths and subpat
Thank you!!
On Wed, Jan 23, 2019, 2:20 PM Heikki Linnakangas On 23/01/2019 01:03, maayan mordehai wrote:
> > hello,
> >
> > I'm Maayan, I'm in a DBA team that uses postgresql.
> > I saw in the documentation on wals:
> > https://www.postgresql.org/docs/10/wal-intro.html
> > In the tip box that, it
On Wed, 23 Jan 2019 at 22:08, Fabien COELHO wrote:
> Out of abc-order rows-per-inserts option in getopt struct.
I missed that. Thanks. Fixed in attached.
> help string does not specify the expected argument.
Also fixed.
> I still think that the added rows_per_insert field is useless, ISTM That
On 23/01/2019 01:03, maayan mordehai wrote:
hello,
I'm Maayan, I'm in a DBA team that uses postgresql.
I saw in the documentation on wals:
https://www.postgresql.org/docs/10/wal-intro.html
In the tip box that, it's better not to use a journaling filesystem. and I
wanted to ask how it works?
can
On Sun, Jan 20, 2019 at 5:19 AM John Naylor wrote:
>
> I have a test for in-range and out-of-range for each relation fork.
>
I think the first two patches (a) removal of dead code in bootstrap
and (b) the core patch to avoid creation of FSM file for the small
table are good now. I have prepared
On Wed, Jan 23, 2019 at 5:28 PM Heikki Linnakangas wrote:
>
> On 23/01/2019 13:51, Amit Kapila wrote:
> > On Wed, Jan 23, 2019 at 2:18 PM Fabien COELHO wrote:
> >>
> >>
> >> An assorted set of command typos is fixed in the attached patch.
> >
> > The patch looks good to me. I will take another p
On 23/01/2019 13:51, Amit Kapila wrote:
On Wed, Jan 23, 2019 at 2:18 PM Fabien COELHO wrote:
An assorted set of command typos is fixed in the attached patch.
The patch looks good to me. I will take another pass over it and commit.
I just committed this. Sorry, I didn't see your mail unti
On Wed, Jan 23, 2019 at 2:18 PM Fabien COELHO wrote:
>
>
> An assorted set of command typos is fixed in the attached patch.
>
The patch looks good to me. I will take another pass over it and commit.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
(2019/01/04 20:33), Etsuro Fujita wrote:
> Here is a new version of the patch.
Attached is an updated version of the patch.
Changes:
* Fixed a stupid bug in the case when use_remote_estimate
* Fixed a typo in a comment I added
* Modified comments I added a little bit further
* Added the commit me
Hi,
I happened to notice that when CopyReadLineText() calls mblen(), it
passes only the first byte of the multi-byte characters. However,
pg_gb18030_mblen() looks at the first and the second byte.
CopyReadLineText() always passes \0 as the second byte, so
pg_gb18030_mblen() will incorrectly r
attached is a new signal handing patch. Path is corrected and moved. The
documentation is sightly streamlined in some places and expanded in others.
Feedback requested.
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße
Hi,
It seems that ATExecDetachPartition misses to mark a child's primary key
constraint entry (if any) as local (conislocal=true, coninhcount=0), which
causes this:
create table p (a int primary key) partition by list (a);
create table p2 partition of p for values in (2);
alter table p detach par
Hello David & Surafel,
About this v10:
Patch applies and compiles cleanly, local & global "make check" ok.
A few comments, possibly redundant with some already in the thread.
Out of abc-order rows-per-inserts option in getopt struct.
help string does not specify the expected argument.
I st
On Wed, Jan 23, 2019 at 9:44 AM Donald Dong wrote:
>
> 1. Enumerate all the plans
>
Not sure this is going to work. Because of the total number of possible
plans is somewhere
around O(n!), if I'm not mistaken, in terms of number of joined relations
times the available
access methods times the p
An assorted set of command typos is fixed in the attached patch.
--
Fabien.diff --git a/contrib/pgcrypto/pgp-decrypt.c b/contrib/pgcrypto/pgp-decrypt.c
index 7d31e5354b..96c344c30b 100644
--- a/contrib/pgcrypto/pgp-decrypt.c
+++ b/contrib/pgcrypto/pgp-decrypt.c
@@ -132,7 +132,7 @@ pgp_parse_pkt_
Hi,
I'm working on an extension which analyzes all possible plans
generated by the planner. I believe this extension would become
useful for benchmarking the planner (e.g. the performance of the
estimation and the cost model) and better understanding the cases
where the planners would make a subop
At Mon, 21 Jan 2019 17:22:55 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190121.172255.226467552.horiguchi.kyot...@lab.ntt.co.jp>
> An option is an additional PGPROC member and interface functions.
>
> struct PGPROC
> {
> ...
> int syscahe_usage_track_interval; /* track interva
On Wed, 23 Jan 2019 at 02:13, Surafel Temesgen wrote:
> okay .thank you for explaining. i attach a patch corrected as such
I did a bit of work to this to fix a bunch of things:
1. Docs for --rows-per-insert didn't mention anything about a parameter.
2. You'd not followed the alphabetical order o
70 matches
Mail list logo
