On Fri, Jan 27, 2023 at 19:55 PM Amit Kapila wrote:
> On Fri, Jan 27, 2023 at 5:18 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Wednesday, January 25, 2023 7:26 PM Amit Kapila
>
> > >
> > > On Tue, Jan 24, 2023 at 8:15 AM wangw.f...@fujitsu.com
> > > wrote:
> > > >
> > > > Attach the new patch
Noah Misch writes:
> Yes, a hook intended to enforce pgindent cleanliness should run tree-wide
> pgindent when the given commit(s) change the typedef list. typedef list
> changes essentially become another kind of refactoring that can yield merge
> conflicts. If your commit passed the pgindent c
On Tue, Jan 24, 2023 at 02:04:02PM -0500, Bruce Momjian wrote:
> On Tue, Jan 24, 2023 at 09:54:57AM -0500, Tom Lane wrote:
> > As another example, the mechanisms we use to create the typedefs list
> > in the first place are pretty squishy/leaky: they depend on which
> > buildfarm animals are runnin
Hi,
I found what appears to be a small harmless error in numeric.c,
that seems worthwhile to fix only because it's currently causes confusion.
It hasn't caused any problems, since the incorrect formula happens to
always produce the same result for DEC_DIGITS==4.
However, for other DEC_DIGITS val
Dear Amit, Sawada-san,
I have also reproduced the failure on PG15 with some debug log, and I agreed
that
somebody changed procArray->replication_slot_xmin to InvalidTransactionId.
> > The same assertion failure has been reported on another thread[1].
> > Since I could reproduce this issue severa
On 1/28/23 05:53, Andres Freund wrote:
> Hi,
>
> On 2023-01-27 23:18:39 -0500, Tom Lane wrote:
>> I also saw it on florican, which is/was an i386 machine using clang and
>> pretty standard build options other than
>> 'CFLAGS' => '-msse2 -O2',
>> so I think this isn't too much about machine
On Thu, Jan 26, 2023 at 3:33 PM Masahiko Sawada
wrote:
>
> On Thu, Jan 26, 2023 at 3:54 PM John Naylor
> wrote:
> I think that we need to prevent concurrent updates (RT_SET() and
> RT_DELETE()) during the iteration to get the consistent result through
> the whole iteration operation. Unlike othe
> On 28/01/23 14:31, John Naylor wrote:
> I recently brought up this older thread (mostly about #1), partly
because of the issues discovered above, and partly because I hope to
make progress on it before feature freeze (likely early April):
>
https://www.postgresql.org/message-id/CAApHDvqXcmz
On Sat, Jan 28, 2023 at 3:21 PM Ankit Kumar Pandey
wrote:
>
> > On 26/01/23 07:40, David Rowley wrote:
> > We might want to look at 1) Expanding
> > on what 69749243 did and considering if we want sort specialisations
> > that are specifically for 1 column and another set for multi-columns.
> > T
On 26/01/23 07:40, David Rowley wrote:
You can see from the results that the patched version is not looking
particularly great. I did a 1 million row test and a 10 million row
test. work_mem was 4GB for each, so the sorts never went to disk.
Yes, its lackluster gains are very limited (pret
10 matches
Mail list logo
