On Fri, 11 Jan 2019, 21:18 Tomas Vondra
> On 1/10/19 4:20 PM, Dean Rasheed wrote:
> > ...
> >
> > So perhaps what we should do for multivariate stats is simply use the
> > relative standard error approach (i.e., reuse the patch in [2] with a
> > 20% RSE cutoff). That had a lot of testing at the
pá 11. 1. 2019 v 20:11 odesílatel Robert Haas
napsal:
> On Fri, Jan 11, 2019 at 2:04 PM Andres Freund wrote:
> > > Maybe we could consider a more extensible syntax that is attached to
> > > the contained SELECT rather than the containing WITH. Then CTEs would
> > > be less special; there'd be
Hi all,
(Added Kevin in CC)
There have been over the ages discussions about getting better
O_DIRECT support to close the gap with other players in the database
market, but I have not actually seen on those lists a patch which
makes use of O_DIRECT for relations and SLRUs (perhaps I missed it,
On 1/11/19 10:25 PM, Magnus Hagander wrote:
On Fri, Jan 11, 2019 at 9:20 PM Tomas Vondra
On 1/11/19 7:40 PM, Robert Haas wrote:
> But I'm tentatively in favor of your proposal anyway, because it's
> pretty simple and cheap and might help people, and doing something
>
Hi,
On 2019-01-12 01:35:06 +0100, Dmitry Dolgov wrote:
> > On Sat, Dec 15, 2018 at 8:37 PM Andres Freund wrote:
> >
> > We need to dump the table access method at dump time, otherwise we loose
> > that information.
>
> As a result of the discussion in [1] (btw, thanks for starting it), here is
> On Jan 11, 2019, at 9:14 AM, Peter Eisentraut
> wrote:
>
>> The patch cannot be applied directly on HEAD. So I patched it on top of
>> 60d99797bf.
>
> Here is an updated patch with the merge conflicts of my own design
> resolved. No functionality changes.
>
>> When I call pg_log_error()
> On Sat, Dec 15, 2018 at 8:37 PM Andres Freund wrote:
>
> We need to dump the table access method at dump time, otherwise we loose
> that information.
As a result of the discussion in [1] (btw, thanks for starting it), here is
proposed solution with tracking current default_table_access_method.
On Fri, Jan 11, 2019 at 11:17:48AM +0100, Peter Eisentraut wrote:
> Attached revised 0002 with those changes.
This one looks fine.
> In that test, if I change the 'current' to 'latest', the test doesn't
> fail, so it's probably not a good test.
I can see your point. You would need a diverging
On Sat, Jan 12, 2019 at 08:34:37AM +0900, Michael Paquier wrote:
> Then the extension is showing up as beginning to be present for other
> users. I am mainly wondering if this case has actually been thought
> about in the past or discussed, and what to do about that and if we
> need to do
On Fri, Jan 11, 2019 at 02:22:01PM -0500, Robert Haas wrote:
> On Sun, Jan 6, 2019 at 10:26 PM Michael Paquier wrote:
>> This combination makes no actual sense, so wouldn't it be better to
>> restrict the case?
>
> Hmm. What exactly doesn't make sense about it?
In my mind, extensions are
Hi!
On Fri, Jan 11, 2019 at 1:05 PM Tom Lane wrote:
> Failure would leave a .tmp file behind, but I doubt we care enough
> about that to work harder than this.
Maybe just make sure that "make clean" removes it?
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
I wrote:
> So it appears that in v10,
> ./configure ... --enable-tap-tests ...
> make
> make install
> cd contrib/test_decoding
> make check
> fails due to failure to install test_decoding into the tmp_install
> tree, while it works in v11. Moreover, that's not
On Fri, Jan 11, 2019 at 12:52:08PM -0500, Robert Haas wrote:
> With the patch, the PrimaryConnInfo and PrimarySlotName arguments are
> removed from RequestXLogStreaming. That means that the new
> walreceiver could come to a different conclusion about the values of
> those arguments than the
> "Andres" == Andres Freund writes:
>> 4. Can we allow declaration-after-statement please? That would allow
>> keeping this code significantly closer to its upstream.
Andres> As I said on IRC: I'm personally on-board with changing this
Andres> styilistic requirement, but I also think
Hi,
I'm writing a tool to process a logical replication stream. The intent is
to use publications and subscriptions as an initial filter, and then use
the replication stream to trigger external events. So my tool should
connect to the master in the same manner as a replication slave, but it
Hi,
On 2019-01-12 01:55:23 +0300, Sergei Kornilov wrote:
> > pg_ctl reload is executed (or the equivalent),
> > different backends reload the file at different times.
> > There are no added TAP tests for the scenario where the values differ
> > between
> the two processes, no code comments which
Hello> pg_ctl reload is executed (or the equivalent),> different backends reload the file at different times.> There are no added TAP tests for the scenario where the values differ between the two processes, no code comments which explain why it's OKBut wait, connection string can not be changed
Hi Amit
On 2019-Jan-09, Amit Langote wrote:
> I noticed a couple of problems with foreign keys on partitioned tables.
Ouch, thanks for reporting. I think 0001 needs a bit of a tweak in pg11
to avoid an ABI break -- I intend to study this one and try to push
early next week. I'm going to see
I wrote:
> There's no obvious difference between bedda9fbb and 6dd690be3,
> so I surmise that that patch depended somehow on some previous
> work that only went into v11 not v10. Haven't found what, yet.
Ah, looks like it was 42e61c774. I'll push a fix shortly.
regards,
On 2019-Jan-04, Peter Eisentraut wrote:
> Your reasoning seems correct to me.
>
> Maybe add a code comment along the lines of "once we have found the
> right ... we don't need to check the remaining ...".
>
> Or, you can make this even more clear by comparing the backendId
> directly with the
I wrote:
> Thomas Munro writes:
>> Does this mean it didn't build the test_decoding module?
> I'm wondering if it built it but didn't install it, as a result of
> some problem with
>> bedda9fbb7 Mon Dec 31 21:57:57 2018 UTC Process EXTRA_INSTALL
>> serially, during the first temp-install.
So
On Tue, Jul 24, 2018 at 6:10 PM Andres Freund wrote:
> My read of the concensus (in which I am in the majority, so I might be
> biased) is that we do want inlining to be the default. We were thinking
> that it'd be necessary to provide a way to force inlining on the SQL
> level for individual
On 1/10/19 4:20 PM, Dean Rasheed wrote:
> ...
>
> So perhaps what we should do for multivariate stats is simply use the
> relative standard error approach (i.e., reuse the patch in [2] with a
> 20% RSE cutoff). That had a lot of testing at the time, against a wide
> range of data distributions,
I wrote:
> 1. No pandoc on borka, where we build tarballs:
> pgsql@borka:~$ which pandoc
> pgsql@borka:~$
That part's sorted, anyway.
pgsql@borka:~$ pandoc --version
pandoc 1.17.2
Compiled with texmath 0.8.6.7, highlighting-kate 0.6.3.
Syntax highlighting is supported for the following
On Fri, Jan 11, 2019 at 9:20 PM Tomas Vondra
wrote:
>
>
>
> On 1/11/19 7:40 PM, Robert Haas wrote:
> > On Fri, Jan 11, 2019 at 5:21 AM Magnus Hagander
> wrote:
> >> Would it make sense to add a column to pg_stat_database showing
> >> the total number of checksum errors that have occurred in a
On 1/11/19 7:40 PM, Robert Haas wrote:
> On Fri, Jan 11, 2019 at 5:21 AM Magnus Hagander wrote:
>> Would it make sense to add a column to pg_stat_database showing
>> the total number of checksum errors that have occurred in a database?
>>
>> It's really a ">1 means it's bad", but it's a lot
Hi,
On 2019-01-11 14:54:55 -0500, Tom Lane wrote:
> Andres Freund writes:
> > And of course it'd change the dump's text contents between ryu and
> > non-ryu backends even with extra_float_digits = 3, but the resulting
> > floats ought to be the same. It's just that ryu is better at figuring
> >
Andres Freund writes:
> And of course it'd change the dump's text contents between ryu and
> non-ryu backends even with extra_float_digits = 3, but the resulting
> floats ought to be the same. It's just that ryu is better at figuring
> out what the minimal text representation is than the current
Hi!
On Fri, Jan 11, 2019 at 8:51 AM Andreas Karlsson wrote:
> Her is quick initial review. I will do more testing later.
Thanks for doing the review!
> In create_ctas_internal() why do you copy the relation even when you do
> not modify it?
I was modelling this after code in view.c [1]. I can
On Fri, Jan 11, 2019 at 2:10 PM Robert Haas wrote:
>
> On Fri, Jan 11, 2019 at 2:04 PM Andres Freund wrote:
> > > Maybe we could consider a more extensible syntax that is attached to
> > > the contained SELECT rather than the containing WITH. Then CTEs would
> > > be less special; there'd be a
On Sun, Jan 6, 2019 at 10:26 PM Michael Paquier wrote:
> This combination makes no actual sense, so wouldn't it be better to
> restrict the case?
Hmm. What exactly doesn't make sense about it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, Jan 11, 2019 at 2:04 PM Andres Freund wrote:
> > Maybe we could consider a more extensible syntax that is attached to
> > the contained SELECT rather than the containing WITH. Then CTEs would
> > be less special; there'd be a place to put hints controlling top-level
> > queries,
Hi,
On 2019-01-12 07:58:39 +1300, Thomas Munro wrote:
> On Sat, Jan 12, 2019 at 7:19 AM Andres Freund wrote:
> > On 2019-01-11 11:12:25 -0500, Robert Haas wrote:
> > > I actually think that we should go "all in" here and allow the user to
> > > specify either that they want materialization or
On Sat, Jan 12, 2019 at 7:19 AM Andres Freund wrote:
> On 2019-01-11 11:12:25 -0500, Robert Haas wrote:
> > I actually think that we should go "all in" here and allow the user to
> > specify either that they want materialization or that they don't want
> > materialization. If they specify
On Fri, Jan 11, 2019 at 1:49 PM David Fetter wrote:
> I don't see those as the same thing even slightly. Functions are
> Turing complete, generally speaking, which means that unless we send
> along those descriptors, we're asking the planner to solve the Halting
> Problem.
So... your argument is
On Fri, Jan 11, 2019 at 11:12:25AM -0500, Robert Haas wrote:
> > I know this is a thorny topic, but I have to say that I am uneasy
> > about the MATERIALIZED syntax. Here's how you write that in some
> > other RDBMS that loves hints:
> >
> > WITH foo AS (SELECT /*+ MATERIALIZE */ ...)
> >
> > I
Hi,
On 2019-01-11 13:33:54 -0500, Robert Haas wrote:
> On Fri, Jan 11, 2019 at 1:30 PM Andres Freund wrote:
> > On 2019-01-11 12:55:54 -0500, Robert Haas wrote:
> > > About as much as I can say is that if you commit this patch, and as a
> > > result, a dump-and-restore from v11 to v12 causes a
On Fri, Jan 11, 2019 at 5:21 AM Magnus Hagander wrote:
> Would it make sense to add a column to pg_stat_database showing the total
> number of checksum errors that have occurred in a database?
>
> It's really a ">1 means it's bad", but it's a lot easier to monitor that in
> the statistics
On Fri, Jan 11, 2019 at 1:30 PM Andres Freund wrote:
> On 2019-01-11 12:55:54 -0500, Robert Haas wrote:
> > About as much as I can say is that if you commit this patch, and as a
> > result, a dump-and-restore from v11 to v12 causes a change in the bits
> > on disk that would not have occurred
Hi,
On 2019-01-11 12:55:54 -0500, Robert Haas wrote:
> About as much as I can say is that if you commit this patch, and as a
> result, a dump-and-restore from v11 to v12 causes a change in the bits
> on disk that would not have occurred without this patch, that's very
> bad. What ramifications
On Fri, Jan 11, 2019 at 1:14 AM Masahiko Sawada wrote:
> Attached the updated patch. Please review it.
I'm quite confused by this patch. It seems to me that the easiest way
to implement this patch would be to (1) make lazy_space_alloc take the
maxtuples = MaxHeapTuplesPerPage branch when the
On 2019-01-11 11:12:25 -0500, Robert Haas wrote:
> I actually think that we should go "all in" here and allow the user to
> specify either that they want materialization or that they don't want
> materialization. If they specify neither, then we make some decision
> which we may change in a
Hi,
On 2019-01-11 09:42:19 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The pluggable storage patchset has a large struct full of callbacks, and
> > a bunch of wrapper functions for calling those callbacks. While
> > starting to polish the patchset, I tried to make the formatting nice.
> >
On Fri, Jan 11, 2019 at 12:33 PM Andrew Gierth
wrote:
> > "Robert" == Robert Haas writes:
> Robert> I don't have an opinion on the code that is part of this patch
>
> At this point, frankly, I'm less interested in opinions on the code
> itself (which can be addressed later if need be) than
Hi,
On 2019-01-11 10:32:03 -0500, Robert Haas wrote:
> On Thu, Jan 10, 2019 at 11:45 PM Andres Freund wrote:
> > void(*relation_set_new_filenode) (Relation relation,
> > char persistence,
> >
On Thu, Jan 10, 2019 at 7:42 PM Andres Freund wrote:
> I still think this whole direction of accessing the GUC in walreceiver
> is a bad idea and shouldn't be pursued further. There's definite
> potential for startup process and WAL receiver having different states
> of GUCs, the code doesn't
> "Robert" == Robert Haas writes:
Robert> I don't have an opinion on the code that is part of this patch
At this point, frankly, I'm less interested in opinions on the code
itself (which can be addressed later if need be) than on answers to (or
discussion of) the questions asked upthread.
On Thu, Jan 10, 2019 at 11:10 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-10 23:02:01 -0500, Chapman Flack wrote:
> >> Does the project have an established view on non-ASCII names in
> >> sources or docs?
> >> AFAICS [1], the name of the algorithm may be Ryū.
>
> > I think it'd be
On Thu, Jan 10, 2019 at 7:05 PM Thomas Munro
wrote:
> +1
+1
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Jan 10, 2019 at 7:05 PM Andres Freund wrote:
> ISTM that the first block would best belong into new files like
> access/rel[ation].h and access/common/rel[ation].h.
+1.
> I think the second
> set should be renamed to be table_open() (with backward compat
> redirects, there's way way too
On 12/28/18 8:48 AM, Mitar wrote:> One more version of the patch with
more deterministic tests.
Her is quick initial review. I will do more testing later.
It applies builds and passes the tests.
The feature seems useful and also improves consistency, if we have
temporary tables and temporary
On Thu, Jan 10, 2019 at 9:10 PM Kohei KaiGai wrote:
> 2019年1月11日(金) 5:52 Robert Haas :
> > On Wed, Jan 9, 2019 at 12:44 AM Kohei KaiGai wrote:
> > > So, is it sufficient if set_rel_pathlist_hook is just relocated in
> > > front of the generate_gather_paths?
> > > If we have no use case for the
On Wed, Jan 9, 2019 at 8:38 PM Michael Paquier wrote:
> On Wed, Jan 09, 2019 at 05:09:19PM -0800, Andres Freund wrote:
> > IIRC we have other such errors including offset and length (and if
> > not we'll grow some). It should be formatted as a genetic write
> > error with the file name, no
> I know this is a thorny topic, but I have to say that I am uneasy
> about the MATERIALIZED syntax. Here's how you write that in some
> other RDBMS that loves hints:
>
> WITH foo AS (SELECT /*+ MATERIALIZE */ ...)
>
> I understood that it was a long standing project policy that we don't
> want
On Fri, Jan 11, 2019 at 9:42 AM Tom Lane wrote:
> Use shorter method names? This sounds like an ugly workaround for
> a carpal-tunnel-syndrome-inducing design.
What would you suggest instead of something like
"relation_set_new_filenode"? I agree that shorter names have some
merit, but it's not
On Thu, Jan 10, 2019 at 11:45 PM Andres Freund wrote:
> void(*relation_set_new_filenode) (Relation relation,
> char persistence,
> TransactionId *freezeXid,
>
Hi
pá 11. 1. 2019 v 9:31 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 06/11/2018 13:27, Peter Eisentraut wrote:
> > This is a small bug that I will fix in my next update.
>
> Time for another update. Lot's of rebasing, many things fixed,
> including the ADD
Peter Eisentraut writes:
> On 09/01/2019 10:05, Mi Tar wrote:
>> I tested this. Patch applied cleanly and INSTALL file was produced.
>> Formatting looks differently from before, but I think that it looks better.
>> We lost central alignment of some headings, but many code/command snippets
>>
Thomas Munro writes:
> Only gaur shows useful logs:
> SELECT 'init' FROM
> pg_create_logical_replication_slot('regression_slot',
> 'test_decoding');
> ! ERROR: could not access file "test_decoding": No such file or directory
> Does this mean it didn't build the test_decoding module?
I'm
Andres Freund writes:
> The pluggable storage patchset has a large struct full of callbacks, and
> a bunch of wrapper functions for calling those callbacks. While
> starting to polish the patchset, I tried to make the formatting nice.
> ...
> So, putting the parameter list, both in use and
Amit Kapila writes:
> On Fri, Jan 11, 2019 at 5:00 AM Tom Lane wrote:
>> It's also possible that you just aren't exercising the cases where
>> trouble occurs. In particular, noting this bit in InsertOneValue():
>> OidOutputFunctionCall(typoutput, values[i];
> I have tried initdb with
On 09/01/2019 10:05, Mi Tar wrote:
> I tested this. Patch applied cleanly and INSTALL file was produced.
> Formatting looks differently from before, but I think that it looks better.
> We lost central alignment of some headings, but many code/command snippets
> are now better/correctly
(2019/01/11 13:46), Amit Langote wrote:
On 2019/01/10 15:07, Etsuro Fujita wrote:
(2019/01/10 10:41), Amit Langote wrote:
That's a loaded meaning and abusing it to mean something else can be
challenged, but we can live with that if properly documented. Speaking of
which:
/* used by
On Fri, Jan 11, 2019 at 5:00 AM Tom Lane wrote:
> It's also possible that you just aren't exercising the cases where
> trouble occurs. In particular, noting this bit in InsertOneValue():
>
> /*
> * We use ereport not elog here so that parameters aren't evaluated unless
> * the
On Fri, 11 Jan 2019 at 14:47, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Fri, Jan 11, 2019 at 6:02 AM Amit Khandekar
> > wrote:
> >
> > > Yes, sounds like a reasonable approach, I can proceed with it.
> >
> > Dmitry, I believe you have taken the pg_dump part only. If that's
> > right,
Would it make sense to add a column to pg_stat_database showing the total
number of checksum errors that have occurred in a database?
It's really a ">1 means it's bad", but it's a lot easier to monitor that in
the statistics views, and given how much a lot of people set their systems
out to log,
On 08/01/2019 04:37, Michael Paquier wrote:
> On Mon, Dec 31, 2018 at 01:21:00PM +0200, David Steele wrote:
>> This patch looks good to me.
>
> 0001 looks fine to me.
committed that one
> -to the latest timeline found in the archive, which is useful in
> -a standby server. Other
On 08/01/2019 23:26, Corey Huinker wrote:
> On Fri, Jan 4, 2019 at 7:49 AM Peter Eisentraut
> wrote:
>>
>> On 25/12/2018 00:56, Corey Huinker wrote:
>>> The regression diff (attached) seems to imply that the triggers simply
>>> are not firing, though.
>>
>> The reason for this was explained by
> On Fri, Jan 11, 2019 at 6:02 AM Amit Khandekar wrote:
>
> > Yes, sounds like a reasonable approach, I can proceed with it.
>
> Dmitry, I believe you have taken the pg_dump part only. If that's
> right, I can proceed with the psql part. Does that sound right ?
Well, actually I've meant that I'm
On 10/01/2019 04:58, Amit Kapila wrote:
>> One flag that covers all things that make psql output less useful for
>> regression test output, or one flag that just controls the table access
>> method display.
>>
> +1 for the later (one flag that just controls the table access method
> display) as
pá 11. 1. 2019 v 2:10 odesílatel Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> napsal:
> From: Robert Haas [mailto:robertmh...@gmail.com]
> > My theory is that the number of wait events is NOT useful information,
> > or at least not nearly as useful the results of a sampling approach.
> >
71 matches
Mail list logo
