Hi Dilip!
> 17 июля 2020 г., в 15:46, Dilip Kumar написал(а):
>
> The attached patch allows the vacuum to continue by emitting WARNING
> for the corrupted tuple instead of immediately error out as discussed
> at [1].
>
> Basically, it provides a new GUC called vacuum_tolerate_damage, to
> cont
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Jeff Davis writes:
> > On Fri, 2020-07-17 at 18:38 -0700, Peter Geoghegan wrote:
> >> There is also the separate question of what to do about the
> >> hashagg_avoid_disk_plan GUC (this is a separate open item that
> >> requires a separate resolu
On Saturday, July 18, 2020, vignesh C wrote:
> Hi,
>
> One of the comments needs correction "sorting all tuples in the the
> dataset" should have been "sorting all tuples in the dataset".
> The Attached patch has the changes for the same.
>
> Regards,
> Vignesh
> EnterpriseDB: http://www.enterpri
On 2020-07-16 13:45, Michael Paquier wrote:
On Thu, Jul 16, 2020 at 10:58:58AM +0200, Peter Eisentraut wrote:
if test "$with_openssl" = yes ; then
dnl Order matters!
+ AC_DEFINE(OPENSSL_API_COMPAT, [10001],
+[Define to the OpenSSL API version in use. This avoids
deprecatio
Stephen Frost writes:
> In other words, if we'd stop trying to shoehorn something in, which
> we're doing because we're in beta, we'd very likely be talking about all
> of this in a very different way and probably be contemplating something
> like a query_mem that provides for an overall memory li
On Wed, Jul 15, 2020 at 05:34:05AM +0300, Alexander Korotkov wrote:
On Mon, Jul 13, 2020 at 5:59 PM Tomas Vondra
wrote:
>> > If we really want to print something nicer, I'd say it needs to be a
>> > special function in the BRIN opclass.
>>
>> If that can be done, then +1. We just need to ensur
On Sun, Jul 19, 2020 at 4:38 AM Stephen Frost wrote:
> > (The only reason I'm in favor of heap_mem[_multiplier] is that it
> > seems like it might be possible to use it to get *better* plans
> > than before. I do not see it as a backwards-compatibility knob.)
>
> I still don't think a hash_mem-t
Part of the blame for the pg_subscription.subslotname fiasco can be laid
at the feet of initdb's default rule for marking columns NOT NULL; that
rule is fairly arbitrary and does not guarantee to make safe choices.
I propose that we change it so that it *is* safe, ie it will only mark
fields NOT NU
On Sat, May 16, 2020 at 02:28:02PM +0200, Dmitry Dolgov wrote:
> > On Mon, Mar 23, 2020 at 07:30:25AM +0100, Pavel Stehule wrote:
> > ne 22. 3. 2020 v 20:41 odesílatel Tom Lane napsal:
> > > Pavel Stehule writes:
> > > > ne 22. 3. 2020 v 18:47 odesílatel Tom Lane napsal:
> > > >> cfbot reports t
I wrote:
> (2) In pre-v13 branches, hack the JIT tuple deconstruction code
> to be specifically aware that it can't trust attnotnull for
> pg_subscription.subslotname. Yeah, it's ugly, but at least it's
> not ugly going forwards.
Concretely, as attached for v12.
regards,
On Sat, 2020-07-18 at 21:15 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > What is your opinion about pessimizing the HashAgg disk costs (not
> > affecting HashAgg plans expected to stay in memory)? Tomas Vondra
> > presented some evidence that Sort had some better IO patterns in
> > some
> > cas
On Sat, Jul 18, 2020 at 3:04 PM Jeff Davis wrote:
> > I think the entire discussion
> > is way out ahead of any field evidence that we need such a knob.
> > In the absence of evidence, our default position ought to be to
> > keep it simple, not to accumulate backwards-compatibility kluges.
>
> Fai
I wrote:
>> It's also a bit annoying that we have no mechanized checks that
>> would catch this inconsistency. If JIT is going to be absolutely
>> dependent on NOT NULL markings being accurate, we can't really
>> have such a laissez-faire attitude to C code getting it wrong.
> It seems like at le
I wrote:
> pg_subscription_rel.srsublsn also needs to be marked nullable.
Not only is it wrongly marked attnotnull, but two of the three places
that read it are doing so unsafely (ie, as though it *were*
non-nullable). So I think we'd better fix it as attached.
regards, t
On Sun, Jul 19, 2020 at 02:17:15PM -0700, Jeff Davis wrote:
On Sat, 2020-07-18 at 21:15 -0400, Tom Lane wrote:
Jeff Davis writes:
> What is your opinion about pessimizing the HashAgg disk costs (not
> affecting HashAgg plans expected to stay in memory)? Tomas Vondra
> presented some evidence th
>
> Thanks, but now the tests no longer work as the nodes in the test suite are
> renamed. While simple enough for a committer to fix, it's always good to see
> the tests pass in the CFBot to make sure the variable name error isn't hiding
> an actual test error.
>
Rebased patch attached, all test
On Sun, Jul 19, 2020 at 7:25 PM James Coleman wrote:
>
> On Saturday, July 18, 2020, vignesh C wrote:
>>
>> Hi,
>>
>> One of the comments needs correction "sorting all tuples in the the
>> dataset" should have been "sorting all tuples in the dataset".
>> The Attached patch has the changes for the
On 2020/07/17 16:25, Fujii Masao wrote:
On 2020/07/16 11:50, torikoshia wrote:
On 2020-07-15 11:44, Fujii Masao wrote:
On 2020/07/14 21:24, torikoshia wrote:
On 2020-07-10 10:49, torikoshia wrote:
On 2020-07-08 16:41, Fujii Masao wrote:
On 2020/07/08 10:14, torikoshia wrote:
On 2020-07
On Sat, Jul 18, 2020 at 6:31 PM Chapman Flack wrote:
>
> On 07/18/20 05:46, Amit Kapila wrote:
> > I don't think so. I think you can use 'pg_ctl start' to achieve that.
> > I think the JOBS stuff is primarily required when we use 'register'
> > operation (aka runs server via service). For example
On 2020/07/17 20:24, David Steele wrote:
On 7/17/20 5:11 AM, Fujii Masao wrote:
On 2020/07/14 20:30, David Steele wrote:
On 7/14/20 12:00 AM, Fujii Masao wrote:
The patch was no longer applied cleanly because of recent commit.
So I updated the patch. Attached.
Barring any objection, I
On Sun, Jun 7, 2020 at 2:36 AM Fabien COELHO wrote:
> In the meantime, here is a v9 which also fixes the behavior when using
> \watch, so that now one can issue several \;-separated queries and have
> their progress shown. I just needed that a few days ago and was
> disappointed but unsurprised th
On 2020-07-20 11:57, Fujii Masao wrote:
On 2020/07/17 16:25, Fujii Masao wrote:
On 2020/07/16 11:50, torikoshia wrote:
On 2020-07-15 11:44, Fujii Masao wrote:
On 2020/07/14 21:24, torikoshia wrote:
On 2020-07-10 10:49, torikoshia wrote:
On 2020-07-08 16:41, Fujii Masao wrote:
On 2020/07/0
On Fri, May 1, 2020 at 1:53 PM James Coleman wrote:
> In another thread [1] I'd mused that "there might be some value in a
> README or comments
> addition that would be a guide to what the various hash
> implementations are useful for...so that we have something to make the
> code base a bit more
>It may be OK actually; if you're doing multiple dangerous changes, you'd
>use --dry-run beforehand ... No? (It's what *I* would do, for sure.)
>Which in turns suggests that it would good to ensure that --dry-run
>*also* emits a warning (not an error, so that any other warnings can
>also be throw
In the meantime, here is a v9 which also fixes the behavior when using
\watch, so that now one can issue several \;-separated queries and have
their progress shown. I just needed that a few days ago and was
disappointed but unsurprised that it did not work.
This seems to break the 013_crash_r
25 matches
Mail list logo
