On 5/17/25 7:58 PM, Regina Obe wrote:
Yah that is why I was suggesting as a switch not a default option. I think the
default option works fine in most cases.
But I was thinking does pg_upgrade rely at all on OIDs? I guess that might make
this not doable. I wasn't sure if that is part of the re
On 5/17/25 12:18 AM, Regina Obe wrote:
It's my understanding that right now when you run pg_upgrade it creates the
extension from what exists in the to be upgraded databases.
Is there a reason why we can't have some sort of switch option that allows
the CREATE EXTENSION from the scripts instead
On 3/31/25 5:33 PM, Dean Rasheed wrote:
On 3/4/25 10:24 AM, Andreas Karlsson wrote:
Rebased the patch to add support for OLD.* and NEW.*.
I took a closer look at this, and I have a number of comments:
Thanks for taking a look and improving my patch! And thanks to Kirill too.
* The
On 4/3/25 11:29 PM, Noah Misch wrote:
Pushed (e.g. v16 has commit 82a8f0f). Only v16 had libpq-be-fe-helpers.h at
all, so I also back-patched 28a5917 to add it. The original use case for
libpq-be-fe-helpers.h was interrupting PQconnectdbParams(), commit e460248. I
decided not to back-patch tha
On 3/12/25 12:48 AM, Noah Misch wrote:
The CREATE DATABASE hang is indeed new in v15. The general dblink missed
interrupt processing (e.g. pg_cancel_backend response delay) is an old bug.
Aha, that was what you were referring to! My apologies, was reading your
mail a bit too quickly. :)
Co
On 2/5/25 11:00 AM, Daniel Gustafsson wrote:
This fell off the ever-growing TODO again. Re-reading it I still think it's a
good idea, it applied almost cleanly still and still gives a slight performance
improvement along with the more interesting refactoring which will make caching
of expression
On 3/7/25 12:48 AM, Jelte Fennema-Nio wrote:
Okay, I went for the approach of just trying everything until one
works. Starting with "git am", then patch(1), and as a final attempt
"git apply". Patch 5272 applies correctly now. I've removed any
backoff caused by repeated failures for all existing
On 11/22/23 2:29 AM, Noah Misch wrote:
Something as simple as the following doesn't respond to cancellation. In
v15+, any DROP DATABASE will hang as long as it's running:
Hi,
One of our customers ran into this bug when upgrading from PostgreSQL 14
to PostgreSQL 16. Your commit[1] fixed this
On 3/4/25 10:24 AM, Andreas Karlsson wrote:
Rebased the patch to add support for OLD.* and NEW.*.
Apparently the CI did not like that version.
Andreas
From 795c78c79bc7b2dbddfa828e4c01c5641d0be272 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Mon, 18 Nov 2024 00:29:15 +0100
Subject
On 3/5/25 12:14 AM, Jelte Fennema-Nio wrote:
On Tue, 4 Mar 2025 at 22:01, Andreas Karlsson wrote:
What I need to see is the below (plus any future commit fests).
Thanks you for describing how you use the current homepage. That's
super helpful.
I am interested in the dates when commit
On 3/4/25 2:30 PM, Jelte Fennema-Nio wrote:
On Tue, 4 Mar 2025 at 13:36, Amit Kapila wrote:
On Tue, Mar 4, 2025 at 4:05 PM Álvaro Herrera wrote:
I think showing different pages on the same URL depending on whether
you're logged in or not is not great UX.
+1. The default should be what we
Hi,
Rebased the patch to add support for OLD.* and NEW.*.
Andreas
From ffa108d03455fc3d901ff32b585dd8dc62a25963 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Mon, 18 Nov 2024 00:29:15 +0100
Subject: [PATCH v5] Add support for ON CONFLICT DO SELECT [ FOR ... ]
Adds support for DO
On 3/4/25 3:01 AM, Michael Paquier wrote:
On Mon, Mar 03, 2025 at 01:13:05PM +0900, Michael Paquier wrote:
In short, LGTM. Will apply if there are no objections.
And applied as 40d3f8274499.
Thanks!
Andreas
more
common the OOM which causes alloc() to incorrectly return NULL could in
theory happen in any of the three functions.
Andreas
From 7165657a4b62ac35e2c67b9e51035be2a5fbb93f Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Sat, 1 Mar 2025 00:27:52 +0100
Subject: [PATCH] Add assertion
mber?
Andreas
From 87ce622a19315b679bbd5691e01c96261bc0c4c8 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Thu, 27 Feb 2025 00:23:44 +0100
Subject: [PATCH] meson: Add support for EXTRA_REGRESS_OPTS
Add support for the EXTRA_REGRESS_OPTS environment variable in meson
which works just like with make and ap
On 2/11/25 9:25 PM, Tom Lane wrote:
Greg Sabino Mullane writes:
I say "of course" but few people (even tech ones) know the distinction.
(Nor should they have to! But that's for a nearby thread). This patch aims
to prevent this very bad footgun by only allowing a /0 if the IP consists
of only ze
On 9/21/24 8:24 PM, Nitin Jadhav wrote:
I reviewed the discussion and took a look at the patch sets. It seems
like many things are combined here. Based on the subject, I initially
thought it aimed to provide the infrastructure to easily extend
storage managers. This would allow anyone to create t
On 12/19/24 9:57 PM, Peter Eisentraut wrote:
Here is an updated patch set on top of what has been committed so far,
with all the issues you pointed out addressed.
Other than the discussion of how old versions of flex we should support
I think this set of patches is ready to be committed. I loo
On 10/29/24 8:55 PM, Andreas Karlsson wrote:
I especially dislike the static variable in our patch. And as far as I
understand it you can avoid the static by changing the lexer to use the
push parser so it can emit multiple terminal tokens from one parsed
token, but I have not looked into push
round to it yet.
= v9-0004-Move-ICU-database-encoding-check-into-validation-.patch
This seems to be causing a test failure in 020_createdb.pl.
Thanks, I have attached a fixup commit for this.
Andreas
From ccaaf785a2aa14460d8360709d6f0ea4746f0157 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
ap_utf8ToUpper() and ucasemap_utf8ToLower() vs ucasemap_utf8ToTitle().
Andreas
From 5a355ef083cc7de92ae1e5dcc0198866a07919eb Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Tue, 17 Dec 2024 22:47:00 +0100
Subject: [PATCH v1 1/2] Use optimized versions of ICU case conversion for
UTF-8
Instead of converti
On 12/18/24 10:42 AM, Peter Eisentraut wrote:
I can fix that with the attached patch.
The symbol YY_TYPEDEF_YY_SCANNER_T isn't documented, but we already use
it elsewhere in the code.
Note that in replication/syncrep.h and replication/walsender_private.h
we have to have an #ifndef wrapper be
On 12/12/24 10:00 AM, Jeff Davis wrote:
Patch attached.
I have not looked at the patch yet but +1 to the idea. I am leaning
towards that the function also optionally normalizing the codepoints
would be handy too since I think that is what most usecases want.
Otherwise people would have to al
On 12/13/24 6:07 PM, Jeff Davis wrote:
OK, that's fine with me for this patch series.
Eventually though, I think we should have built-in versions of these
ASCII functions. Even if there's no actual problem, it would more
clearly indicate that we only care about ASCII at that particular call
site
From 8be52428ce8926a3d0137f5fb18e72d90871dc3f Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Mon, 18 Nov 2024 00:29:15 +0100
Subject: [PATCH v4] Add support for ON CONFLICT DO SELECT [ FOR ... ]
Adds support for DO SELECT action for ON CONFLICT clause where we
select the tuples and optionally lock the
43 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Tue, 17 Dec 2024 00:32:23 +0100
Subject: [PATCH v2 20/22] fixup! replication parser: pure parser and reentrant
scanner
Fix argument order.
---
src/backend/replication/repl_scanner.l | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
On 12/13/24 12:33 AM, Tom Lane wrote:
What I think we should do about this is to teach timestamp
input to look into the current IANA time zone to see if it
knows the given abbreviation, and if so use that meaning
regardless of what timezone_abbreviations might say. This
isn't particularly hard,
On 12/16/24 6:51 PM, Tomas Vondra wrote:
OK, pushed. Similarly to tho the other tab completion patches I
committed today, I chose not to squash the parts, even though these
changes seem to be in the same area. Seems tidier this way.
Thanks!
Personally I do not care either way. Most committers
On 12/3/24 7:24 PM, Nikita Malakhov wrote:
Please check the attached patch. I'm very interested if my assumption
is correct or not.
Hi,
You probably attached the wrong file since your patch does not even compile.
Andreas
Hi,
Here is an updated version of the patch which fixes a few small bugs,
including making sure it checks the update permission plus a bug found
by Joel Jacobsson when it was called by SPI.
Andreas
From 21ccc735d9d261278564a98d8d2d8137485cd758 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
on (e.g. we may need to update documentation for
CREATE POLICY)
References
1.
https://www.postgresql.org/message-id/CAL9smLCdV-v3KgOJX3mU19FYK82N7yzqJj2HAwWX70E%3DP98kgQ%40mail.gmail.com
Andreas
From e17121508711d9bedcc9ff4c8a3c4c8428f28607 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: M
On 11/14/24 9:59 AM, Peter Eisentraut wrote:
I'm more concerned that many of these just keep getting copied around
indiscriminately, and this is liable to hide actual type mismatches or
silently discard qualifiers. So I'm arguing in favor of a more
restrictive style in this matter.
+1 I agre
N and USING keywords.
## 0002-Complete-ON-and-USING-keywords-for-joins.patch
Adds completion of the first USING column.
Andreas
From acf9f238f34c9f72ade5a56d2a15d366993a5cfa Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Fri, 15 Nov 2024 20:05:17 +0100
Subject: [PATCH 1/3] Complete LA
On 11/4/24 7:32 PM, Tom Lane wrote:
Seems reasonable. Pushed with some trivial cosmetic adjustments
to make it look more like the identical adjacent cases for policies
and triggers.
Thanks!
Andreas
On 10/26/24 12:42 AM, Jeff Davis wrote:
On Thu, 2024-10-24 at 10:05 +0200, Andreas Karlsson wrote:
Why is there no pg_locale_builtin.c?
Just that it would be a fairly small file, but I'm fine with doing
that.
I think adding such a small file would make life easier for people new
t
p 17 00:00:00 2001
From: Andreas Karlsson
Date: Tue, 29 Oct 2024 20:23:24 +0100
Subject: [PATCH] Broken out tokeniziation of arrows
---
src/backend/parser/gram.y | 20 ++---
src/backend/parser/scan.l | 37 +++
src/fe_utils/psqlscan.l
18b39f0e79306082481c7ee304de578f5b32a6b7 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Tue, 29 Oct 2024 14:59:04 +0100
Subject: [PATCH] Make pg_dump always write rules in a stable order
Instead of sorting rules by schema and name and then finally oid in
pg_dump we sort them by schema, name and relation name
On 10/15/24 8:12 AM, Peter Eisentraut wrote:
We currently have
static PG_Locale_Strategy pg_regex_strategy;
static pg_locale_t pg_regex_locale;
static Oid pg_regex_collation;
but after the recent improvements to pg_locale_t handling, we don't need
all three anymore. All the in
On 9/27/24 12:30 AM, Jeff Davis wrote:
The attached patch series refactors the collation and ctype behavior
into method tables, and provides a way to hook the creation of a
pg_locale_t so that an extension can create any kind of method table it
wants.
Great! I had been planning to do this mysel
On 9/13/24 4:41 AM, Laurenz Albe wrote:
That's very broken and should not be allowed.
+1
A possible objection is that if anybody has such a setup and
hasn't noticed a problem because they never change their
timezone setting, they might not appreciate us breaking it.
I hope that there are fe
On 9/10/24 10:54 AM, Daniel Gustafsson wrote:
On 22 Jul 2024, at 23:25, Andreas Karlsson wrote:
I have bench marked the two patches now and failed to measure any speedup or
slowdown from the first patch (removing return) but I think it is a good idea
anyway.
For the second patch (optimize
On 9/4/24 11:45 PM, Jeff Davis wrote:
Committed v2-0001.
> [...]
I fixed this by replacing the assert with an elog(ERROR, ...), so that
it will consistently show a "cache lookup failed for collation 0"
regardless of whether it's a debug build or not. It's not expected that
the error will be e
d6223
AndreasFrom d63f681f7d0df06d493a1ec06a706f32e39e250e Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Tue, 3 Sep 2024 13:53:21 +0200
Subject: [PATCH v1] Specialize EEOP_*_TESTVAL steps
Refactor the EEOP_CASE_TESTVAL and EEOP_DOMAIN_TESTVAL steps by
deciding if we should read from caseValue_
On 9/2/24 9:06 PM, Andreas Karlsson wrote:
On 9/2/24 4:23 AM, Xing Guo wrote:
Thanks for testing it! I spotted another unnecessary store instruction
and added it in my V2 patch.
Another well-spotted unnecessary store. Nice!
I think this patch is ready for committer. It is simple and pretty
On 9/2/24 4:23 AM, Xing Guo wrote:
Thanks for testing it! I spotted another unnecessary store instruction
and added it in my V2 patch.
Another well-spotted unnecessary store. Nice!
I think this patch is ready for committer. It is simple and pretty
obviously correct.
Andreas
On 8/29/24 1:51 PM, David Rowley wrote:
I had planned to work on this for PG18, but I'd be happy for some
assistance if you're willing.
I am interested in working on this, unless Andy Fan wants to do this
work. :) I believe that optimizing the out, in and send functions would
be worth the pai
On 8/30/24 5:55 AM, Xing Guo wrote:
I find there are some unnecessary load/store instructions being
emitted by the JIT compiler.
Well spotted! All of these are obvious dead instructions and while LLVM
might be able to optimize them away there is no reason to create extra
work for the optimize
On 8/29/24 4:53 PM, Frédéric Yhuel wrote:
So I think we should just use PageGetExactFreeSpace().
I agree, I feel that is the least surprising behavior because we
currently sum tiny amounts of free space that is unusable anyway. E.g.
imagine one million pages with 10 free bytes each, that look
On 8/28/24 7:26 PM, Heikki Linnakangas wrote:
Hmm, I don't see the issue. It's an uncommon sentence structure, but it
was there before this patch, and it's correct AFAICS. If you grep for
"which see ", you'll find some more examples of that.
Not sure if it is correct or not but from some googl
ybe I
should start a new thread though.
AndreasFrom 9715b6f429907a9f284284e697727bfc7b4082e7 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Wed, 14 Aug 2024 00:52:53 +0200
Subject: [PATCH v2 5/5] Remove pg_collate_deterministic() and check field
directly
There is no clear benefit from
On 8/9/24 8:24 PM, Jeff Davis wrote:
On Fri, 2024-08-09 at 13:41 +0200, Andreas Karlsson wrote:
I am leaning towards that we should write our own pure ascii
functions
for this.
That makes sense for a lot of call sites, but it could cause breakage
if we aren't careful.
Since we d
On 8/9/24 6:59 PM, Abdoulaye Ba wrote:> The primary use case for
this hook is to allow extensions to account
for additional storage mechanisms that are not covered by the
default PostgreSQL relation size calculations. For instance, in our
project, we are working with an external i
On 8/7/24 2:08 PM, Heikki Linnakangas wrote:
The attached patches rename them to follow the usual naming convention.
The InitLocks() function is refactored a bit more, splitting the
per-backend initialization to a separate InitLockManagerAccess()
function. That's why it's in a separate commit.
propose a new naming scheme:
PG_STRATEGY_[_]
I am open for other suggestions of course like keeping the PG_LOCALE_*
prefix, but in any case I think we should make the enum labels consistent.
AndreasFrom b0a3711081b2664cf6e58ec63ac446a56cc3ff80 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date
On 8/23/24 12:02 PM, Rafia Sabih wrote:> On the other hand, this got me
thinking about the purpose of this space > information.
If we want to understand that there's still some space for the tuples in
a page, then using PageGetExactFreeSpace is not doing justice in case of
heap page, because we
On 8/22/24 10:50 AM, 陈宗志 wrote:
I disagree with the point made in the article. The article mentions
that ‘prevents the kernel from reordering reads and writes to optimize
performance,’ which might be referring to the file system’s IO
scheduling and merging. However, this can be handled within the
On 8/10/24 9:10 AM, Peter Eisentraut wrote:
Thoughts?
I like it. Not because of the security issue but mainly because it is
more correct to do it this way. Plus the old code running stat() on
Windows also made little sense.
I think this simple fix can be committed.
Andreas
9ed06366 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Wed, 14 Aug 2024 00:37:23 +0200
Subject: [PATCH 1/6] Remove lc_collate_is_c()
Instead always look up the collation and check to collate_is_c field.
TODO: Check for performance regression?
---
src/backend/access/spgist/spgtextpro
On 8/8/24 2:18 PM, Abdoulaye Ba wrote:
I am submitting a patch to add hooks for the functions
pg_total_relation_size and pg_indexes_size. These hooks allow for custom
behaviour to be injected into these functions, which can be useful for
extensions and other custom PostgreSQL modifications.
W
On 8/8/24 12:45 AM, Jeff Davis wrote:
My point was just that there are a lot of those call sites (especially
for isspace()) in various parsers. It feels like a lot of code churn to
change all of them, when a lot of them seem to be intended for ascii
anyway.
And where do we get the locale_t struc
On 7/30/24 1:31 PM, Andrey M. Borodin wrote:>> On 30 Jul 2024, at 14:57,
Tomas Vondra wrote:
How do we synchronize Shared Fake LSN with global XLogCtl->unloggedLSN? Just bump
XLogCtl->unloggedLSN if necessary?
Perhaps, consider using GetFakeLSNForUnloggedRel() instead of shared counter? As
On 7/29/24 5:00 PM, Alexander Lakhin wrote:
I also wonder whether src/test/locale/ still makes sense; does anyone
run those tests (I could not run a single one on a quick attempt)?
I was actually wondering about those yesterday and they should probably
be removed (or fixed if anyone can see a
ter committing if an additional cache of the
last locale is worth it or not.
AndreasFrom 5f634670569a3ef8249ff1747af2157b6939f505 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Sun, 28 Jul 2024 00:04:43 +0200
Subject: [PATCH] WIP: Ugly caching of last locale
---
src/backend/utils/adt/p
On 7/26/24 10:35 PM, Jeff Davis wrote:
database_ctype_is_c refers to the LC_CTYPE environment of the database
-- pg_database.datctype. default_locale.ctype_is_c is the ctype of the
database's default collation.
Confusing, I know, but it matters for a few things that still depend on
the LC_CTYPE,
Nice refactoring!
Two small comments about CheckMyDatabase().
- Shouldn't we look at the default_locale.ctype_is_c when setting
database_ctype_is_c instead of doing a strcmp()? or maybe we should even
remove the global variable and always look at the default_locale?
- I think that the lookup
On 7/22/24 2:08 PM, Andrey M. Borodin wrote:
During inserting tuples we need NSN on page. For NSN we can use just a counter,
generated by gistGetFakeLSN() which in turn will call
GetFakeLSNForUnloggedRel(). Or any other shared counter.
After inserting tuples we call log_newpage_range() to actua
On 7/24/24 10:35 PM, Tom Lane wrote:
Andreas Karlsson writes:
1) As I said earlier I think we should remove the old code.
I agree that carrying two versions of the test doesn't seem great.
However, a large part of the purpose of test_sepgsql is to help
people debug their sepgsql setup,
On 7/24/24 6:33 PM, Peter Eisentraut wrote:
On 24.07.24 16:31, Andreas Karlsson wrote:
I took a quick look at the patch and I like that we standardize things
a bit. But one thing I am not a fan of are all the use of sed and awk
in the Perl script. I would prefer if that logic happened all in
On 7/24/24 6:31 PM, Peter Eisentraut wrote:
On 24.07.24 18:29, Andreas Karlsson wrote:
Peter, what did you do to get the tests running? And should we fix
these tests to make them more user friendly?
In my experience, the tests (both the old and the proposed new) only
work on Red Hat-like
On 7/24/24 4:31 PM, Andreas Karlsson wrote:
I have not yet set up an VM with selinux to try the patch out for real
but will do so later.
I almost got the tests running but it required way too many manual steps
to just get there and I gave up after just getting segfaults. I had to
edit
I took a quick look at the patch and I like that we standardize things a
bit. But one thing I am not a fan of are all the use of sed and awk in
the Perl script. I would prefer if that logic happened all in Perl,
especially since we have some of it in Perl (e.g. chomp). Also I wonder
if we shoul
I have bench marked the two patches now and failed to measure any
speedup or slowdown from the first patch (removing return) but I think
it is a good idea anyway.
For the second patch (optimize strict) I managed to measure a ~1% speed
up for the following query "SELECT sum(x + y + 1) FROM t;"
them what you wish, for me they make to code
easier to read.
Andreas
From 9ea9a07ce6e4faf728ccc4a7b161a70a214601c8 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Thu, 18 Jul 2024 21:54:29 +0200
Subject: [PATCH] Suggested style changes
---
src/backend/executor/execExprInterp.c | 9 +++
On 6/20/24 5:22 PM, Andreas Karlsson wrote:
On 10/12/23 11:48 AM, Daniel Gustafsson wrote:
Thoughts?
I have looked at the patch and it still applies, builds and passes the
test cases and I personally think these optimizations are pretty much
no-brainers that we should do and it is a pity
On 10/12/23 11:48 AM, Daniel Gustafsson wrote:
Thoughts?
I have looked at the patch and it still applies, builds and passes the
test cases and I personally think these optimizations are pretty much
no-brainers that we should do and it is a pity nobody has had the time
to review this patch.
helpful.
See the attached patch.
AndreasFrom e3b55e00aee578a46298447463e0984aa3a230f7 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Wed, 5 Jun 2024 10:13:23 +0200
Subject: [PATCH] Move resowner from common JitContext to LLVM specific
Only the LLVM specific code uses it since resource owners
On 5/4/24 10:16 PM, Tom Lane wrote:
This fixes bug #18456 [1]. Since we're in back-branch release freeze,
I'll just park it for the moment. But I think we should shove it in
once the freeze lifts so it's in 17beta1.
There is a similar issue with the return type (at least if it is a
generic rec
On 3/13/24 12:41 PM, Andreas Karlsson wrote:
On 2/8/24 8:58 AM, Peter Eisentraut wrote:
I think keeping the two build systems aligned this way will be useful
for longer-term maintenance.
Agreed, so started reviewing the patch. Attached is a rebased version of
the patch to solve a conflict
On 2/8/24 8:58 AM, Peter Eisentraut wrote:
I think keeping the two build systems aligned this way will be useful
for longer-term maintenance.
Agreed, so started reviewing the patch. Attached is a rebased version of
the patch to solve a conflict.
AndreasFrom 2069c6d6e2ef2bc37c5af0df12c558ead8
On 3/12/23 09:17, Ankit Kumar Pandey wrote:
Attaching updated patch with a fix for an issue in window function.
I have also fixed naming convention of patch as last patch had
incompatible name.
Hi,
This patch does not apply to master. Could you rebase it and submit it
as one patch which app
On 6/29/23 11:13, Thom Brown wrote:
I get the feeling that this is deliberate, and perhaps an attempt to
mitigate locking issues, or some other explanation, but the rationale
isn't immediately apparent to me if this is the case.
I have always assumed the reason is that there might be other
tra
On 6/14/23 09:01, Kyotaro Horiguchi wrote:
At Wed, 14 Jun 2023 08:46:05 +0300, Konstantin Knizhnik
wrote in
But I do not think that it is somehow related with using threads
instead of process.
The question whether to use private or shared cache is not directly
related to threads vs. process ch
On 6/13/23 10:20, Konstantin Knizhnik wrote:
The fact that it is flushed out upon reconnection can not
help much: what if backends are not going to disconnect?
This is why many connection pools have a maximum connection lifetime
which can be configured. So in practice flushing all caches on
d
On 2/10/23 02:22, Jeff Davis wrote:
We will still allow the ICU format locale IDs for input; we would just
convert them to BCP47 before storing them in the catalog. And there's
an inverse function, so it's easy enough to offer a view that shows the
ICU format locale IDs in addition to the BCP 47
On 2/9/23 23:09, Jeff Davis wrote:
I do like the ICU format locale IDs from a readability standpoint.
"en_US@colstrength=primary" is more meaningful to me than "en-US-u-ks-
level1" (the equivalent language tag). And the format is specified[1],
even though it's not an independent standard. But I t
On 1/3/23 22:16, Thomas Munro wrote:
On Wed, Jan 4, 2023 at 10:07 AM Andreas Karlsson wrote:
Another thing: shouldn't we set some wait event to indicate that we are
waiting the RADIUS server or is that pointless during authentication
since there are no queries running anyway?
I init
On 1/3/23 22:03, Andreas Karlsson wrote:
On 1/3/23 04:11, Thomas Munro wrote:
Here's a draft patch to tackle a couple of TODOs in the RADIUS code in
auth.c.
Nice to see someone working on this!.
Another thing: shouldn't we set some wait event to indicate that we are
waiting
On 1/3/23 04:11, Thomas Munro wrote:
Here's a draft patch to tackle a couple of TODOs in the RADIUS code in auth.c.
Nice to see someone working on this! I know of one company which could
have used the configurable timeout for radius because the 3 second
timeout is too short for 2FA. I think t
On 2/21/22 13:09, Euler Taveira wrote:
DESIGN
The conversion requires 8 steps.
1. Check if the target data directory has the same system identifier
than the
source data directory.
2. Stop the target server if it is running as a standby server. (Modify
recovery parameters requires a restart.)
On 2/7/22 11:26, Frédéric Yhuel wrote:
Attached is a (naive) patch that aims to fix the case of a FK addition,
but the handling of the flag CURSOR_OPT_PARALLEL_OK, generally speaking,
looks rather hackish.
Thanks, for the patch. You can add it to the current open commitfest
(https://commitfes
On 1/19/22 09:30, Peter Eisentraut wrote:
So, first of all, would people agree with this course of action?
I don't have a lot of experience with this module, so I don't know if
there are any lingering concerns about whether it is mature enough as a
built-in feature.
While it I like the idea
On 10/21/21 5:55 PM, Matthias van de Meent wrote:
On Sat, 2 Oct 2021 at 17:05, Tom Lane wrote:
Andres Freund writes:
It's not like this forces you to use cirrus or anything. For people that don't
want to use CI, It'll make cfbot a bit more effective (because people can
adjust what it tests a
On 10/2/21 5:48 AM, Daniel Fone wrote:
I don’t get these compiler warnings and I can’t find any settings to use that
might generate them. I’m compiling on macOS 11.6 configured with
`--enable-cassert --enable-depend --enable-debug CFLAGS=-O0`
I’ve optimistically updated the patch to hopefully
On 9/28/21 11:58 PM, Daniel Fone wrote:
On 29/09/2021, at 2:33 AM, Daniel Gustafsson wrote:
I don't see why not, the best first patches are those scratching an itch. If
you feel up for it then give it a go, I - and the rest of pgsql-hackers - can
help if you need to bounce ideas.
I’m glad you
On 9/15/21 1:40 PM, Tom Lane wrote:
Marcos Pegoraro writes:
Alphabetical order of triggers sometimes makes me write a_Recalc or z_Calc
to be sure it´ll be the first or the last trigger with same event of that
table
Oracle and SQL Server have FOLLOWS and PRECEDES when defining trigger
executi
On 8/10/21 10:27 AM, 孙诗浩(思才) wrote:
Before send patch review, I want to konw whether the postgres maintainer
will approve my changes.
So, please give me some advice.
Welcome!
I do not think that is a feature which will get much interest from the
developers since it is unclear to me what the
reas
>From 63158a51add9cbd43ca7d5d6219cd6127657f25f Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Sun, 30 May 2021 15:11:35 +0200
Subject: [PATCH] Shrink GISTSTATE
---
src/backend/access/gist/gist.c | 58 ++---
src/backend/access/gist/gistscan.c | 4 +-
src/backend/access/gist/gis
On 3/7/21 1:08 AM, Joel Jacobson wrote:
Attached is a suggestion of adding a convenience view,
allowing quickly looking up all objects owned by a given user.
This definitely seems like a useful feature. I know I am guilty of
creating tables as the wrong role more than one time.
Andreas
On 3/4/21 4:40 PM, Tom Lane wrote:
I wonder if a 2-D integer array wouldn't be a better idea,
ie {{startpos1,length1},{startpos2,length2},...}. My experience
with working with parallel arrays in SQL has been unpleasant.
Hm, I can see your point but on the other hand I can't say my
experiences
On 1/22/21 2:19 PM, Darafei "Komяpa" Praliaskouski wrote:
Having row count right away is very useful in CTAS in analytical and GIS
usage scenarios.
I can see that, but would it not work if it was:
CREATE TABLE AS 1
Disclaimer: I have not looked at the code so maybe there is some good
reason
1 - 100 of 238 matches
Mail list logo
