On Mon, Jul 27, 2020 at 2:45 PM Thomas Munro wrote:
> Here's a new version, using the name min_dynamic_shared_memory, which
> sounds better to me. Any objections? I also fixed the GUC's maximum
> setting so that it's sure to fit in size_t.
I pushed it like that. Happy to rename the GUC if
On Thu, Jul 30, 2020 at 05:57:40PM +0900, Michael Paquier wrote:
> Indeed. Let's fix this.
And done.
--
Michael
signature.asc
Description: PGP signature
>
> I see no good reason to believe that the signal handler issue is the only
> one. Even if it is,
> not being able to call any postgres infrastructure is a pretty huge
> handicap.
>
(changed emails to get rid of the nasty employer notice...)
It's at least a workable handicap that I'm happy to
> This patch fails to apply to HEAD, please submit a rebased version. I've
> marked this as as Waiting on Author.
Sorry for my absence. Unfortunately I couldn't have time to work on this patch
in this cf.
I believe I will be back in next cf, work on this patch and also review other
patches.
On Friday, July 31, 2020 2:37 AM, Konstantin Knizhnik wrote:
> 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
On Sat, 11 Jul 2020 at 21:56, Drouvot, Bertrand wrote:
>
>
> On 7/7/20 9:43 AM, Masahiko Sawada wrote:
> > Fully makes sense, the new patch version attached is now producing:
> >> 2020-07-06 06:10:36.022 UTC [14035] LOG: waiting for recovery conflict
> >> on snapshot
> > How about adding the
sorry I meant file src/tools/msvc/Solution.pm
routine sub GetOpenSSLVersion
has the follwing line:
qq("$self->{options}->{openssl}\\bin\\openssl.exe" version 2>&1);
in our distribution openssl.exe isn’t in the $self->{options}->{openssl}\bin\
location
dm
> On Jul 30, 2020, at 10:25 PM,
On Mon, 13 Jul 2020 at 10:18, Floris Van Nee wrote:
> One question about the unique keys - probably for Andy or David: I've looked
> in the archives to find arguments for/against using Expr nodes or
> EquivalenceClasses in the Unique Keys patch. However, I couldn't really find
> a clear answer
On Thu, Jul 30, 2020 at 11:23:38PM +0200, Daniel Gustafsson wrote:
> Looks good, thanks. Let's close the CF entry with this and open a new for the
> pg_depend part when that's done.
I have applied the patch, thanks.
And actually, I have found just after that CREATE DATABASE gets
severely
On Sat, Jun 20, 2020 at 10:32 AM Thomas Munro wrote:
> Rebased. I'll add this to the open commitfest.
I traced the recovery process while running pgbench -M prepared -c16
-j16 -t1 (= 160,000 transactions). With the patch, the number of
lseeks went from 1,080,661 (6.75 per pgbench
Hi Michael, thanks a lot
I figured it out, UNC works indeed
however I found at least 2 problems (at least in our 3p harness)
1. in our configuration openssl executable went to lib (I don’t know why), so I
had to change line in Configure script
and point to openssl.exe file. Sure I probably can
On Fri, 3 Jul 2020 at 07:47, James Coleman wrote:
> Patch using int64 attached.
I added this to the open items list for PG13.
David
On Thu, Jul 30, 2020 at 06:55:28AM -0400, Dmitry Markman wrote:
> icu => ,
>
> is it correct?
Exactly.
> if it’s correct does build support UNC paths?
Yes, these work. One take to be aware of is that the quoting of the
paths can be annoying. FWIW, I just use single quotes with normal
On Thu, Jul 30, 2020 at 6:40 PM Justin Pryzby wrote:
> Feel free to close it out. I'm satisfied that we've had a discussion about
> it.
Closed it out.
--
Peter Geoghegan
On Thu, Jul 30, 2020 at 6:39 PM James Coleman wrote:
> I very much do not like this approach, and I think it's actually
> fundamentally wrong, at least for the memory check. Quicksort is not the only
> option that uses memory. For now, there's only one option that spills to disk
> (external
At 2014-01-28 21:11:54, "Bruce Momjian" wrote:
>On Mon, Jul 1, 2013 at 08:10:14PM -0400, Josh Kupershmidt wrote:
>> On Thu, Jun 27, 2013 at 11:47 AM, Fujii Masao wrote:
>> > On Thu, Jun 27, 2013 at 10:36 AM, Josh Kupershmidt
>> > wrote:
>> >> On Wed, Jun 26, 2013 at 12:22 PM, Fujii
On Thu, Jul 30, 2020 at 06:33:32PM -0700, Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 5:22 PM Justin Pryzby wrote:
> > Because filtering out zero values is exactly what's intended to be avoided
> > for
> > nontext output.
> >
> > I think checking whether the method was used should result in
On Thu, Jul 30, 2020 at 8:22 PM Justin Pryzby wrote:
> On Wed, Jul 29, 2020 at 09:18:44PM -0700, Peter Geoghegan wrote:
> > On Wed, Jul 29, 2020 at 9:05 PM Justin Pryzby
> wrote:
> > > So my 2ndary suggestion is to conditionalize based on the method
> rather than
> > > value of space used.
> >
> On Jul 30, 2020, at 5:53 PM, Robert Haas wrote:
>
> On Thu, Jul 30, 2020 at 6:10 PM Mark Dilger
> wrote:
>> No, that wasn't my concern. I was thinking about CLOG entries disappearing
>> during the scan as a consequence of concurrent vacuums, and the effect that
>> would have on the
On Thu, Jul 30, 2020 at 5:22 PM Justin Pryzby wrote:
> Because filtering out zero values is exactly what's intended to be avoided for
> nontext output.
>
> I think checking whether the method was used should result in the same output,
> without the literal check for zero value (which itself sets
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Here's a proposed patch along that line.
> I've back-patched this to 11 (which was just a bit of fuzz) and tested
> it out with a couple of different queries that were causing issues
> previously on the archive server, and they
On Thu, Jul 30, 2020 at 6:10 PM Mark Dilger
wrote:
> No, that wasn't my concern. I was thinking about CLOG entries disappearing
> during the scan as a consequence of concurrent vacuums, and the effect that
> would have on the validity of the cached [relfrozenxid..next_valid_xid]
> range. In
Daniel Gustafsson writes:
> This patch has been bumped in CFs for the past year, with the thread stalled
> and the last review comment being in support of rejection. Tom, do you still
> feel it should be rejected in light of Pavel's latest posts?
I have seen no convincing response to the
On Wed, Jul 29, 2020 at 09:18:44PM -0700, Peter Geoghegan wrote:
> On Wed, Jul 29, 2020 at 9:05 PM Justin Pryzby wrote:
> > So my 2ndary suggestion is to conditionalize based on the method rather than
> > value of space used.
>
> What's the advantage of doing it that way?
Because filtering out
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Stephen Frost writes:
> >>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> We could hard-code a rule like that, or we could introduce a new
> explicit parameter for the
Commit 896ddf9b added prefetching to logtape.c to avoid excessive
fragmentation in the context of hash aggs that spill and have many
batches/tapes. Apparently the preallocation doesn't actually perform
any filesystem operations, so the new mechanism should be zero
overhead when "preallocated"
> On 10 Jul 2020, at 02:03, Cary Huang wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: tested, failed
> Spec compliant: tested, failed
> Documentation:tested, failed
>
> On 1 Jul 2020, at 15:38, Amit Langote wrote:
> Another thing I could do is decouple the patches to discuss here from
> the patches of the other thread, which should be possible and might be
> good to avoid back and forth between the two threads.
It sounds like it would make it easier for
> On 5 Jul 2020, at 13:52, Daniel Gustafsson wrote:
>
>> On 6 Apr 2020, at 23:15, Michael Banck wrote:
>
>> Probably we need to take a step back;
>
> This patch has been Waiting on Author since the last commitfest (and no longer
> applies as well), and by the sounds of the thread there are
> On 29 Jul 2020, at 19:58, Robert Haas wrote:
> Here are a bunch of comments based on a partial read-through of this
> patch.
Thanks a lot Robert and Justin for the reviews! With the commitfest wrap-up
imminent and being on vacation I will have a hard time responding properly
before the end
> On 26 Jan 2020, at 16:33, Pavel Stehule wrote:
> I reread all related mails and I think so it should be safe - or there is
> same risk like using any C extensions for functions or hooks.
This patch has been bumped in CFs for the past year, with the thread stalled
and the last review comment
> On Jul 30, 2020, at 1:47 PM, Andres Freund wrote:
>
> Hi,
>
> On 2020-07-30 13:18:01 -0700, Mark Dilger wrote:
>> Per tuple, tuple_is_visible() potentially checks whether the xmin or xmax
>> committed via TransactionIdDidCommit. I am worried about concurrent
>> truncation of clog
> On Jul 30, 2020, at 2:00 PM, Robert Haas wrote:
>
> On Thu, Jul 30, 2020 at 4:18 PM Mark Dilger
> wrote:
>>> Maybe I'm just being dense here -- exactly what problem are you worried
>>> about?
>>
>> Per tuple, tuple_is_visible() potentially checks whether the xmin or xmax
>> committed
In an off-list discussion with Paul, we decided to withdraw this patch for now
and instead create a new entry when there is a re-worked patch. This has now
been done in the CF app.
cheers ./daniel
> On 1 Jul 2020, at 14:15, Daniel Gustafsson wrote:
>
>> On 4 Mar 2020, at 12:06, Masahiko Sawada
>> wrote:
>
>> Attached updated patch that incorporated comments from Amit and Vignesh.
>
> This patch fails to compile due to an Oid collision in pg_proc.dat. Please
> submit a new version
> On 5 Jul 2020, at 13:38, Daniel Gustafsson wrote:
>
>> On 24 Mar 2020, at 15:47, David Steele wrote:
>
>> This patch no longer applies: http://cfbot.cputube.org/patch_27_2262.log
>>
>> CF entry has been updated to Waiting on Author.
>
> This patch hasn't been updated and still doesn't
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
I have tested this patch at various workloads and hardware
On Thu, Jul 30, 2020 at 5:50 PM Thomas Munro wrote:
> I pushed those three patches, but will wait for more discussion on the rest.
And here's a rebase, to make cfbot happy.
From a760053ac6fea1b9a829e9a170902a555863ce66 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Mon, 24 Feb 2020 23:51:09
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
We could hard-code a rule like that, or we could introduce a new
explicit parameter for the maximum cover length. The latter would be
more flexible,
> On 26 Jul 2020, at 09:06, Michael Paquier wrote:
>
> On Wed, Jul 22, 2020 at 11:31:38PM +0200, Daniel Gustafsson wrote:
>> Thanks for picking it up!
>
> For the archives, the patch set has been applied as ce4939f and
> 15e4419 on HEAD. Thanks, Noah.
Indeed, thanks!
>>> Do you happen to
> On 30 Jul 2020, at 03:28, Michael Paquier wrote:
> On Wed, Jul 29, 2020 at 11:34:07PM +0200, Daniel Gustafsson wrote:
>> Fair enough, let's break out pg_depend and I'll have another go at that.
>
> Thanks. Attached is a polished version of the patch that I intend to
> commit for pg_attribute
On Thu, Jul 30, 2020 at 4:18 PM Mark Dilger
wrote:
> > Maybe I'm just being dense here -- exactly what problem are you worried
> > about?
>
> Per tuple, tuple_is_visible() potentially checks whether the xmin or xmax
> committed via TransactionIdDidCommit. I am worried about concurrent
>
On Thu, Jul 30, 2020 at 8:09 AM wenjing zeng wrote:
> Please continue to review the code.
This patch is pretty light on comments. Many of the new functions have
no header comments, for example. There are comments here and there in
the body of the new functions that are added, and in places where
Hi,
On 2020-07-30 13:18:01 -0700, Mark Dilger wrote:
> Per tuple, tuple_is_visible() potentially checks whether the xmin or xmax
> committed via TransactionIdDidCommit. I am worried about concurrent
> truncation of clog entries causing I/O errors on SLRU lookup when performing
> that check.
> On Jul 29, 2020, at 12:52 PM, Robert Haas wrote:
>
> On Mon, Jul 20, 2020 at 5:02 PM Mark Dilger
> wrote:
>> I've made the options 'all-visible', 'all-frozen', and 'none'. It defaults
>> to 'none'.
>
> That looks nice.
>
>>> I guess that
>>> could still be expensive if there's a lot of
On Thu, Jul 30, 2020 at 2:55 PM Tom Lane wrote:
> > Why not? Our answer to threading inside functions has been, for quite a
> > while, that it's kinda ok if the threads never call into postgres and
> > can never escape the lifetime of a function. But that's not actually
> > really safe due to the
Andres Freund writes:
> On 2020-07-28 21:52:20 -0400, Tom Lane wrote:
>> TBH, though, I do not buy this argument for a millisecond. I don't
>> think that anything is going to come out of multithreading a bgworker
>> but blood and tears. Perhaps someday we'll make a major push to
>> make the
Hi,
On 2020-07-28 21:52:20 -0400, Tom Lane wrote:
> >> The rationale here is that as far as I can tell this is the *only* blocker
> >> to using multithreaded code in a BGWorker which can't be avoided by
> >> adhering to strict code rules (eg: no PG calls from non-main threads, no
> >>
Hi,
On 2020-07-29 13:41:02 +1200, Thomas Munro wrote:
> One practical problem with this change is that some systems have a
> stub definition of pthread_sigmask() that does nothing, when you don't
> link against the threading library. Realistically, most *useful*
> builds of PostgreSQL bring it
On Thu, 2020-07-30 at 19:16 +0200, Tomas Vondra wrote:
> > Essentially:
> > initHyperLogLog(, 5)
> > for i in 0 .. one billion
> >addHyperLogLog(, hash(i))
> > estimateHyperLogLog
> >
> > The numbers are the same regardless of bwidth.
> >
> > Before my patch, it takes about 15.6s. After
On Mon, Jul 27, 2020 at 1:02 PM Mark Dilger
wrote:
> Not at all! I appreciate all the reviews.
Reviewing 0002, reading through verify_heapam.c:
+typedef enum SkipPages
+{
+ SKIP_ALL_FROZEN_PAGES,
+ SKIP_ALL_VISIBLE_PAGES,
+ SKIP_PAGES_NONE
+} SkipPages;
This looks inconsistent. Maybe just
On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian wrote:
> I came up with a more verbose documentation suggestion, attached.
I'm okay with this.
Thanks
--
Peter Geoghegan
On Wed, Jul 29, 2020 at 08:43:24PM -0700, David G. Johnston wrote:
> On Wednesday, July 29, 2020, Peter Geoghegan wrote:
>
> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > > There should be a note about this in the Postgres 13 release notes,
> > > for the usual reasons.
On Thu, Jul 30, 2020 at 09:21:23AM -0700, Jeff Davis wrote:
On Wed, 2020-07-29 at 17:32 -0700, Peter Geoghegan wrote:
How did you test this? What kind of difference are we talking about?
Essentially:
initHyperLogLog(, 5)
for i in 0 .. one billion
addHyperLogLog(, hash(i))
On Wed, 2020-07-29 at 17:32 -0700, Peter Geoghegan wrote:
> How did you test this? What kind of difference are we talking about?
Essentially:
initHyperLogLog(, 5)
for i in 0 .. one billion
addHyperLogLog(, hash(i))
estimateHyperLogLog
The numbers are the same regardless of bwidth.
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> We could hard-code a rule like that, or we could introduce a new
> >> explicit parameter for the maximum cover length. The latter would be
> >> more flexible, but we need
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> We could hard-code a rule like that, or we could introduce a new
>> explicit parameter for the maximum cover length. The latter would be
>> more flexible, but we need something back-patchable and I'm concerned
>> about the
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> We could hard-code a rule like that, or we could introduce a new
> explicit parameter for the maximum cover length. The latter would be
> more flexible, but we need something back-patchable and I'm concerned
> about the compatibility hazards of
On 27.07.2020 20:25, Alvaro Herrera wrote:
On 2020-Jul-27, Anastasia Lubennikova wrote:
Here is the updated version of the fix.
The problem can be reproduced on all supported versions, so I suggest to
backpatch it.
Code slightly changed in v12, so here are two patches: one for versions 9.5
to
On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila wrote:
>
> On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
> >
> > I still don't agree with this as proposed.
> >
> > + * For now, we don't allow parallel inserts of any form not even where the
> > + * leader can perform the insert. This
On Mon, Jul 20, 2020 at 3:47 PM Robert Haas wrote:
> But I also agree that what pg_start_backup() was doing before v13 was
> wrong; that's why I committed
> 303640199d0436c5e7acdf50b837a027b5726594. The only reason I didn't
> back-patch it is because the consequences are so minor I didn't think
>
Hi
I’d like to add icu/openssl support to my postgresql build on windows
documentation says that I have to modify config.pl file, however it's not clear
what exactly I have to do
config-default.pl for example has the following line
icu => undef,# --with-icu=
so, if I want to add
Michael Paquier writes:
> On Wed, Jul 29, 2020 at 03:06:58PM +0900, Michael Paquier wrote:
>> This is actually a bug fix, because we include in the docs some
>> incorrect information, so it should be backpatched. If there are no
>> objections, I'll take care of that.
>
> And done.
Thanks!
-
On Thu, Jul 30, 2020 at 12:28 PM Ajin Cherian wrote:
>
> I was running some tests on this patch. I was generally trying to see how the
> patch affects logical replication when doing bulk inserts. This issue has
> been raised in the past, for eg: this [1].
> My test setup is:
> 1. Two postgres
On Thu, Jul 30, 2020 at 02:16:04PM +0900, Masahiko Sawada wrote:
> Yeah, that's the reason why I mentioned about toast tables. "VACUUM
> " displays "pg_toast." but, "VACUUM pg_to" doesn't
> complement anything.
So am I OK with this situation. The same is true as well for CLUSTER
and TRUNCATE,
On Thu, Jul 30, 2020 at 08:03:09AM +, k.jami...@fujitsu.com wrote:
> Just found a minor error in source code comment.
> src/include/executor/instrument.h
>
> Attached is the fix.
>
> - longlocal_blks_dirtied; /* # of shared blocks dirtied */
> + long
On Wed, Jul 22, 2020 at 3:16 PM Amit Langote wrote:
> On Mon, Jul 20, 2020 at 8:35 PM Amit Kapila wrote:
> > IIUC, here the problem is related to below part of code:
> > ExecInsert(..)
> > {
> > /* Process RETURNING if present */
> > if (resultRelInfo->ri_projectReturning)
> > result =
Hi,
Just found a minor error in source code comment.
src/include/executor/instrument.h
Attached is the fix.
- longlocal_blks_dirtied; /* # of shared blocks dirtied */
+ longlocal_blks_dirtied; /* # of local blocks dirtied */
Regards,
Kirk Jamison
On Wednesday, July 29, 2020 4:55 PM, Konstantin Knizhnik wrote:
> On 17.06.2020 09:14, k.jami...@fujitsu.com wrote:
> > Hi,
> >
> > Since the last posted version of the patch fails, attached is a rebased
> > version.
> > Written upthread were performance results and some benefits and challenges.
>> Main purpose is to decide (1) the user interface and (2) the
>> way to get the plan type from pg_stat_statements.
>>
>> (1) the user interface
>> I added a new boolean column 'generic_plan' to both
>> pg_stat_statements view and the member of the hash key of
>> pg_stat_statements.
>>
>> This is
On Wed, Jul 29, 2020 at 3:16 PM Dilip Kumar wrote:
>
>
> Thanks, please find the rebased patch set.
>
> --
> Regards,
> Dilip Kumar
> EnterpriseDB: http://www.enterprisedb.com
I was running some tests on this patch. I was generally trying to see how
the patch affects logical replication when
On Wed, Jul 29, 2020 at 03:06:58PM +0900, Michael Paquier wrote:
> This is actually a bug fix, because we include in the docs some
> incorrect information, so it should be backpatched. If there are no
> objections, I'll take care of that.
And done.
--
Michael
signature.asc
Description: PGP
On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
>
> I still don't agree with this as proposed.
>
> + * For now, we don't allow parallel inserts of any form not even where the
> + * leader can perform the insert. This restriction can be uplifted once
> + * we allow the planner to generate
Hi,
On Fri, Jul 10, 2020 at 5:32 PM torikoshia wrote:
> - whether information for identifying parent-child relation is necessary
> or it's an overkill
I think it's important to understand the parent-child relationship of
the context.
Personally, I often want to know the following two things ..
74 matches
Mail list logo
