On Fri, Sep 10, 2021 at 08:21:51AM +, gkokola...@pm.me wrote:
> Agreed. A default value of 5, which is in the middle point of options, has
> been
> defined and used.
>
> In addition, the tests have been adjusted to mimic the newly added gzip tests.
Looking at lz4frame.h, there is LZ4F_flush(
On 14/9/21 16:37, Aleksander Alekseev wrote:
Hi Andrey,
only performance issues
That's interesting. Any chance you could share the hardware
description, the configuration file, and steps to reproduce with us?
I didn't control execution time exactly. Because it is a join of two
empty tables.
Etsuro Fujita писал 2021-08-30 12:52:
On Mon, Aug 30, 2021 at 5:36 PM Andrey V. Lepikhov
To allow async execution in a bit more cases, I modified the patch a
bit further: a ProjectionPath put directly above an async-capable
ForeignPath would also be considered async-capable as ForeignScan can
pr
On 14/9/21 11:37, Andrey V. Lepikhov wrote:
Thank you for this good catch!
The problem was in the adjust_child_relids_multilevel routine. The
tmp_result variable sometimes points to original required_outer.
This patch adds new ways which optimizer can generate plans. One
possible way is optimiz
On Fri, Sep 03, 2021 at 08:27:55PM +0200, Daniel Gustafsson wrote:
> > On 19 May 2021, at 09:53, Michael Paquier wrote:
> >
> > On Tue, Apr 27, 2021 at 12:58:52PM +0300, Aleksander Alekseev wrote:
> >> I've noticed there is no tab completion for ALTER TABLE xxx ADD. Here
> >> is an alternative ve
On Wed, Sep 15, 2021 at 4:14 AM Stephen Frost wrote:
>
> > > I'm not proposing to remove existing archive_command. Just deprecate it
> > > one-WAL-per-call form.
> >
> > Which is a big API beak.
>
> We definitely need to stop being afraid of this. We completely changed
> around how restores work
On 2021/09/11 12:21, Fujii Masao wrote:
On 2021/07/23 20:07, Ranier Vilela wrote:
Em sex., 23 de jul. de 2021 às 07:02, Aleksander Alekseev mailto:aleksan...@timescale.com>> escreveu:
Hi hackers,
The following review has been posted through the commitfest application:
On Wed, Sep 15, 2021 at 8:49 AM Peter Smith wrote:
>
> On Tue, Sep 14, 2021 at 8:33 PM Amit Kapila wrote:
> >
> > On Fri, Jun 25, 2021 at 9:20 AM Peter Smith wrote:
> > >
> > > But I recently learned that when there are partitions in the
> > > publication, then toggling the value of the PUBLICAT
On Tue, Sep 14, 2021 at 05:30:27PM -0400, John Naylor wrote:
> I've attached the patch for including this update in our sources. I'll
> apply it on master after doing some sanity checks. The announcement can be
> found here:
>
> http://blog.unicode.org/2021/09/announcing-unicode-standard-version-1
On Mon, Sep 6, 2021 at 11:21 PM Alvaro Herrera wrote:
>
> I pushed the clerical part of this -- namely the addition of
> PublicationTable node and PublicationRelInfo struct.
>
One point to note here is that we are developing a generic grammar for
publications where not only tables but other objec
On Tue, Sep 14, 2021 at 8:33 PM Amit Kapila wrote:
>
> On Fri, Jun 25, 2021 at 9:20 AM Peter Smith wrote:
> >
> > But I recently learned that when there are partitions in the
> > publication, then toggling the value of the PUBLICATION option
> > "publish_via_partition_root" [3] can also *implicit
On Tue, Sep 14, 2021 at 06:00:44PM +, Bossart, Nathan wrote:
> I think I see more support for shared_memory_size_in_huge_pages than
> for huge_pages_needed_for_shared_memory at the moment. I'll update
> the patch set in the next day or two to use
> shared_memory_size_in_huge_pages unless somet
At Tue, 14 Sep 2021 22:32:04 -0300, Alvaro Herrera
wrote in
> On 2021-Sep-14, Alvaro Herrera wrote:
>
> > On 2021-Sep-08, Kyotaro Horiguchi wrote:
> >
> > > Thanks! As my understanding the new record add the ability to
> > > cross-check between a teard-off contrecord and the new record insert
At Tue, 14 Sep 2021 18:07:31 +, "Bossart, Nathan"
wrote in
> On 9/14/21, 9:18 AM, "Bossart, Nathan" wrote:
> > This is an interesting idea, but the "else" block here seems prone to
> > race conditions. I think we'd have to hold arch_lck to prevent that.
> > But as I mentioned above, if we
On 2021-Sep-14, Alvaro Herrera wrote:
> On 2021-Sep-08, Kyotaro Horiguchi wrote:
>
> > Thanks! As my understanding the new record add the ability to
> > cross-check between a teard-off contrecord and the new record inserted
> > after the teard-off record. I didn't test the version by myself but
Hello Melanie
On 2021-Sep-13, Melanie Plageman wrote:
> I also think it makes sense to rename the pg_stat_buffer_actions view to
> pg_stat_buffers and to name the columns using both the buffer action
> type and buffer type -- e.g. shared, strategy, local. This leaves open
> the possibility of cou
> On Jun 16, 2020, at 6:55 AM, amul sul wrote:
>
> (2) if the session is idle, we also need the top-level abort
> record to be written immediately, but can't send an error to the client until
> the next
> command is issued without losing wire protocol synchronization. For now, we
> just use
>
> On 15 Sep 2021, at 00:14, Jacob Champion wrote:
> On Mon, 2021-09-13 at 15:04 +0200, Daniel Gustafsson wrote:
>> -# Convert client.key to encrypted PEM (X.509 text) and DER (X.509 ASN.1)
>> formats
>> -# to test libpq's support for the sslpassword= option.
>> -ssl/client-encrypted-pem.key: out
On Tue, Sep 14, 2021 at 12:57:47PM -0300, Alvaro Herrera wrote:
> The parentheses that commit e3a87b4991cc removed the requirement for are
> those that the committed code still has, starting at the errcode() line.
> The ones in errmsg() were redundant and have never been necessary.
Indeed, thanks!
On Mon, 2021-09-13 at 15:04 +0200, Daniel Gustafsson wrote:
> A few things noted (and fixed as per the attached, which is v6 squashed and
> rebased on HEAD; commitmessage hasn't been addressed yet) while reviewing:
>
> * Various comment reflowing to fit within 79 characters
>
> * Pass through the
I wrote:
> Hence, I present the attached, which also tweaks things to avoid an
> extra pq_flush in the end-of-command code path, and improves the
> comments to discuss the issue of NOTIFYs sent by procedures.
Hearing no comments, I pushed that.
> I'm inclined to think we should flat-out reject LI
> So I wonder, isn't the fixed usage issue specific to LLVM 7
That's definitely possible. I was unable to reproduce the issue I shared in my
original email when postgres was compiled with LLVM 10.
That's also why I sent an email to the pgsql-pkg-yum mailing list about options
to use a newer ve
Greetings,
* Julien Rouhaud (rjuju...@gmail.com) wrote:
> On Fri, Sep 10, 2021 at 2:03 PM Andrey Borodin wrote:
> > > 10 сент. 2021 г., в 10:52, Julien Rouhaud написал(а):
> > > Yes, but it also means that it's up to every single archiving tool to
> > > implement a somewhat hackish parallel vers
Zhihong Yu writes:
> In the fix, isUsedSubplan is used to tell whether any given subplan is used.
> Since only one subplan is used, I wonder if the array can be replaced by
> specifying the subplan is used.
That doesn't seem particularly more convenient. The point of the bool
array is to merge t
On Tue, Sep 14, 2021 at 10:44 AM Tom Lane wrote:
> Rajkumar Raghuwanshi writes:
> > I am getting "ERROR: subplan "SubPlan 1" was not initialized" error with
> > below test case.
>
> > CREATE TABLE tbl ( c1 int, c2 int, c3 int ) PARTITION BY LIST (c1);
> > create table tbl_null PARTITION OF tbl
Hello Andres,
14.09.2021 08:05, Andres Freund wrote:
>
>> With LLVM 9 on the same Centos 7 I don't get such segfault. Also it
>> doesn't happen on different OSes with LLVM 7.
> That just like an llvm bug to me. Rather than the usage issue addressed in
> this thread.
But Justin seen this strangenes
On 9/13/21, 11:06 PM, "Amul Sul" wrote:
> The patch is straightforward but the only concern is that in
> StartupXLOG(), SharedRecoveryState now gets updated only with spin
> lock; earlier it also had ControlFileLock in addition to that. AFAICU,
> I don't see any problem there, since until the star
On 9/14/21 2:04 PM, Erik Rijkers wrote:
> On 9/14/21 2:53 PM, Andrew Dunstan wrote:
>> On 9/13/21 5:41 AM, Erik Rijkers wrote:
>>> On 9/2/21 8:52 PM, Andrew Dunstan wrote:
>>>
>
> >> [0001-SQL-JSON-functions-v51.patch]
> >> [0002-JSON_TABLE-v51.patch]
> >> [0003-JSON_TABLE-PLAN-DEFAULT-clause-v51
Dear Alvaro,
We just need to rewrite the scope of the patch so I work on the next
generation. I do not know what was "out of scope" in the current version
/Mark
On Tue, 14 Sep 2021, 8:55 pm Alvaro Herrera,
wrote:
> On 2021-Sep-14, Daniel Gustafsson wrote:
>
> > Given the above, and that nothin
> On 14 Sep 2021, at 20:54, Alvaro Herrera wrote:
>
> On 2021-Sep-14, Daniel Gustafsson wrote:
>
>> Given the above, and that nothing has happened on this thread since this
>> note,
>> I think we should mark this Returned with Feedback and await a new
>> submission.
>> Does that seem reasonabl
On 2021-Sep-14, Daniel Gustafsson wrote:
> Given the above, and that nothing has happened on this thread since this note,
> I think we should mark this Returned with Feedback and await a new submission.
> Does that seem reasonable Alvaro?
It seems reasonable to me.
--
Álvaro Herrera
> On 14 Jul 2021, at 18:07, Alvaro Herrera wrote:
>
> On 2021-Jul-14, vignesh C wrote:
>
>> The patch does not apply on Head anymore, could you rebase and post a
>> patch. I'm changing the status to "Waiting for Author".
>
> BTW I gave a look at this patch in the March commitfest and concluded
út 14. 9. 2021 v 20:04 odesílatel Erik Rijkers napsal:
> On 9/14/21 2:53 PM, Andrew Dunstan wrote:
> > On 9/13/21 5:41 AM, Erik Rijkers wrote:
> >> On 9/2/21 8:52 PM, Andrew Dunstan wrote:
> >>
>
> >> [0001-SQL-JSON-functions-v51.patch]
> >> [0002-JSON_TABLE-v51.patch]
> >> [0003-JSON_TABLE-PL
On 9/14/21, 9:18 AM, "Bossart, Nathan" wrote:
> This is an interesting idea, but the "else" block here seems prone to
> race conditions. I think we'd have to hold arch_lck to prevent that.
> But as I mentioned above, if we are okay with depending on the
> fallback directory scans, I think we can
On 9/14/21 2:53 PM, Andrew Dunstan wrote:
On 9/13/21 5:41 AM, Erik Rijkers wrote:
On 9/2/21 8:52 PM, Andrew Dunstan wrote:
>> [0001-SQL-JSON-functions-v51.patch]
>> [0002-JSON_TABLE-v51.patch]
>> [0003-JSON_TABLE-PLAN-DEFAULT-clause-v51.patch]
>> [0004-JSON_TABLE-PLAN-clause-v51.patch]
Thank
On 9/13/21, 5:49 PM, "Kyotaro Horiguchi" wrote:
> At Tue, 14 Sep 2021 00:30:22 +, "Bossart, Nathan"
> wrote in
>> On 9/13/21, 1:25 PM, "Tom Lane" wrote:
>> > Seems like "huge_pages_needed_for_shared_memory" would be sufficient.
>>
>> I think we are down to either shared_memory_size_in_huge_
On 2021-Sep-08, Kyotaro Horiguchi wrote:
> Thanks! As my understanding the new record add the ability to
> cross-check between a teard-off contrecord and the new record inserted
> after the teard-off record. I didn't test the version by myself but
> the previous version implemented the essential
Rajkumar Raghuwanshi writes:
> I am getting "ERROR: subplan "SubPlan 1" was not initialized" error with
> below test case.
> CREATE TABLE tbl ( c1 int, c2 int, c3 int ) PARTITION BY LIST (c1);
> create table tbl_null PARTITION OF tbl FOR VALUES IN (null);
> create table tbl_def PARTITION OF tbl
On 9/14/21, 7:23 AM, "Dipesh Pandit" wrote:
> I agree that when we are creating a .ready file we should compare
> the current .ready file with the last .ready file to check if this file is
> created out of order. We can store the state of the last .ready file
> in shared memory and compare it w
On 2021-Sep-14, Michael Paquier wrote:
> On Mon, Sep 13, 2021 at 08:51:18AM +0530, Bharath Rupireddy wrote:
> > On Mon, Sep 13, 2021 at 8:07 AM Michael Paquier wrote:
> >> On Sun, Sep 12, 2021 at 10:14:36PM -0300, Euler Taveira wrote:
> >>> On Sun, Sep 12, 2021, at 8:02 PM, Bossart, Nathan wrote:
Hello
I found that in 0001 you propose to rename few options. Probably we could
rename another option for clarify? I think FAST (it's about some bw limits?)
and WAIT (wait for what? checkpoint?) option names are confusing.
Could we replace FAST with "CHECKPOINT [fast|spread]" and WAIT to
WAIT_W
Hi,
On September 14, 2021 7:11:25 AM PDT, Tom Lane wrote:
>Aleksander Alekseev writes:
>>> Initial experiments show no observable problems when copying PGDATA or in
>>> fact using physical streaming replication between the two CPU architectures.
>
>> That's an interesting result. The topic of p
On Tue, Sep 7, 2021 at 11:38 AM houzj.f...@fujitsu.com
wrote:
>
> From Tues, Sep 7, 2021 12:02 PM Amit Kapila wrote:
> > On Mon, Sep 6, 2021 at 1:49 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > I can reproduce this bug.
> > >
> > > I think the reason is it didn't invalidate all the leaf par
On Mon, Sep 13, 2021 at 9:42 PM Robert Haas wrote:
>
> On Mon, Sep 13, 2021 at 7:19 AM Dilip Kumar wrote:
> > Seems like nothing has been done about the issue reported in [1]
> >
> > This one line change shall fix the issue,
>
> Oops. Try this version.
Thanks, this version works fine.
--
Regar
Thanks for the feedback.
> The latest post on this thread contained a link to this one, and it
> made me want to rewind to this point in the discussion. Suppose we
> have the following alternative scenario:
>
> Let's say step 1 looks for WAL file 10, but 10.ready doesn't exist
> yet. The followin
Aleksander Alekseev writes:
>> Initial experiments show no observable problems when copying PGDATA or in
>> fact using physical streaming replication between the two CPU architectures.
> That's an interesting result. The topic of physical replication
> compatibility interested me much back in 201
> 14 сент. 2021 г., в 18:41, Daniel Gustafsson написал(а):
>
>>> Besides this patch looks good and is ready for committer IMV.
>
> A variant of this patch was originally objected against by Michael, and as
> this
> version is marked Ready for Committer I would like to hear his opinions on
>
"Andrey V. Lepikhov" writes:
> Also, as a test, I used two tables with 1E5 partitions each. I tried to
> do plain SELECT, JOIN, join with plain table. No errors found, only
> performance issues. But it is a subject for another research.
Yeah, there's no expectation that the performance would be
>> Besides this patch looks good and is ready for committer IMV.
A variant of this patch was originally objected against by Michael, and as this
version is marked Ready for Committer I would like to hear his opinions on
whether the new evidence changes anything.
--
Daniel Gustafsson
Em ter., 14 de set. de 2021 às 08:49, Rajkumar Raghuwanshi <
rajkumar.raghuwan...@enterprisedb.com> escreveu:
> Hi,
>
> I am getting "ERROR: subplan "SubPlan 1" was not initialized" error with
> below test case.
>
> CREATE TABLE tbl ( c1 int, c2 int, c3 int ) PARTITION BY LIST (c1);
> create tabl
> On 14 Sep 2021, at 11:57, Amit Kapila wrote:
> LGTM as well. Peter E., Daniel, does any one of you is intending to
> push this? If not, I can take care of this.
No worries, I can pick it up.
--
Daniel Gustafsson https://vmware.com/
Hi Jan,
> Initial experiments show no observable problems when copying PGDATA or in
fact using physical streaming replication between the two CPU architectures.
That's an interesting result. The topic of physical replication
compatibility interested me much back in 2017 and I raised this question
Hi,
I am getting "ERROR: subplan "SubPlan 1" was not initialized" error with
below test case.
CREATE TABLE tbl ( c1 int, c2 int, c3 int ) PARTITION BY LIST (c1);
create table tbl_null PARTITION OF tbl FOR VALUES IN (null);
create table tbl_def PARTITION OF tbl DEFAULT;
insert into tbl values (88
Hi Andrey,
> only performance issues
That's interesting. Any chance you could share the hardware
description, the configuration file, and steps to reproduce with us?
--
Best regards,
Aleksander Alekseev
Fellow Postgres Admins and Developers,
With the arrival of ARM compute nodes on AWS and an existing fleet of
Postgres clusters running on x86_64 nodes the question arises how to
migrate existing Postgres clusters to ARM64 nodes, ideally with zero
downtime, as one is used to.
Initial experiments s
On Tue, Sep 14, 2021 at 12:18:21PM +0900, Amit Langote wrote:
> Patch updated. Given the new text, I thought it might be better to
> move the paragraph right next to the description of the ResourceOwner
> API at the beginning of the section, because the context seems clearer
> that way. Thoughts?
On Fri, Jun 25, 2021 at 9:20 AM Peter Smith wrote:
>
> But I recently learned that when there are partitions in the
> publication, then toggling the value of the PUBLICATION option
> "publish_via_partition_root" [3] can also *implicitly* change the list
> published tables, and therefore that too m
On Wed, Sep 8, 2021 at 5:11 PM Masahiko Sawada wrote:
>
> On Tue, Sep 7, 2021 at 9:01 PM Daniel Gustafsson wrote:
> >
> > > On 7 Sep 2021, at 13:36, Peter Eisentraut
> > > wrote:
> > >
> > > On 12.08.21 04:52, Masahiko Sawada wrote:
> > >> On Wed, Aug 11, 2021 at 5:42 PM Daniel Gustafsson
> >
On Mon, Sep 13, 2021 at 10:42 PM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > Am I the only that that thinks this code is doing far too much in a
> > PG_CATCH block?
>
> You mean the one in ReorderBufferProcessTXN? Yeah, that is mighty
> ugly. It might be all right given that it almost immedi
On Tue, Sep 14, 2021 at 6:31 AM houzj.f...@fujitsu.com
wrote:
>
> From Sun, Sept 12, 2021 11:13 PM vignesh C wrote:
> > On Fri, Sep 10, 2021 at 11:21 AM Hou Zhijie wrote:
> > > Attach the without-flag version and add comments about the pubobj_name.
> >
> > Thanks for the changes, the suggested c
On Mon, Sep 13, 2021 at 7:06 PM tanghy.f...@fujitsu.com
wrote:
>
> On Sunday, September 12, 2021 11:13 PM vignesh C wrote:
> >
> > Thanks for the changes, the suggested changes make the parsing code
> > simpler. I have merged the changes to the main patch. Attached v27
> > patch has the changes f
61 matches
Mail list logo
