On Sat, May 22, 2021 at 10:15 AM Dilip Kumar wrote:
>
> On Sat, May 22, 2021 at 1:14 AM Robert Haas wrote:
> >
> > The attached test script, test.sh seems to reliably reproduce this.
> > Put that file and the recalcitrant_cp script, also attached, into an
>
> I haven't tested this, but I will do
On Sat, May 22, 2021 at 1:49 AM Mark Dilger
wrote:
>
> -hackers,
>
> I think commit 82ed7748b710e3ddce3f7ebc74af80fe4869492f created some
> confusion that should be cleaned up before release. I'd like some guidance
> on what the intended behavior is before I submit a patch for this, though:
>
>
On Thu, May 20, 2021 at 5:03 PM Amit Kapila wrote:
>
> On Fri, May 7, 2021 at 6:06 PM Dilip Kumar wrote:
> >
> > On Mon, May 3, 2021 at 6:08 PM Bharath Rupireddy
> > wrote:
> > >
> > > Having said that, isn't it good if we can provide a subscription
> > > (CREATE/ALTER) level option say "cascade
On Sat, May 22, 2021 at 1:14 AM Robert Haas wrote:
>
> On Fri, May 21, 2021 at 12:52 PM Robert Haas wrote:
> > I had trouble following it completely, but I didn't really spot
> > anything that seemed definitely wrong. However, I don't understand
> > what it has to do with where we are now. What I
Le sam. 22 mai 2021 à 02:27, Bruce Momjian a écrit :
> On Fri, May 21, 2021 at 02:19:13PM -0400, Andrew Dunstan wrote:
> >
> > On 5/16/21 11:13 PM, Bruce Momjian wrote:
> > > On Sun, May 16, 2021 at 08:39:33PM +0800, Julien Rouhaud wrote:
> > >> Le dim. 16 mai 2021 à 11:23, Alvaro Herrera
> a éc
On Fri, May 21, 2021 at 3:39 PM Bharath Rupireddy
wrote:
> > Having said that, I see a different use case of such an option which
> > is related to the proposal [1] where the patch provides a truncate
> > option to truncate tables before initial sync. The cascade option
> > could be useful in that
On Thu, Nov 26, 2020 at 12:16 AM David Christensen wrote:
>
> Hi,
>
> At this time I do not have time to make the necessary changes for this
> commitfest so I am voluntarily withdrawing this patch, but will
> revisit at a future time.
Hi,
This feature looks useful in the sense that it avoids use
On Fri, May 21, 2021 at 6:47 PM Guillaume Lelarge
wrote:
>
> Le ven. 21 mai 2021 à 05:43, Amit Kapila a écrit :
>>
>> On Fri, May 21, 2021 at 1:30 AM Guillaume Lelarge
>> wrote:
>> >
>> >
>> >> If so, the
>> >> problem might be that copying the data of the first table creates a
>> >> transaction
On Sat, May 22, 2021 at 6:01 AM Tom Lane wrote:
> Amit Langote writes:
> > IMHO, it would be better to keep the lowest-level
> > apply_handle_XXX_internal() out of this, because presumably we're only
> > cleaning up the mess in higher-level callers. Somewhat related, one
> > of the intentions be
On Sat, May 22, 2021 at 11:00 AM osumi.takami...@fujitsu.com
wrote:
> On Friday, May 21, 2021 9:45 PM I worte:
> > On Friday, May 21, 2021 4:43 PM Amit Langote
> > wrote:
> > > On Fri, May 21, 2021 at 3:55 PM osumi.takami...@fujitsu.com
> > > wrote:
> > > > But, I've detected segmentation faults
On Friday, May 21, 2021 9:45 PM I worte:
> On Friday, May 21, 2021 4:43 PM Amit Langote
> wrote:
> > On Fri, May 21, 2021 at 3:55 PM osumi.takami...@fujitsu.com
> > wrote:
> > > But, I've detected segmentation faults caused by the patch, which
> > > can happen during 100_bugs.pl in src/test/subsc
On Fri, May 21, 2021 at 9:21 PM Peter Smith wrote:
>
> On Thu, May 20, 2021 at 2:11 PM Bharath Rupireddy
> wrote:
> >
> > On Wed, May 19, 2021 at 6:13 PM Bharath Rupireddy
> > wrote:
> > > Thanks. I will work on the new structure ParseSubOption only for
> > > subscription options.
> >
> > PSA v2
Hi,
On 2021-05-21 15:57:01 -0700, Andres Freund wrote:
> I found the LLVM commit to blame (c8fc5e3ba942057d6c4cdcd1faeae69a28e7b671).
> Contacting the author and reading the change to see if I can spit the
> issue myself.
Hrmpf. It's a silent API breakage. The author intended to email us about
it
I wrote:
> BTW, I wonder whether it wouldn't be a good idea for the
> postmaster to log something along the lines of "stopping
> because restart_after_crash is off". The present behavior
> can be quite mysterious otherwise (it certainly confused me).
Concretely, I suggest the attached.
While che
Hi,
On 2021-05-21 18:18:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Interesting. I tried this with a slightly older LLVM checkout
> > (6f4f0afaa8ae), from 2021-04-20, contrib/ltree tests run without an
> > issue, even if I force everything to be jitted+inlined+optimized. The
> > git has
Hi,
On 2021-05-21 14:58:38 -0700, Andres Freund wrote:
> Interesting. I tried this with a slightly older LLVM checkout
> (6f4f0afaa8ae), from 2021-04-20, contrib/ltree tests run without an
> issue, even if I force everything to be jitted+inlined+optimized. The
> git hash in the package version ind
Andres Freund writes:
> Interesting. I tried this with a slightly older LLVM checkout
> (6f4f0afaa8ae), from 2021-04-20, contrib/ltree tests run without an
> issue, even if I force everything to be jitted+inlined+optimized. The
> git hash in the package version indicates the commit is from
> 2021-
I wrote:
> I count three distinct bugs that were exposed by this attempt:
> ...
> 2. Said bug causes a segfault in the apply worker process.
> This causes the parent postmaster to give up and die.
> I don't understand why we don't treat that like a crash
> in a regular backend, considering that an
Hi,
On 2021-05-21 21:37:22 +1200, Thomas Munro wrote:
> I installed Clang/LLVM version
> "1:13~++20210520071732+02f2d739e074-1~exp1~20210520052519.57" from
> https://apt.llvm.org/ on a Debian buster box, and I saw that
> contrib/ltree's test fail about half the time with a range of weird
> and won
Hi,
On 2021-05-20 09:16:50 -0400, Andrew Dunstan wrote:
> We certainly shouldn't want that. But we do need it for the target
> unless we wipe out everything in the source that refers to it.
Is there a reason not to go for the wipe? I don't think the type of
functions we have in regress.so are ne
On 5/21/21 9:46 AM, Andrew Dunstan wrote:
> On 5/21/21 9:25 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> That seems a bit tortured. Why should you have to make the decision at
>>> configure time? ISTM all you need is an extra make target that will
>>> install it for you, or a make variable
Hi,
On 2021-05-21 11:01:03 -0400, Tom Lane wrote:
> It was a good thing I went through this code, too, because I noticed
> one serious bug (attcompression not checked in equalTupleDescs) and
> another thing that looks like a bug:
Grepping for attcompression while trying to understand the issue To
Amit Langote writes:
> IMHO, it would be better to keep the lowest-level
> apply_handle_XXX_internal() out of this, because presumably we're only
> cleaning up the mess in higher-level callers. Somewhat related, one
> of the intentions behind a04daa97a43, which removed
> es_result_relation_info i
Hi,
On 2021-05-21 11:01:03 -0400, Tom Lane wrote:
> It was a good thing I went through this code, too, because I noticed
> one serious bug (attcompression not checked in equalTupleDescs) and
> another thing that looks like a bug: there are two places that set
> up attcompression depending on
>
>
-hackers,
I think commit 82ed7748b710e3ddce3f7ebc74af80fe4869492f created some confusion
that should be cleaned up before release. I'd like some guidance on what the
intended behavior is before I submit a patch for this, though:
+ALTER SUBSCRIPTION mysubscription SET PUBLICATION nosuchpub WITH
Christoph Berg writes:
> Interestingly, the test is only failing on i386 and none of the other
> architectures, which could hint at 80-bit extended precision FP
> problems.
Yeah, that's what I'd assumed it is. We suppress that where we can
with -fexcess-precision=standard or -msse2, but I'm gues
In the meantime postgresql-14 has been accepted into Debian/experimental:
https://buildd.debian.org/status/logs.php?pkg=postgresql-14&ver=14%7Ebeta1-1
Interestingly, the test is only failing on i386 and none of the other
architectures, which could hint at 80-bit extended precision FP
problems.
(
On Fri, May 21, 2021 at 12:52 PM Robert Haas wrote:
> I had trouble following it completely, but I didn't really spot
> anything that seemed definitely wrong. However, I don't understand
> what it has to do with where we are now. What I want to understand is:
> under exactly what circumstances doe
On Fri, May 21, 2021 at 02:19:13PM -0400, Andrew Dunstan wrote:
>
> On 5/16/21 11:13 PM, Bruce Momjian wrote:
> > On Sun, May 16, 2021 at 08:39:33PM +0800, Julien Rouhaud wrote:
> >> Le dim. 16 mai 2021 à 11:23, Alvaro Herrera a
> >> écrit :
> >>
> >> On 2021-May-15, Bruce Momjian wrote:
> >
Yura Sokolov writes:
> I propose to add PortalDrop at the 'if (completed)' branch of
> exec_execute_message.
This violates our wire protocol specification, which
specifically says
If successfully created, a named portal object lasts till the end of
the current transaction, unless explici
On 5/16/21 11:13 PM, Bruce Momjian wrote:
> On Sun, May 16, 2021 at 08:39:33PM +0800, Julien Rouhaud wrote:
>> Le dim. 16 mai 2021 à 11:23, Alvaro Herrera a
>> écrit :
>>
>> On 2021-May-15, Bruce Momjian wrote:
>>
>> > On Sat, May 15, 2021 at 05:32:58PM -0400, Bruce Momjian wrote:
>>
>>
On 5/21/21 6:43 PM, Andres Freund wrote:
Hi,
> ...
>
Attached are the flame graphs for all three cases. The change in master is
pretty clearly visible, but I don't see any clear difference between old and
patched code :-(
I'm pretty sure it's the additional WAL records?
Not sure. If I und
On Thu, May 20, 2021 at 10:21 PM Kyotaro Horiguchi
wrote:
> > > Conclusion:
> > > - I think now we agree on the point that initializing expectedTLEs
> > > with the recovery target timeline is the right fix.
> > > - We still have some differences of opinion about what was the
> > > original problem
Hi,
On 2021-05-21 18:17:01 +0200, Tomas Vondra wrote:
> OK, so here are the flamegraphs, for all three cases - current master,
> 0c7d3bb99 (i.e. before heap_insert changes) and with the pinning patch
> applied. I did this using the same test case as before (50M table), but with
> -fno-omit-frame-p
On Fri, May 21, 2021 at 10:39 AM Dilip Kumar wrote:
> > so we might have
> > the timeline history in RECOVERYHISTORY but that's not the filename
> > we're actually going to try to read from inside readTimeLineHistory().
> > In the second case, findNewestTimeLine() will call
> > existsTimeLineHisto
Hi,
Here is another take on the patch with a couple of changes:
* I've removed for now UniqueKeys parts. The interaction of skip scan &
unique keys patch was actually not that big, so the main difference is
that now the structure itself went away, a list of unique expressions
is used instea
On Fri, May 21, 2021 at 7:51 AM Kyotaro Horiguchi
wrote:
>
> https://www.postgresql.org/message-id/50E43C57.5050101%40vmware.com
>
> > That leaves one case not covered: If you take a backup with plain
> > "pg_basebackup" from a standby, without -X, and the first WAL segment
> > contains a timeline
Michael Paquier writes:
> This is still an open item. FWIW, I can get behind the reordering
> proposed by Tom for the consistency gained with pg_type, leading to
> the attached to reduce the size of FormData_pg_attribute from 116b to
> 112b.
I think we need to do more than that. It's certainly
On Thu, May 20, 2021 at 11:19 PM Robert Haas wrote:
>
> On Tue, May 18, 2021 at 1:33 AM Dilip Kumar wrote:
> > Yeah, it will be a fake 1-element list. But just to be clear that
> > 1-element can only be "ControlFile->checkPointCopy.ThisTimeLineID" and
> > nothing else, do you agree to this? Bec
Hi,
On Thu, 2021-05-20 at 15:47 -0400, Andrew Dunstan wrote:
> Meanwhile I would suggest that RPM maintainers exclude both requires
> and provides for these five names.
Done, thanks. Will appear in next beta build.
Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engi
On 5/21/21 9:25 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> That seems a bit tortured. Why should you have to make the decision at
>> configure time? ISTM all you need is an extra make target that will
>> install it for you, or a make variable that controls it in the existing
>> install targ
On 5/21/21 5:03 AM, Bharath Rupireddy wrote:
> On Fri, May 21, 2021 at 1:19 PM houzj.f...@fujitsu.com
> wrote:
>> Attaching V2 patch. Please consider it for further review.
> Thanks for the patch. Some more comments:
>
> 1) Can fmstate->p_nums ever be 0 in postgresGetForeignModifyBatchSize?
> By
Andrew Dunstan writes:
> That seems a bit tortured. Why should you have to make the decision at
> configure time? ISTM all you need is an extra make target that will
> install it for you, or a make variable that controls it in the existing
> install target.
Works fine for Unix, but what about Win
Le ven. 21 mai 2021 à 05:43, Amit Kapila a écrit :
> On Fri, May 21, 2021 at 1:30 AM Guillaume Lelarge
> wrote:
> >
> >
> >> If so, the
> >> problem might be that copying the data of the first table creates a
> >> transaction which blocks creation of the slot for second table copy.
> >
> >
> > I
On Friday, May 21, 2021 4:43 PM Amit Langote wrote:
> On Fri, May 21, 2021 at 3:55 PM osumi.takami...@fujitsu.com
> wrote:
> > But, I've detected segmentation faults caused by the patch, which can
> > happen during 100_bugs.pl in src/test/subscription.
> > This happens more than one in ten times.
On 5/20/21 7:58 PM, Michael Paquier wrote:
> On Thu, May 20, 2021 at 09:30:37AM -0400, Tom Lane wrote:
>> I'd be okay with it being some sort of non-default option.
> Okay. It would be possible to control that with an environment
> variable. However I am wondering if it would not be more user-f
On 5/20/21 11:04 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 5/20/21 9:49 PM, Michael Paquier wrote:
>>> Are older versions of the perl MSI that activestate provides hard to
>>> come by? FWIW, I would not mind if this README and the docs are
>>> updated to mention that on Windows we requ
On Fri, May 21, 2021 at 1:02 PM Amit Langote wrote:
> I will now take a look at the patch itself.
Some quick observations:
* I get a lot of instances of the following 2 warnings when compiling
the patched code:
Warning #1:
partprune.c: In function ‘get_matching_list_bounds’:
partprune.c:2731:1
On Thu, May 20, 2021 at 2:11 PM Bharath Rupireddy
wrote:
>
> On Wed, May 19, 2021 at 6:13 PM Bharath Rupireddy
> wrote:
> > Thanks. I will work on the new structure ParseSubOption only for
> > subscription options.
>
> PSA v2 patch that has changes for 1) new ParseSubOption structure 2)
> the err
On Fri, May 21, 2021 at 3:46 PM Amit Kapila wrote:
>
> On Fri, Mar 19, 2021 at 11:02 AM Bharath Rupireddy
> wrote:
> >
> > On Wed, Jan 27, 2021 at 1:47 PM Bharath Rupireddy
> > wrote:
> > >
> >
> > I analyzed performance of parallel inserts in CTAS for different cases
> > with tuple size 32bytes
On Fri, May 21, 2021 at 6:08 AM Michael Paquier wrote:
>
> On Thu, May 20, 2021 at 09:14:45PM +0530, Bharath Rupireddy wrote:
> > On Thu, May 20, 2021 at 7:52 PM Bernd Helmle wrote:
> >> "mv" looks like a very common alias (i use it all over the time when
> >> testing or playing around with mater
On Thu, May 20, 2021 at 12:46 PM tanghy.f...@fujitsu.com
wrote:
>
> On Thursday, May 20, 2021 3:05 PM, Amit Kapila
> wrote:
> > Okay, I have prepared the patches for all branches (11...HEAD). Each
> > version needs minor changes in the test, the code doesn't need much
> > change. Some notable ch
On Fri, Mar 19, 2021 at 11:02 AM Bharath Rupireddy
wrote:
>
> On Wed, Jan 27, 2021 at 1:47 PM Bharath Rupireddy
> wrote:
> >
>
> I analyzed performance of parallel inserts in CTAS for different cases
> with tuple size 32bytes, 59bytes, 241bytes and 1064bytes. We could
> gain if the tuple sizes ar
On Thu, May 20, 2021 at 5:03 PM Amit Kapila wrote:
>
> On Fri, May 7, 2021 at 6:06 PM Dilip Kumar wrote:
> >
> > On Mon, May 3, 2021 at 6:08 PM Bharath Rupireddy
> > wrote:
> > >
> > > Having said that, isn't it good if we can provide a subscription
> > > (CREATE/ALTER) level option say "cascade
On Fri, May 21, 2021 at 1:30 PM Bharath Rupireddy
wrote:
>
> On Fri, May 21, 2021 at 11:10 AM Amit Kapila wrote:
> >
> > If the patch changes the vacuumdb code as above then isn't it better
> > to change the vacuumdb docs to reflect the same. See below part of
> > vacuumdb docs:
> > -P parallel_d
On Wed, May 19, 2021 at 5:02 AM Fabien COELHO wrote:
> It seems that the upload of the valgrind run (many hours…) failed on "413
> request entity too large", and everything seems to have been cleaned
> despite the "--keepall" I think I put when I started the run.
I installed Clang/LLVM version
"1
On Fri, May 21, 2021 at 1:19 PM houzj.f...@fujitsu.com
wrote:
> Attaching V2 patch. Please consider it for further review.
Thanks for the patch. Some more comments:
1) Can fmstate->p_nums ever be 0 in postgresGetForeignModifyBatchSize?
By any chance, if it can, I think instead of an assert, we c
On Fri, May 21, 2021 at 11:26 AM Amit Kapila
wrote:
> On Thu, May 20, 2021 at 5:43 PM Ashutosh Bapat
> wrote:
> >
> > Hi
> > LogicalIncreaseRestartDecodingForSlot() has a debug log to report a
> > new restart_lsn. But the corresponding function for catalog_xmin.
> > Here's a patch to add the sam
On 2021/05/21 13:45, Masahiko Sawada wrote:
> On Fri, May 21, 2021 at 12:45 PM Masahiro Ikeda
> wrote:
>>
>>
>>
>> On 2021/05/21 10:39, Masahiko Sawada wrote:
>>> On Thu, May 20, 2021 at 1:26 PM Masahiro Ikeda
>>> wrote:
On 2021/05/11 13:37, Masahiko Sawada wrote:
> I've at
On Tue, May 18, 2021 at 9:32 PM Amit Kapila wrote:
>
> On Thu, May 13, 2021 at 3:20 PM Peter Smith wrote:
> >
> > Please find attached the latest patch set v75*
> >
>
> Review comments for v75-0001-Add-support-for-prepared-transactions-to-built-i:
> ===
On Fri, May 21, 2021 at 11:10 AM Amit Kapila wrote:
> I responded on that thread and it seems there is no object to the new
> message. I have a minor comment on your patch:
Thanks Amit!
> - printf(_(" -P, --parallel=PARALLEL_DEGREE use this many background
> workers for vacuum, if available\n"
From: Bharath Rupireddy
Sent: Friday, May 21, 2021 1:42 PM
> On Fri, May 21, 2021 at 8:18 AM houzj.f...@fujitsu.com
> wrote:
> > Actually, I think if the (number of columns) * (number of rows) >
> > 65535, then we can get this error. But, I think almost no one will set
> > such a large value, so
At Fri, 21 May 2021 11:21:05 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 20 May 2021 13:49:10 -0400, Robert Haas wrote
> in
> In the case of (c) recoveryTargetTLI > checkpoint TLI. In this case
> we expecte that checkpint TLI is in the history of
> recoveryTargetTLI. Otherwise re
On Fri, May 21, 2021 at 3:55 PM osumi.takami...@fujitsu.com
wrote:
> On Thursday, May 20, 2021 9:59 PM Amit Langote
> wrote:
> > Here are updated/divided patches.
> Thanks for your updates.
>
> But, I've detected segmentation faults caused by the patch,
> which can happen during 100_bugs.pl in s
On Friday, May 21, 2021 3:55 PM I wrote:
> On Thursday, May 20, 2021 9:59 PM Amit Langote
> wrote:
> > Here are updated/divided patches.
> Thanks for your updates.
>
> But, I've detected segmentation faults caused by the patch, which can
> happen during 100_bugs.pl in src/test/subscription.
> Thi
65 matches
Mail list logo
