On Mon, May 16, 2022 at 2:41 PM Michael Paquier wrote:
> On Mon, May 16, 2022 at 11:34:41AM +0900, Amit Langote wrote:
> > Attached a patch to fix with a test added. cc'ing Michael who
> > authored that commit.
>
> Indeed, 6f164e6d got that incorrectly. I don't really want to play
> with the
On Mon, May 16, 2022 at 11:34:41AM +0900, Amit Langote wrote:
> Attached a patch to fix with a test added. cc'ing Michael who
> authored that commit.
Indeed, 6f164e6d got that incorrectly. I don't really want to play
with the master branch at this stage, even if this is trivial, but
I'll fix it
On Thu, May 12, 2022 at 4:27 PM Amul Sul wrote:
>
Hi Amul,
Thanks for the review, actually based on some comments from Robert we
have planned to make some design changes. So I am planning to work on
that for the July commitfest. I will try to incorporate all your
review comments in the new
On Sat, May 14, 2022 at 01:27:28AM -0700, Noah Misch wrote:
> Here, I requested the rationale for the differences you had just described.
> You made a choice to stop testing one list of database names and start testing
> a different list of database names. Why?
Because the shape of the new names
On Mon, May 16, 2022 at 07:58:37AM +0530, Amit Kapila wrote:
> I prefer to do this for pg16 unless we see some bug due to this.
Agreed. This does not seem worth taking any risk with after beta1,
and v14 got released this way.
--
Michael
signature.asc
Description: PGP signature
po 16. 5. 2022 v 6:11 odesÃlatel David Rowley napsal:
> On Fri, 6 May 2022 at 21:27, David Rowley wrote:
> > I've attached a patch to fix. I'll look at it in more detail after the
> weekend.
>
> I've now pushed this fix to master and backpatched to 14.
>
Thank you
Pavel
>
> David
>
On Fri, 6 May 2022 at 21:27, David Rowley wrote:
> I've attached a patch to fix. I'll look at it in more detail after the
> weekend.
I've now pushed this fix to master and backpatched to 14.
David
On Mon, May 09, 2022 at 09:24:06AM +0900, Michael Paquier wrote:
> Okay, applied this one on HEAD after going back-and-forth on it for
> the last couple of days. I have found myself shaping the patch in
> what looks like its simplest form, by applying the check based on an
> older checkpoint to
On Sat, 14 May 2022 at 11:01, Thomas Munro wrote:
> On Sat, May 14, 2022 at 10:25 AM Thomas Munro wrote:
>> Japin, are you able to reproduce the problem reliably? Did I guess
>> right, that you're on illumos? Does this help? I used
>> defined(__sun__) to select the option, but I don't
On Saturday, May 14, 2022 10:33 PM vignesh C wrote:
> Thanks for the comments, the attached v5 patch has the changes for the same.
> Also I have made the changes for SKIP Table based on the new syntax, the
> changes for the same are available in
>
On Sun, May 15, 2022 at 12:22 AM Jonathan S. Katz wrote:
>
> Please provide feedback no later than 2022-05-19 0:00 AoE[1].
>
> [`recovery_prefetch`](https://www.postgresql.org/docs/15/runtime-config-wal.html#GUC-RECOVERY-PREFETCH)
> that can help speed up all recovery operations by prefetching
Hi,
I noticed that $subject causes an error in HEAD:
$ pgbench -i --partitions=0
pgbench: error: --partitions must be in range 1..2147483647
However, it works in v13 and v14, assuming no partitions.
I think the commit 6f164e6d17 may have unintentionally broken it, by
introducing this hunk:
@@
On Sun, May 15, 2022 at 5:05 PM Alvaro Herrera wrote:
>
> On 2022-May-14, Amit Kapila wrote:
>
> > On Sat, May 14, 2022 at 1:57 AM Alvaro Herrera
> > wrote:
> > >
> > > We didn't have any use of TransactionId as members of List, until
> > > RelationSyncEntry->streamed_txns was introduced
On Saturday, May 14, 2022 12:07 AM 'Bruce Momjian' wrote:
> On Fri, May 13, 2022 at 01:36:04AM +, osumi.takami...@fujitsu.com wrote:
> > >
> > > This is enabled with the subscriber option "disable_on_error"
> > > and avoids possible infinite loops during stream application.
> > >
>
>
>
> 2. You calculate the cost to compare with jit_above_cost as:
>
> plan->total_cost * plan->est_loops.
>
> An alternative way might be to consider the rescan cost like
> cost_rescan. This should be closer for a final execution cost.
> However since it is hard to set a reasonable
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Bruce Momjian writes:
>> > On Wed, May 11, 2022 at 08:59:26PM -0400, Bruce Momjian wrote:
>> >> On Thu, May 12, 2022 at 09:04:38AM +0900, Tatsuo Ishii wrote:
>> >>> The last line should be
>> >>>
Hi,
Speaking as someone who regularly trawls through megabytes of build farm output:
1. It seems a bit useless to have a load of "FATAL: the database
system is in recovery mode" spam whenever the server crashes under
src/test/regress. Any reason not to just turn that off, as we do for
the TAP
On 5/15/22 21:55, Matthias van de Meent wrote:
> Note: I am not (currently) planning on implementing this rough idea,
> just putting it up to share and document the idea, on request of Tomas
> (cc-ed).
>
> The excellent pgconf.de presentation on PostgreSQL's extended
> statistics system by Tomas
Note: I am not (currently) planning on implementing this rough idea,
just putting it up to share and document the idea, on request of Tomas
(cc-ed).
The excellent pgconf.de presentation on PostgreSQL's extended
statistics system by Tomas Vondra [0] talked about how the current
default statistics
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > Here, that doesn't seem too likely. You could have a column that
> > contains 'tom' and ['tom'] and [['tom']] and [[['tom']]] and so forth
> > and they all get mapped onto the same bucket and you're sad. But
> > probably
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Bruce Momjian writes:
> > On Wed, May 11, 2022 at 08:59:26PM -0400, Bruce Momjian wrote:
> >> On Thu, May 12, 2022 at 09:04:38AM +0900, Tatsuo Ishii wrote:
> >>> The last line should be
> >>>
On Wed, Sep 1, 2021 at 11:27 AM Andres Freund wrote:
>
> Hi,
>
> Attached is an updated patch AIO series. The major changes are:
Hi Andres, is there a plan to get fallocate changes alone first? I think
fallocate API can help parallel inserts work (bulk relation extension
currently writes zero
ne 15. 5. 2022 v 14:20 odesÃlatel Simon Riggs
napsal:
> Currently, CREATE STATS requires you to think of a name for each stats
> object, which is fairly painful, so users would prefer an
> automatically assigned name.
>
> Attached patch allows this, which turns out to be very simple, since a
>
On Fri, May 13, 2022 at 09:49:54AM -0400, Robert Haas wrote:
>
> Committed.
Thanks!
For the record I submitted patches or pull requests this weekend for all
repositories I was aware of to fix the compatibility with this patch, hoping
that it will save some time to the packagers when they will
I'm sorry if you've already said this elsewhere, but can you please
state what is the *intention* of this patchset? If it's a pure
refactoring (but I don't think it is), then it's a net loss, because
after pgindent it summarizes as:
58 files changed, 2714 insertions(+), 2368 deletions(-)
so we
Currently, CREATE STATS requires you to think of a name for each stats
object, which is fairly painful, so users would prefer an
automatically assigned name.
Attached patch allows this, which turns out to be very simple, since a
name assignment function already exists.
The generated name is
On 2022-May-14, Amit Kapila wrote:
> On Sat, May 14, 2022 at 1:57 AM Alvaro Herrera
> wrote:
> >
> > We didn't have any use of TransactionId as members of List, until
> > RelationSyncEntry->streamed_txns was introduced (464824323e57, pg14).
> > It's currently implemented as a list of int. This
27 matches
Mail list logo
