Hello Andres,
how do you want to generalize it? Are you thinking about a view solely for the
display of the memory usage of different objects? Like functions or views (that
also have a plan associated with it, when I think about it)? While being
interesting I still believe monitoring the mem
On Mon, Jul 22, 2019 at 01:05:32PM -0400, Alvaro Herrera wrote:
> Fair enough. List has gotten quite sophisticated now, so I understand
> the concern.
Just wondering something... List cells include one pointer, one
signed integer and an OID. The two last entries are basically 4-byte
each,
On Tue, Jul 23, 2019 at 01:01:27PM -0700, Andres Freund wrote:
Hi,
On 2019-06-18 17:08:37 -0700, Andres Freund wrote:
On 2019-06-18 18:48:58 -0500, Justin Pryzby wrote:
> Ah: the table is an inheritence parent. If I uninherit its child, there's no
> error during ANALYZE. MV stats on the
Michael Paquier writes:
> Just wondering something... List cells include one pointer, one
> signed integer and an OID. The two last entries are basically 4-byte
> each, hence could we reduce a bit the bloat by unifying both of them?
We couldn't really simplify the API that way; for example,
Fabien COELHO writes:
> Otherwise, why not simply move llvm C++ includes *before* postgres
> includes?
We've been burnt in the past by putting other headers before postgres.h.
(A typical issue is that the interpretation of varies depending
on _LARGE_FILES or a similar macro, so you get
Hello Thomas,
I would just #undef Min for our small number of .cpp files that
include LLVM headers. It's not as though you need it in C++, which
has std::min() from .
Like so. Fixes the problem for me (llvm-devel-9.0.d20190712).
Hmmm. Not so nice, but if it works, why not, at least the
On Sat, Jul 27, 2019 at 01:06:06PM -0400, Sehrope Sarkuni wrote:
> While reviewing this patch I read through some of the other fsync
> callsites and noticed this typo (walkdir is in file_utils.c, not
> initdb.c) too:
Thanks, Sehrope. Applied.
--
Michael
signature.asc
Description: PGP signature
On Fri, Jul 26, 2019 at 05:52:43PM -0400, Alvaro Herrera wrote:
> Yeah, I had removed those on purpose, but that was probably inconsistent
> with my own reviews of others' patches. I pushed it with them.
Thanks!
--
Michael
signature.asc
Description: PGP signature
On Saturday, July 27, 2019 7:06 AM(GMT+9), Tomas Vondra wrote:
> On Fri, Jul 26, 2019 at 07:03:41AM +, Jamison, Kirk wrote:
> >On Sat, July 20, 2019 8:12 AM (GMT+9), Tomas Vondra wrote:
> >
> >> >+ /* XXX What if the target is set to 0? Reset the statistic?
> >> */
> >> >
> >> >This
On Fri, Jul 26, 2019 at 08:24:16PM -0400, Tom Lane wrote:
> I think this is a sufficiently obvious bug, and a sufficiently
> obvious fix, that we should just fix it and not insist on getting
> a reproducible test case first. I think a test case would soon
> bit-rot anyway, and no longer exercise
On Mon, Jul 29, 2019 at 7:27 AM Michael Paquier wrote:
>
> On Fri, Jul 26, 2019 at 03:12:28PM +0530, Ashutosh Sharma wrote:
> > Hi All,
> >
> > I'm able to insert data into a table column marked as GENERATED ALWAYS
> > using COPY command however, it fails with INSERT command. Isn't that a
> > bug
Hi,
On 2019-07-29 10:48:41 +0900, Michael Paquier wrote:
> On Thu, Jul 18, 2019 at 09:16:22PM -0700, Andres Freund wrote:
> >> - One set of functions for the backend, called pg_stro[u]intXX_backend
> >> or pg_backend_stro[u]intXX which can take as extra argument error_ok,
> >> calling the
Let's just commit the #undef so that seawasp is green and back to
being ready to tell us if something else breaks.
+1. I was afraid that working around this would be impossibly
painful ... but if it just takes one judiciously placed #undef,
let's do that and not argue about it.
Done.
Hi,
On 2019-07-29 10:27:54 +1200, Thomas Munro wrote:
> On Mon, Jul 29, 2019 at 9:55 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > Let's just commit the #undef so that seawasp is green and back to
> > > being ready to tell us if something else breaks.
> >
> > +1. I was afraid that working
On Mon, 29 Jul 2019 at 00:09, Petr Jelinek wrote:
> Given that we don't process any other records in this function besides
> XLOG_HEAP2_MULTI_INSERT and XLOG_HEAP2_NEW_CID, it seems like simplest
> fix is to just remove the first check for fast forward and keep the one
> in
On Fri, Jul 26, 2019 at 03:12:28PM +0530, Ashutosh Sharma wrote:
> Hi All,
>
> I'm able to insert data into a table column marked as GENERATED ALWAYS
> using COPY command however, it fails with INSERT command. Isn't that a
> bug with COPY command?
Per the documentation in the section for
On Thu, Jul 25, 2019 at 01:03:06PM -0400, Bruce Momjian wrote:
> On Tue, Jul 16, 2019 at 01:24:54PM +0900, Masahiko Sawada wrote:
> > On Sat, Jul 13, 2019 at 12:33 AM Bruce Momjian wrote:
> > > then each row change gets its own LSN. You are asking if an update that
> > > just expires one row and
Hello, Fabien.
At Fri, 26 Jul 2019 08:19:47 + (GMT), Fabien COELHO
wrote in
>
> Hello Kyotaro-san,
>
> >> Attached a v2 for the always-show-all-results variant. Thanks for the
> >> debug!
> >
> > I have some comments on this patch.
> >
> > I'm +1 for always output all results without
Bonjour Michaël,
Fabien, are you planning to send an updated patch? This stuff has
value.
Yep, I will try for this week.
--
Fabien.
On 2019-07-28 21:42, Tom Lane wrote:
> Oh ... one other thought, based on forcing the collate.linux.utf8
> test to run on platforms where it can be expected to fail: I think
> you'd be well advised to make that test verify that the required
> collations are present, the same as you did in the
On Sun, Jul 28, 2019 at 07:44:44AM +0300, Alexander Lakhin wrote:
> 8.3. lag_with_offset_and_default, * ->
> window_lag_with_offset_and_default, window_* (in windowfuncs.c)
The intention here is to refer to the SQL-visible names.
> In passing, I found a legacy script, FAQ2txt, that should be
Hello.
On 2019/07/29 6:36, Fabien COELHO wrote:>
>> Thanks for the feedback. Attached v3 with further documentation updates.
>
> Attached v4 also fixes pg_stat_statements non regression tests, per pg
> patch tester travis run.
Thanks. I looked this more closely.
+ * Marshal the COPY data.
On Sat, Jul 27, 2019 at 2:27 PM Andres Freund wrote:
> Note that neither of those mean that it's not a good idea to
> posix_fallocate() and *then* write zeroes, when initializing. For
> several filesystems that's more likely to result in more optimally sized
> filesystem extents, reducing
On Thu, Jul 18, 2019 at 09:16:22PM -0700, Andres Freund wrote:
> On 2019-07-19 12:21:27 +0900, Michael Paquier wrote:
> Why not common? It's not a platform dependent bit. Could even be put
> into the already existing string.c.
That would be fine to me, it is not like this file is bloated now.
>>
On 2019-07-28 20:12, Tom Lane wrote:
> So I wish we could get rid of the Makefile changes, have the test
> scripts be completely responsible for whether to run themselves or
> not, and put them into the schedule files normally.
>
> It's pretty obvious how we might do this for collate.icu.utf8:
>
On Thu, Jul 25, 2019 at 10:21 PM Binguo Bao wrote:
>
> Hi John!
> Sorry for the late reply. It took me some time to fix a random bug.
Don't worry, it's not late at all! :-)
>> In the case where we don't know the slice size, how about the other
>> aspect of my question above: Might it be simpler
Hi,
On 2019-07-28 21:21:51 +0200, Tomas Vondra wrote:
> AFAICS it applies to 10+ versions, because that's where extended stats
> were introduced. We certainly can't mess with catalogs there, so this is
> about the only backpatchable fix I can think of.
AFAIU the inh version wouldn't be used
Andres Freund writes:
> On 2019-07-28 10:07:27 -0400, Tom Lane wrote:
>> In the long run, might we ever switch to 64-bit OIDs? I dunno.
> Depends on the the table, I'd say. Having toast tables have 64bit ids,
> and not advance the oid counter, would be quite the advantage over the
> current
Hi,
On 2019-07-28 12:15:20 +0200, Tomas Vondra wrote:
> Attached is a patch fixing the error by not building extended stats for
> the inh=true case (as already proposed in this thread). That's about the
> simplest way to resolve this issue for v12. It should add a simple
> regression test too, I
> On Thu, Jul 25, 2019 at 1:21 PM Kyotaro Horiguchi
> wrote:
>
> I have some comments.
Thank you for the review!
> + * The order of columns in the index should be the same, as for
> + * unique distincs pathkeys, otherwise we cannot use _bt_search
> + * in the skip
Thanks the follow ups on this one Edmund/Peter!
I've attached a new V4 variant of the patch based on
Peter's V3, mostly containing comment amendments and a few
other minor stylistic fixes.
> An interesting thing about sorting IPv4 inets on 64-bit machines is that
when the inets are the same, the
On Mon, Jul 29, 2019 at 8:03 AM Fabien COELHO wrote:
> If reordering includes is not an option, too bad. Then "#undef Min" which
> I find disputable, allthough I've done much worse... it might or might not
> work depending on what is done afterwards. Or rename the macro, as I
> suggested first,
Hi,
On 2019-07-28 10:07:27 -0400, Tom Lane wrote:
> In the long run, might we ever switch to 64-bit OIDs? I dunno.
> Now that we kicked them out of user tables, it might be feasible,
> but by the same token there's not much pressure to do it.
Depends on the the table, I'd say. Having toast
Matheus de Oliveira writes:
> [ postgresql-alter-constraint.v5.patch ]
Somebody seems to have marked this Ready For Committer without posting
any review, which is not very kosher, but I took a quick look at it
anyway.
* It's failing to apply, as noted by the cfbot, because somebody added
an
Thomas Munro writes:
> Let's just commit the #undef so that seawasp is green and back to
> being ready to tell us if something else breaks.
+1. I was afraid that working around this would be impossibly
painful ... but if it just takes one judiciously placed #undef,
let's do that and not argue
Andres Freund writes:
> On 2019-07-27 12:46:51 -0400, Tom Lane wrote:
>> 2. Change psql so that there's a way to get NOTIFY messages without
>> the sending PID. For testing purposes, it'd be sufficient to know
>> whether the sending PID is our own backend's PID or not. This idea
>> is not
Hello,
Here are the numbers at the end of the 4th week, with just a few days to go:
status | w1 | w2 | w3 | w4
+-+-+-+-
Committed | 32 | 41 | 49 | 59
Moved to next CF | 5 | 6 | 6 | 6
Needs review
I wrote:
> I'm less clear on a reasonable way to detect a glibc platform
> from SQL. The best I can think of is to see if the string
> "linux" appears in the output of version(), and that's probably
> none too robust. Can we do anything based on the content of
> pg_collation? Probably not :-(.
Hello Tom,
They should be fully independent anyway, so the order should
not matter?
On what grounds do you claim that's true anywhere, let alone
everywhere?
I mean that the intersection of Postgres realm, a database written in C,
and LLVM realm, a compiler written in C++, should not
Thanks for the feedback. Attached v3 with further documentation updates.
Attached v4 also fixes pg_stat_statements non regression tests, per pg
patch tester travis run.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out
On Sun, Jul 28, 2019 at 09:42:44AM -0700, Andres Freund wrote:
Hi,
On 2019-07-28 12:15:20 +0200, Tomas Vondra wrote:
Attached is a patch fixing the error by not building extended stats for
the inh=true case (as already proposed in this thread). That's about the
simplest way to resolve this
Oh ... one other thought, based on forcing the collate.linux.utf8
test to run on platforms where it can be expected to fail: I think
you'd be well advised to make that test verify that the required
collations are present, the same as you did in the collate.icu.utf8
test. I noticed for instance
Peter Eisentraut writes:
>> Cool, that works out quite well. See attached patch. I flipped the
>> logic around to make it \quit if not compatible. That way the
>> alternative expected file is shorter and doesn't need to be updated all
>> the time. But it gets the job done either way.
I took
On Mon, Jul 29, 2019 at 9:55 AM Tom Lane wrote:
> Thomas Munro writes:
> > Let's just commit the #undef so that seawasp is green and back to
> > being ready to tell us if something else breaks.
>
> +1. I was afraid that working around this would be impossibly
> painful ... but if it just takes
Hi,
On 27. 07. 19 3:15, Andres Freund wrote:
Hi,
Petr, Simon, see the potential issue related to fast forward at the
bottom.
[..snip..]
This actually made me look at the nearby changes due to
commit 9c7d06d60680c7f00d931233873dee81fdb311c6
Author: Simon Riggs
Date: 2018-01-17 11:38:34
45 matches
Mail list logo
