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 c
On Sat, Jun 17, 2023 at 10:03 AM Jeff Davis wrote:
> On Thu, 2023-06-15 at 19:15 +1200, Thomas Munro wrote:
> > Hmm, OK let's explore that. What could we do that would be helpful
> > here, without affecting users of the "true" C.UTF-8 for the rest of
> > time?
>
> Where is the "true" C.UTF-8 defi
On Sat, Jun 17, 2023 at 1:51 AM Jacob Champion wrote:
>
> On Fri, Jun 16, 2023 at 6:26 AM Amit Kapila wrote:
>
> > > But if it's because you've implemented a partitioning scheme of your
> > > own (the docs still list reasons you might want to [2], even today),
> > > and all you ever really do is
On Fri, Jun 16, 2023, at 17:42, Joel Jacobson wrote:
> I realise int4hashset_hash() is broken,
> since two int4hashset's that are considered equal,
> can by coincidence get different hashes:
...
> Do we have any ideas on how to fix this without sacrificing performance?
The problem was due to hashs
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 it are very unclear.
In particular, I seem to recall tha
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 it are very unclear.
In particular, I seem to recall that there are bits of logic that
depend on
On 2023/6/16 23:39, Tomas Vondra wrote:
On 6/16/23 11:25, Quan Zongliang wrote:
We have a small table with only 23 rows and 21 values.
The resulting MCV and histogram is as follows
stanumbers1 | {0.08695652,0.08695652}
stavalues1 | {v1,v2}
stavalues2 |
{v3,v4,v5,v6,v7,v8,v9,v10,v11,v12,
On Fri Jun 16, 2023 at 5:10 PM CDT, Tom Lane wrote:
> "Tristan Partin" writes:
> > I am proposing that the default value of
> > client_connection_check_interval be moved to a non-zero value on
> > systems where it is supported. I think it would be a nice quality of
> > life improvement.
>
> I doub
On Fri Jun 16, 2023 at 5:10 PM CDT, Dagfinn Ilmari Mannsåker wrote:
> Andres Freund writes:
>
> > Hi,
> >
> > On 2023-06-16 16:20:14 -0400, Andrew Dunstan wrote:
> >> Unless I'm misunderstanding, this doesn't look terribly feasible to me. You
> >> can only get at %INC by loading the module, which
Andres Freund writes:
> Hi,
>
> On 2023-06-16 16:20:14 -0400, Andrew Dunstan wrote:
>> Unless I'm misunderstanding, this doesn't look terribly feasible to me. You
>> can only get at %INC by loading the module, which in many cases will have
>> side effects.
>
> I was envisioning using %INC after t
"Tristan Partin" writes:
> I am proposing that the default value of
> client_connection_check_interval be moved to a non-zero value on
> systems where it is supported. I think it would be a nice quality of
> life improvement.
I doubt that we need this, and I *really* doubt that it's appropriate
t
On Thu, 2023-06-15 at 19:15 +1200, Thomas Munro wrote:
> Hmm, OK let's explore that. What could we do that would be helpful
> here, without affecting users of the "true" C.UTF-8 for the rest of
> time?
Where is the "true" C.UTF-8 defined?
I assume you mean that the collation order can't (shouldn
Hi hackers,
In modern versions of Postgres the dollar sign is a totally legal character
for identifiers (except for the first character), but tab-complete do not
treat such identifiers well.
For example if one try to create an Oracle-style view like this:
create view v$activity as select * from p
On Fri, 2023-06-16 at 16:01 +0200, Peter Eisentraut wrote:
> What happens if after this patch you continue to specify
> provider=libc
> and locale=C? Do you then get the "slow" path?
Users can continue to use the libc provider as they did before and the
fast path will still work.
> Should there
I have applied the patch to the latest master branch and successfully executed
'./configure && make && make check' on macOS Ventura. However, during the
process, a warning was encountered: "mixing declarations and code is
incompatible with standards before C99 [-Wdeclaration-after-statement]". M
Hi,
On 2023-06-16 16:20:14 -0400, Andrew Dunstan wrote:
> Unless I'm misunderstanding, this doesn't look terribly feasible to me. You
> can only get at %INC by loading the module, which in many cases will have
> side effects.
I was envisioning using %INC after the use/require block - I don't thin
Attached patch adds additional hardening to nbtree page deletion. It
makes nbtree VACUUM tolerate a certain sort of cross-page
inconsistencies in the structure of an index (corruption). VACUUM can
press on, avoiding an eventual wraparound/xidStopLimit failure in
environments where nobody notices th
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 match contrib/unaccent/meson.build:40. Might help with
grepping in t
Hi,
I am proposing that the default value of
client_connection_check_interval be moved to a non-zero value on
systems where it is supported. I think it would be a nice quality of
life improvement. I have run into a problem where this would have been
useful before with regard to pgbench not current
Patch attached. Currently, the Makefile specifies NO_LOCALE=1, and the
meson.build does not.
--
Jeff Davis
PostgreSQL Contributor Team - AWS
From 1775c98badb94a2ee185d7a6bd11482a4e5db58a Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Fri, 16 Jun 2023 11:51:00 -0700
Subject: [PATCH v1] test_e
On Fri, Jun 16, 2023 at 6:26 AM Amit Kapila wrote:
> On Sat, Apr 1, 2023 at 5:06 AM Jacob Champion wrote:
> > I think it comes down to why an inheritance scheme was used. If it's
> > because you want to group rows into named, queryable subsets (e.g. the
> > "cities/capitals" example in the docs [
On 2023-06-14 We 15:32, Andres Freund wrote:
Hi,
On 2023-06-09 11:43:54 -0700, Andres Freund wrote:
On 2023-06-02 10:13:44 -0500, Tristan Partin wrote:
On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
Hi,
On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
I wonder if we instead cou
On Fri, Jun 16, 2023 at 04:51:38PM +0900, Kyotaro Horiguchi wrote:
> (Honestly, the rearrangement code looks somewhat tricky to grasp..)
Yeah, I think there's still some room for improvement here.
> It doesn't work properly if '--' is involved.
>
> For example, consider the following options (ev
On 2023/06/17 1:16, Tristan Partin wrote:
> I will take a look at your V2 when it is ready! I will also pass along
> that this is wanted by Neon customers :).
Thanks!
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
On Fri, 2023-06-16 at 16:50 +0200, Peter Eisentraut wrote:
> This looks good to me.
>
> Attached is small fixup patch with some documentation tweaks and
> simplifying some test code (also includes pgperltidy).
Thank you. Committed with your fixups.
Regards,
Jeff Davis
I will take a look at your V2 when it is ready! I will also pass along
that this is wanted by Neon customers :).
--
Tristan Partin
Neon (https://neon.tech)
On Fri, Jun 16, 2023, at 13:57, jian he wrote:
> similar to (int[] || int4) and (int4 || int[])
> should we expect ('{1,2}'::int4hashset || 3) == (3 ||
> '{1,2}'::int4hashset) == (select hashset_add('{1,2}'::int4hashset,3));
> *?*
Good idea, makes sense to support it.
Implemented in attached pa
On 6/16/23 11:25, Quan Zongliang wrote:
>
> We have a small table with only 23 rows and 21 values.
>
> The resulting MCV and histogram is as follows
> stanumbers1 | {0.08695652,0.08695652}
> stavalues1 | {v1,v2}
> stavalues2 |
> {v3,v4,v5,v6,v7,v8,v9,v10,v11,v12,v13,v14,v15,v16,v17,v18,v19,v
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 I just took it upon me
to implement these functions (or well I mostly
On 14.06.23 23:24, Jeff Davis wrote:
On Mon, 2023-06-12 at 23:04 +0200, Peter Eisentraut wrote:
Patch 0003:
Makes LOCALE apply to all providers. The overall feel after this
patch
is that "locale" now means the collation locale, and
LC_COLLATE/LC_CTYPE are for the server environment. When using
Hi,
> Pretty sure that reopening an already rejected patch that is competing
> with compression dictionaries (which the rest of us are currently
> focusing on) will achieve anything.
Ooops, I didn't mean to be sarcastic:
s/will achieve/will not achieve/
My apologies.
> Consider joining the com
Hey everyone,
I've discovered a serious bug that leads to a server crash upon promoting an
instance that crashed previously and did
recovery in standby mode.
The bug is present in PostgreSQL versions 13 and 14 (and in earlier versions,
though it doesn't manifest itself so
catastrophically).
The
Hi hackers,
pg_get_backend_memory_contexts() (and pg_backend_memory_contexts view)
does not display parent/child relation between contexts reliably.
Current version of this function only shows the name of parent context
for each context. The issue here is that it's not guaranteed that
context name
On 15.06.23 00:55, Jeff Davis wrote:
The locale "C" (and equivalently, "POSIX") is not really a libc locale;
it's implemented internally with memcmp for collation and
pg_ascii_tolower, etc., for ctype.
The attached patch implements a new collation provider, "builtin",
which only supports "C" and
On 15.06.23 04:49, Amit Kapila wrote:
I wanted to backpatch the following change which provides somewhat
accurate information about what a user needs to do when it faces an
error.
To proceed in
- this situation, disassociate the subscription from the replication slot by
- executing ALTER SUBS
On Sat, Apr 1, 2023 at 5:06 AM Jacob Champion wrote:
>
> On Fri, Mar 31, 2023 at 3:17 PM Peter Smith wrote:
>
> > Outside the scope of special TimescaleDB tables and the speculated
> > pg_partman old-style table migration, will this proposed new feature
> > have any other application? In other wo
Hi Nikita,
> We already have a lot of changes in Pluggable TOAST that were not committed
> to the main GIT branch of this thread, so it seems that I have to merge them
> and
> reopen it.
Pretty sure that reopening an already rejected patch that is competing
with compression dictionaries (which t
Hi hackers,
Relcache errors from time to time detect catalog corruptions. For example,
recently I observed following:
1. Filesystem or nvme disk zeroed out leading 160Kb of catalog index. This type
of corruption passes through data_checksums.
2. RelationBuildTupleDesc() was failing with "catalog
similar to (int[] || int4) and (int4 || int[])
should we expect ('{1,2}'::int4hashset || 3) == (3 ||
'{1,2}'::int4hashset) == (select hashset_add('{1,2}'::int4hashset,3)); *?*
The following is the general idea on how to make it work by looking at
similar code
CREATE OPERATOR || (
leftarg
On 2023-06-16 16:46, Michael Paquier wrote:
On Fri, Jun 16, 2023 at 11:14:05AM +0900, Masahiro Ikeda wrote:
I tried to query on pg_stat_activity to check the background worker
invoked by pg_prewarm. But, I found that pg_stat_activity doesn't show
it although I may be missing something...
So, I
New patch attached:
Add customizable params to int4hashset() and collision count function
This commit enhances int4hashset() by introducing adjustable capacity,
load, and growth factors, providing flexibility for performance optimization.
Also added is a new function, hashset_collisions(), to re
Hi,
Seems that I missed the thread mentioned above. I strongly disagree
with such statement, Pluggable TOAST could not be a part or Compression
Dictionaries thread because the TOAST improvement is a more general subject,
it involves much deeper and tricky changes in the core. And also is much
more
On Mon, Apr 17, 2023 at 7:37 PM Drouvot, Bertrand
wrote:
>
> Please find attached V5 (a rebase of V4 posted up-thread).
>
> In addition to the "rebasing" work, the TAP test adds a test about conflict
> handling (logical slot invalidation)
> relying on the work done in the "Minimal logical decodin
On 2023-Jun-16, Masahiko Sawada wrote:
> The walreceiver process doesn't use CRS_EXPORT_SNAPSHOT actually,
> right? I think replacing it with CRS_EXPORT_SNAPSHOT would rather
> confuse me
libpqwalreceiver.c does use it. But I agree -- I think it would be
better to not use the enum in walreceiver
On Fri, Jun 16, 2023 at 6:17 PM Masahiko Sawada wrote:
>
> On Fri, Jun 16, 2023 at 3:10 PM Wei Wang (Fujitsu)
> wrote:
> >
> > Hi,
> >
> > In the function WalReceiverMain, when the function walrcv_create_slot is
> > called,
> > the fourth parameter is assigned the value "0" instead of the enum v
We have a small table with only 23 rows and 21 values.
The resulting MCV and histogram is as follows
stanumbers1 | {0.08695652,0.08695652}
stavalues1 | {v1,v2}
stavalues2 |
{v3,v4,v5,v6,v7,v8,v9,v10,v11,v12,v13,v14,v15,v16,v17,v18,v19,v20,v21}
An incorrect number of rows was estimated when
On Fri, Jun 16, 2023 at 3:10 PM Wei Wang (Fujitsu)
wrote:
>
> Hi,
>
> In the function WalReceiverMain, when the function walrcv_create_slot is
> called,
> the fourth parameter is assigned the value "0" instead of the enum value
> "CRS_EXPORT_SNAPSHOT". I think it would be better to use the corres
At Thu, 15 Jun 2023 21:58:28 -0700, Nathan Bossart
wrote in
> On Fri, Jun 16, 2023 at 10:30:09AM +0900, Michael Paquier wrote:
> > On Thu, Jun 15, 2023 at 05:09:59PM -0700, Nathan Bossart wrote:
> >> I've attached a new version of the patch that omits the
> >> POSIXLY_CORRECT stuff.
> >
> > Thi
On Fri, Jun 16, 2023 at 11:14:05AM +0900, Masahiro Ikeda wrote:
> I tried to query on pg_stat_activity to check the background worker
> invoked by pg_prewarm. But, I found that pg_stat_activity doesn't show
> it although I may be missing something...
>
> So, I tried to implement TAP tests. But I h
49 matches
Mail list logo
