On Sat, Jun 17, 2023 at 10:57:05AM -0400, Evan Jones wrote:
> However, if we think this change could be a problem, one fix would be to
> switch scanner_isspace() to array_isspace(), which returns true for these
> *six* ASCII characters. I am happy to submit a patch to do this.
The difference
On 2/7/23 01:09, Thomas Munro wrote:
> On Tue, Feb 7, 2023 at 1:06 PM Tomas Vondra
> wrote:
>> On 2/7/23 00:48, Thomas Munro wrote:
>>> On Tue, Feb 7, 2023 at 12:46 PM Tomas Vondra
>>> wrote:
No, I left the workload as it was for the first lockup, so `make check`
runs everything as
Has anyone recently tried updating a streaming replication cluster using
debian’s pg_upgradecluster(1) on each node?
Did things work well?
My last attempt (11 to 13, as I recall) had issues and I had to drop and
re-install the db on the secondaries.
I'd like to avoid that this time...
Should I
On Thu, Jun 15, 2023 at 4:16 AM Vladimir Churyukin
wrote:
> We're trying to see what is the worst performance in terms of I/O, i.e.
>> when the database just started up or the data/indexes being queried are not
>> cached at all.
>
>
You could create new tables that are copies of the existing
On 6/17/23 20:19, Tom Lane wrote:
> Tomas Vondra writes:
>> I guess the "correct" solution would be to extend ALTER OPERATOR. I
>> wonder why it's not supported - it's clearly an intentional decision
>> (per comment in AlterOperator). So what might break if this changes for
>> an existing
On Sat, Jun 17, 2023 at 11:29 AM Jaime Casanova
wrote:
> I have been testing 16beta1, last commit
> a14e75eb0b6a73821e0d66c0d407372ec8376105
> I just let sqlsmith do its magic before trying something else, and
> today I found a core with the attached backtrace.
The assertion that fails is the
Hi,
I have been testing 16beta1, last commit
a14e75eb0b6a73821e0d66c0d407372ec8376105
I just let sqlsmith do its magic before trying something else, and
today I found a core with the attached backtrace.
Only information on the log was this:
DETAIL: Failed process was running: autovacuum:
Tomas Vondra writes:
> I guess the "correct" solution would be to extend ALTER OPERATOR. I
> wonder why it's not supported - it's clearly an intentional decision
> (per comment in AlterOperator). So what might break if this changes for
> an existing operator?
This code was added by commit
Hi,
I've created a CF entry for the patch:
https://commitfest.postgresql.org/43/4375/
I only briefly skimmed the code, so a couple comments.
On 6/17/23 17:45, Tommy Pavlicek wrote:
> Hi All,
>
> I've written a patch to add hash functions for the ltree extension. It
> adds support for hash
Hi,
The release date for PostgreSQL 16 Beta 2 is June 29, 2023. Please be
sure to commit any open items[1] for the Beta 2 release before June 25,
2023 0:00 AoE[2] to give them enough time to work through the buildfarm.
Thanks,
Jonathan
[1]
On Wed, Jun 14, 2023 at 9:48 PM Jeff Davis wrote:
>
> Currently, CREATE COLLATION always defaults the provider to libc.
>
> The attached patch causes it to default to libc if LC_COLLATE/LC_CTYPE
> are specified, otherwise default to the current database default
> collation's provider.
+
Hi All,
I've written a patch to add hash functions for the ltree extension. It adds
support for hash indexes and hash aggregation. I've reused the existing
logic that's used to hash arrays and added tests that mirror elsewhere
(i.e. hstore and hash_func regression tests).
The patch doesn't
Unfortunately I just noticed a possible "bug" with this change. The
scanner_isspace() function only recognizes *five* ASCII space characters: '
' \t \n \r \f. It *excludes* VTAB \v, which the C standard function
isspace() includes. This means this patch changed the behavior of hstore
parsing for
On Fri, Jun 16, 2023 at 1:56 PM Tristan Partin wrote:
>
> On Fri Jun 16, 2023 at 3:29 PM CDT, Jeff Davis wrote:
> > Patch attached. Currently, the Makefile specifies NO_LOCALE=1, and the
> > meson.build does not.
>
> Looks alright to me, but it might be nicer to change the order of
> arguments to
On 2023-06-15 Th 12:12, Andrew Dunstan wrote:
On 2023-06-15 Th 11:26, Jelte Fennema wrote:
On Sat, 22 Apr 2023 at 13:42, Andrew Dunstan wrote:
Perhaps we should start with a buildfarm module, which would run pg_indent
--show-diff. That would only need to run on one animal, so a failure
On 6/17/23 02:02, Quan Zongliang wrote:
>
>
> On 2023/6/17 06:46, Tom Lane wrote:
>> Quan Zongliang writes:
>>> Perhaps we should discard this (dups cnt > 1) restriction?
>>
>> That's not going to happen on the basis of one test case that you
>> haven't even shown us. The implications of doing
On Fri, Jun 16, 2023 at 11:28 PM Jelte Fennema wrote:
>
> On Fri, 16 Jun 2023 at 16:26, Craig Ringer wrote:
> > Nobody's implemented it.
> >
> > A patch to add PQclosePrepared and PQsendClosePrepared would be welcome. At
> > least, I think so...
>
> This might have been a pretty old thread. But
On 6/17/23 00:32, Quan Zongliang wrote:
> ...
>
> It's not just a small table. If a column's value is nearly unique. It
> also causes the same problem because we exclude values that occur only
> once. samplerows <= num_mcv just solves one scenario.
> Perhaps we should discard this (dups cnt > 1)
On Tue, May 16, 2023 at 8:00 PM Masahiko Sawada wrote:
>
> On Thu, May 11, 2023 at 5:12 PM Masahiko Sawada wrote:
> >
>
> After thinking more about it, I realized that this is not a problem
> specific to HEAD. ISTM the problem is that by commit 7b64e4b3, we drop
> the stats entry of subscription
On Fri, Jun 16, 2023 at 7:15 PM Peter Eisentraut wrote:
>
> On 15.06.23 04:49, Amit Kapila wrote:
> >
> > Now, along with this change, there is a change in errhint as well
> > which I am not sure about whether to backpatch or not. I think we have
> > the following options (a) commit both doc and
20 matches
Mail list logo
