On Sat, Jan 26, 2019 at 12:14:33PM +0900, Amit Langote wrote:
> The describe lines are there just to show that the stored expessions are
> not verbatim same as the input expressions, so it seemed an overkill to add
> them for all of the partitions.
I see, so per 7c079d7 this is the reason why show
so 26. 1. 2019 v 1:20 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > Four years ago I proposed implicit casting to common type of arguments
> with
> > anyelement type.
> >
> https://www.postgresql.org/message-id/CAFj8pRCZVo_xoW0cfxt%3DmmgjXKBgr3Gm1VMGL_zx9wDRHmm6Cw%40mail.gmail.com
> >
On 01/25/19 22:53, Pavel Stehule wrote:
> Documentation review will be harder - I am not a native speaker and I have
> not a necessary knowledges of XQuery (probably only you have this
> knowledge).
The doc patch is enough that I think it would be ideal to somehow attract
a native speaker who has
On 01/25/19 19:37, Chapman Flack wrote:
> There is still nothing in this patch set to address [1], though that
> also seems worth doing, perhaps in another patch, and probably not
> difficult, perhaps needing only a regex.
Heck, it could be even simpler than that. If some XML input has a DTD,
the
Hi
so 26. 1. 2019 v 4:25 odesílatel Chapman Flack
napsal:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not tested
>
> > Thanks for insisting - I ended up setting up the environment and running
> > the tests, and discovering that some test-related changes were missing.
> > Here's a 3rd version of the patch. Hope this is now in good shape, let me
> > know if you think anything else needs to be done.
>
> Lotta wo
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
As the reporter of the issues raised in this email thread, I've revie
On Fri, Jan 25, 2019 at 03:26:38PM +0100, Nick B wrote:
> On server we see this error firing: "terminating walsender process due to
> replication timeout"
> The problem occurs during a network or file system acting very slow. One
> example of such case looks like this (strace output for fsync calls
Hi,
On Sat, Jan 26, 2019 at 12:01 Michael Paquier wrote:
> On Sat, Jan 26, 2019 at 03:14:51AM +0900, Amit Langote wrote:
> > How about replacing \d+ list_parted with couple of \d on individual
> > partitions, like in the attached?
>
> That would make it. Why just part_1 and part_3 though? It
Hello, I'm not a C coder and can't helpbut I *love* cross-tab/pivot
tables. They're the best, and just fantastic for preparing data to feed
into various analysis tools. The tablefunc module is helpful, but a bit
awkward to use (as I remember it.)
>From a user's point of view, I high-performanc
On Fri, Jan 25, 2019 at 12:30:39PM -0300, Alvaro Herrera wrote:
> I am, except that the change of "table" to "object" in xact.c line 2262
> makes the new paragraph read a bit weird -- it's now saying "if we've
> added a temp object ... Other objects have the same problem". Doesn't
> make sense.
On Sat, Jan 26, 2019 at 03:14:51AM +0900, Amit Langote wrote:
> How about replacing \d+ list_parted with couple of \d on individual
> partitions, like in the attached?
That would make it. Why just part_1 and part_3 though? It looks more
complete to add part_null and part_2 as well.
--
Michael
On Fri, Jan 25, 2019 at 06:55:56PM -0500, Bruce Momjian wrote:
> On Sat, Jan 26, 2019 at 12:49:50AM +0100, David Fetter wrote:
> > On Fri, Jan 25, 2019 at 05:38:59PM -0500, Bruce Momjian wrote:
> > > With our scanner keywords list now more cache-aware, and with us
> > > planning to use Bison for ye
Shay Rojansky writes:
> Thanks for insisting - I ended up setting up the environment and running
> the tests, and discovering that some test-related changes were missing.
> Here's a 3rd version of the patch. Hope this is now in good shape, let me
> know if you think anything else needs to be done.
On Wed, Jan 23, 2019 at 8:01 AM Alexander Korotkov
wrote:
> Finally, I'm going to commit this if no objections.
BTW, I decided to postpone commit for few days. Nikita and me are
still working on better error messages.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
T
David Rowley writes:
> As far as I can see the patch is ready to go, but I'll defer to Mark,
> who's also listed on the reviewer list for this patch.
Mark, are you planning to do further review on this patch?
I'd like to move it along, since (IMO anyway) we need it in
before progress can be made
David Rowley writes:
> On Thu, 3 Jan 2019 at 08:01, Tomas Vondra
> wrote:
>> AFAICS the patch essentially does two things: (a) identifies Append
>> paths with a single member and (b) ensures the Vars are properly mapped
>> when the Append node is skipped when creating the plan.
>> I agree doing
Pavel Stehule writes:
> Four years ago I proposed implicit casting to common type of arguments with
> anyelement type.
> https://www.postgresql.org/message-id/CAFj8pRCZVo_xoW0cfxt%3DmmgjXKBgr3Gm1VMGL_zx9wDRHmm6Cw%40mail.gmail.com
> My proposal was rejected, because it introduce compatibility issue
On Thu, Jan 10, 2019 at 11:41:51PM -0800, Donald Dong wrote:
>
> > On Jan 10, 2019, at 8:01 PM, Tom Lane wrote:
> >
> > ... estimate_rel_size() in plancat.c is where to look to find out
> > about the planner's default estimates when it's lacking hard data.
>
> Thank you! Now I see how the plann
On Thu, Jan 10, 2019 at 01:33:43PM +0100, Daniel Gustafsson wrote:
> The file header in the advanced tutorial has what seems like incorrect (or at
> least odd) wording: "Tutorial on advanced more PostgreSQL features”. Attached
> patch changes to “more advanced” which I think is what was the intent
On Sat, Jan 26, 2019 at 12:49:50AM +0100, David Fetter wrote:
> On Fri, Jan 25, 2019 at 05:38:59PM -0500, Bruce Momjian wrote:
> > With our scanner keywords list now more cache-aware, and with us
> > planning to use Bison for years to come, has anyone ever looked at
> > reordering the bison state m
On Fri, Jan 25, 2019 at 05:38:59PM -0500, Bruce Momjian wrote:
> With our scanner keywords list now more cache-aware, and with us
> planning to use Bison for years to come, has anyone ever looked at
> reordering the bison state machine array to be more cache aware, e.g.,
> having common states next
On Fri, Jan 25, 2019 at 04:31:00PM -0600, Merlin Moncure wrote:
> On Fri, Jan 25, 2019 at 3:16 PM David Fetter wrote:
> >
> > On Fri, Jan 25, 2019 at 02:21:55PM -0600, Merlin Moncure wrote:
> > > Hackers,
> > >
> > > We have a strong need to make a variant to the crosstab interface so
> > > that d
On Thu, Jan 24, 2019 at 9:50 PM Amit Kapila wrote:
>
> On Fri, Jan 25, 2019 at 1:03 AM John Naylor
> wrote:
> >
> > On Wed, Jan 23, 2019 at 11:17 PM Amit Kapila
> > wrote:
> > > I think what doc means to say is
> > > that it copies any unlinked files present in primary's new cluster
> > > (whi
On Thu, Jan 24, 2019 at 5:19 AM Amit Kapila wrote:
>
> 1.
> + if ((maps[mapnum].relkind != RELKIND_RELATION &&
> + maps[mapnum].relkind != RELKIND_TOASTVALUE) ||
> + first_seg_size > HEAP_FSM_CREATION_THRESHOLD * BLCKSZ ||
> + GET_MAJOR_VERSION(new_cluster.major_version) <= 1100)
> + (void) transf
On Tue, Jan 8, 2019 at 05:08:41PM +1100, Haribabu Kommi wrote:
> Hi Hackers,
>
> The Server GUC parameters accepts values in both Octal and hexadecimal formats
> also.
>
> postgres=# set max_parallel_workers_per_gather='0x10';
> postgres=# show max_parallel_workers_per_gather;
> max_parallel_wo
Hello Tom,
Fixing the problem envolves deciding what is the right behavior, and
update the documentation and the implementation accordingly. Currently the
documentation suggests that :ERROR is about SQL error (subject to
interpretation), and the implementation is more or less consistent with
t
With our scanner keywords list now more cache-aware, and with us
planning to use Bison for years to come, has anyone ever looked at
reordering the bison state machine array to be more cache aware, e.g.,
having common states next to each other rather than scattered around the
array?
--
Bruce Mom
On Sun, Jan 6, 2019 at 11:01:52AM -0800, Mitar wrote:
> Hi!
>
> I have read around the Internet a lot about the idea of using /dev/shm
> for a tablespace to put tables in and issues with that. But I still
> have not managed to get a good grasp why would that be a bad idea for
> using it for tempo
On Fri, Jan 25, 2019 at 3:16 PM David Fetter wrote:
>
> On Fri, Jan 25, 2019 at 02:21:55PM -0600, Merlin Moncure wrote:
> > Hackers,
> >
> > We have a strong need to make a variant to the crosstab interface so
> > that data that is pivoted one way would be sent through a crosstab
> > like function
Andreas Karlsson writes:
> [ inlining-ctes-v8.patch ]
I went ahead and pushed the stuff about QTW_EXAMINE_RTES_BEFORE/_AFTER,
because that seems like an independent change with other possible uses.
Attached is an updated version of the rest of the patch, with mostly
cosmetic changes. I've not t
On 2019-Jan-25, Robert Haas wrote:
> I finally gotten a little more time to work on this. It took me a
> while to understand that a PartitionedRelPruneInfos assumes that the
> indexes of partitions in the PartitionDesc don't change between
> planning and execution, because subplan_map[] and subpl
On Fri, Jan 25, 2019 at 02:21:55PM -0600, Merlin Moncure wrote:
> Hackers,
>
> We have a strong need to make a variant to the crosstab interface so
> that data that is pivoted one way would be sent through a crosstab
> like function so that it would be pivoted another way. For example,
> if you h
On Thu, Dec 20, 2018 at 3:58 PM Alvaro Herrera wrote:
> Namely: how does this handle the case of partition pruning structure
> being passed from planner to executor, if an attach happens in the
> middle of it and puts a partition in between existing partitions? Array
> indexes of any partitions t
Hackers,
We have a strong need to make a variant to the crosstab interface so
that data that is pivoted one way would be sent through a crosstab
like function so that it would be pivoted another way. For example,
if you had
row 0: a1, a2, a3, k1, c1, c2, ...
row 1: a1, a2, a3, k2, c1, c2, ...
ro
Andres Freund writes:
> On 2019-01-25 16:35:18 -0300, Alvaro Herrera wrote:
>> Would anybody object too hard if I move hash_any() and friends to
>> src/backend/utils/hash/hashfn.c and the declarations to
>> src/include/utils/hashutils.h?
> I hate the current split quite a bit, albeit for somewhat
Hi,
On 2019-01-25 16:35:18 -0300, Alvaro Herrera wrote:
> I just noticed (once again) that we have hash_any() declared in
> src/access/hash.h (the header file for the hash index AM) rather than
> somewhere in utils/, for no good reason other than perhaps there was no
> better place when it was int
I just noticed (once again) that we have hash_any() declared in
src/access/hash.h (the header file for the hash index AM) rather than
somewhere in utils/, for no good reason other than perhaps there was no
better place when it was introduced. This means that some files that
seem to just need hash_
On Fri, Jan 25, 2019 at 08:14:19AM +, Tsunakawa, Takayuki wrote:
> Hi Horiguchi-san, Bruce,
>
> From: Bruce Momjian [mailto:br...@momjian.us]
> > I suggest you go with just syscache_prune_min_age, get that into
> > PG 12, and we can then reevaluate what we need. If you want to
> > hard-code a
On Sat, Jan 26, 2019 at 12:19 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > committed
>
> Some of the buildfarm members are having sort-ordering problems
> with this. Looks like you could work around it with different
> partition names (don't assume the relative sort order of
> letters and d
Jim Finnerty writes:
> Tom, there's an analogous issue of adjusting distinct values on a per-column
> basis based on the selectivity of other local predicates. Several
> commercial RDBMS's make such adjustments in an effort to get better
> selectivity estimates when there are multiple local predi
Fabien COELHO writes:
> Fixing the problem envolves deciding what is the right behavior, and
> update the documentation and the implementation accordingly. Currently the
> documentation suggests that :ERROR is about SQL error (subject to
> interpretation), and the implementation is more or less
Hello,
> On 24. Jan 2019, at 13:47, Kyotaro HORIGUCHI
> wrote:
Thank you for the review.I took a liberty to address it with v9.
>
> Documentation looks fine for me. By the way, a comment for the
> caller-site of CheckRequreParameterValues() in xlog.c looks
> somewhat stale.
>
>> /* Check to
Alvaro Herrera writes:
> So let's have it write with a $VACUUMDB_OPTS variable, which is by
> default defined as empty but with a comment suggesting that maybe the
> user wants to add the -j option. This way, if they have to edit it,
> they only have to edit the VACUUMDB_OPTS line instead of each
On 2019-Jan-25, Peter Eisentraut wrote:
> On 25/01/2019 11:28, Michael Paquier wrote:
> > based on that linking the value used by pg_upgrade and vacuumdb is a
> > bad concept in my opinion, and the patch should be rejected. More
> > documentation on pg_upgrade side to explain that a bit better co
Eyeballing 0001, it has a few problems.
1. It's under-parenthesizing the txn argument of the macros.
2. the "has"/"is" macro definitions don't return booleans -- see
fce4609d5e5b.
3. the remainder of this no longer makes sense:
/* Do we know this is a subxact? Xid of top-level txn if so */
Edmund Horner writes:
> I added some code to selfuncs.c to estimate the selectivity of CTID,
> including nullness, in my ongoing attempt to add TID range scans [1]. And
> as Tom pointed out [2], no system attribute can be null, so we might as
> well handle them all.
> That's what the attached pat
Bonsoir Daniel,
Sure. As there are several bugs (doubtful features) uncovered, a first
patch could fix "COPY ...TO STDOUT \g file", but probably replicate ERROR
current behavior however debatable it is (i.e. your patch without the
ERROR change, which is unrelated to the bug being fixed), and t
On 2019-Jan-25, Michael Paquier wrote:
> On Thu, Jan 24, 2019 at 08:56:05AM -0300, Alvaro Herrera wrote:
> > Uh, I didn't think it was necessary nor desirable to rename the flag,
> > only the user-visible message.
>
> Oh, OK. I have overstated your comment then. Are you fine with the
> attached
On 16/01/2019 21:50, Peter Eisentraut wrote:
> On 16/01/2019 14:20, Daniel Verite wrote:
>> I've found another issue with aggregates over distinct:
>> the deduplication seems to ignore the collation.
>
> I have a fix for that. I'll send it with the next update.
Another patch. This fixes your is
Peter Eisentraut writes:
> committed
Some of the buildfarm members are having sort-ordering problems
with this. Looks like you could work around it with different
partition names (don't assume the relative sort order of
letters and digits).
regards, tom lane
On 01/25/19 09:01, Peter Eisentraut wrote:
> On 19/01/2019 21:24, Chapman Flack wrote:
>> (thinks to self half-seriously about an XSL transform for generating
>> printed output that could preserve link-texted links, add raised numbers,
>> and produce a numbered URLs section at the back)
>
> Extern
On 15/01/2019 02:52, John Naylor wrote:
The majority of cases are measurably faster, and the best case is at
least 20x faster. On the whole I'd say this patch is a performance win
even without further optimization. I'm marking it ready for committer.
I read through the patch one more time, twea
On 14/01/2019 23:16, Arseny Sher wrote:
>
> Nikhil Sontakke writes:
>
>> I'd like to believe that the latest patch set tries to address some
>> (if not all) of your concerns. Can you please take a look and let me
>> know?
>
> Hi, sure.
>
> General things:
>
> - Earlier I said that there is no
Hi, hackers.
When running pg_basebackup with -X s with network file system as target we
would consistently get "could not receive data from WAL stream: server
closed the connection unexpectedly".
On server we see this error firing: "terminating walsender process due to
replication timeout"
The pr
Hi,
I think the difference between abort and abort prepared should be
explained better (I am not quite sure I get it myself).
> + The required abort_cb callback is called whenever
Also, why is this one required when all the 2pc stuff is optional?
> +static void
> +DecodePrepare(LogicalDeco
On 19/01/2019 21:24, Chapman Flack wrote:
> (thinks to self half-seriously about an XSL transform for generating
> printed output that could preserve link-texted links, add raised numbers,
> and produce a numbered URLs section at the back)
External links already create footnotes in the PDF output.
Hi Kirk,
On 1/24/19 9:31 PM, Jamison, Kirk wrote:
According to CF app, this patch needs review so I took a look at it.
Currently, your patch applies and builds cleanly, and all tests are also
successful
based from the CF bot patch tester.
I'm not sure if I have understood the argument raised b
Fabien COELHO wrote:
> Sure. As there are several bugs (doubtful features) uncovered, a first
> patch could fix "COPY ...TO STDOUT \g file", but probably replicate ERROR
> current behavior however debatable it is (i.e. your patch without the
> ERROR change, which is unrelated to the bug
On 24/01/2019 23:27, Robert Haas wrote:
On Wed, Jan 23, 2019 at 6:23 AM Heikki Linnakangas wrote:
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.
Copy
Bruce Momjian wrote:
> but I am able to see the failure using STDIN:
>
> COPY test FROM STDIN CSV;
> Enter data to be copied followed by a newline.
> End with a backslash and a period on a line by itself, or an EOF
> signal.
> "foo
> \.
> ER
On 25/01/2019 11:28, Michael Paquier wrote:
> based on that linking the value used by pg_upgrade and vacuumdb is a
> bad concept in my opinion, and the patch should be rejected. More
> documentation on pg_upgrade side to explain that a bit better could be
> a good idea though, as it is perfectly p
On 25/01/2019 09:52, Takashi Menjo wrote:
> 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.
> Sorry but
Hi,
I noticed yet another thing while updating the patch for pushing down
ORDER BY LIMIT. Let me explain. When costing foreign paths on the
basis of local statistics, we calculate/cache the costs of an unsorted
foreign path, and re-use them to estimate the costs of presorted foreign
paths, as sh
On 26/12/2018 07:07, Tatsuro Yamada wrote:
> +#define Query_for_list_of_attribute_numbers \
> +"SELECT attnum "\
> +" FROM pg_catalog.pg_attribute a, "\
> +" pg_catalog.pg_class c "\
> +" WHERE c.oid = a.attrelid "\
> +" AND a.attnum > 0 "\
> +" AND NOT a.attisdropped "\
> +" /* %d %s
On 24/01/2019 21:57, Jeremy Finzel wrote:
> The source system has a timestamp stored "at time zone UTC", like this
> for 6:00pm Chicago time:
> 2019-01-24 20:00:00.00
>
> I was *very surprised* to find that replicating above timestamp to
> timestamptz actually does so correctly, showing this v
On 24/01/2019 13:57, Amit Langote wrote:
> The if (contain_var_clause(value)) block is new code, but I agree its
> ereport should have parser_errposition just like other ereports in that
> function. Fixed that in the attached.
committed
--
Peter Eisentraut http://www.2ndQuadrant.co
On Fri, Jan 25, 2019 at 02:31:57AM +, Jamison, Kirk wrote:
> I'm not sure if I have understood the argument raised by Peter
> correctly. Quoting Peter, "it's not clear that pg_upgrade and
> vacuumdb are bound the same way, so it's not a given that the same
> -j number should be used." I think
On Thu, Jan 24, 2019 at 08:56:05AM -0300, Alvaro Herrera wrote:
> Uh, I didn't think it was necessary nor desirable to rename the flag,
> only the user-visible message.
Oh, OK. I have overstated your comment then. Are you fine with the
attached instead? The flag name remains the same, and the c
Hello,
On behalf of Yoshimi, I rebased the patchset onto the latest master
(e3565fd6).
Please see the attachment. It also includes an additional bug fix (in patch
0002)
about temporary filename.
Note that PMDK 1.4.2+ supports MAP_SYNC and MAP_SHARED_VALIDATE flags,
so please use a new version
čt 24. 1. 2019 v 23:08 odesílatel Tom Lane napsal:
> Peter Eisentraut writes:
> > committed
>
> Why didn't this patch modify the dumping logic in pl_funcs.c to print
> the IDs? I'm not aware of other cases where we intentionally omit
> fields from debug-support printouts.
>
Currently we don't
Hi Horiguchi-san, Bruce,
From: Bruce Momjian [mailto:br...@momjian.us]
> I suggest you go with just syscache_prune_min_age, get that into PG 12,
> and we can then reevaluate what we need. If you want to hard-code a
> minimum cache size where no pruning will happen, maybe based on the system
> cat
72 matches
Mail list logo
