On Mon, Feb 24, 2025 at 5:50 PM Yongye Serkfem wrote:
> Hi Everyone!
> I am having a series of idle connections and unable to delete them with a
> single command. Any help in realizing this would be greatly appreciated.
>
This will kill idle connections older than two hours:
select pid, pg_termi
On Mon, Feb 24, 2025 at 3:50 PM Yongye Serkfem wrote:
>
> I am having a series of idle connections and unable to delete them with a
> single command. Any help in realizing this would be greatly appreciated.
>
>
"deleting" really isn't the word used to describe this, terminate, kill, or
disconnect
Hi Everyone!
I am having a series of idle connections and unable to delete them with a
single command. Any help in realizing this would be greatly appreciated.
Regards
Yong
Jeremy Schneider writes:
> Is there a page somewhere on the postgres wiki with a simple high-level
> explanation of what the https://postgr.es/m/MESSAGE_ID URL format is
> and how to construct one of these URLs?
> For example, can this be used for all postgres mailing lists or only
> certain lists
On Mon, Feb 24, 2025 at 11:56:20AM -0800, Jeremy Schneider wrote:
> Hello,
>
> Is there a page somewhere on the postgres wiki with a simple high-level
> explanation of what the https://postgr.es/m/MESSAGE_ID URL format is
> and how to construct one of these URLs?
>
> For example, can this be used
Hello,
Is there a page somewhere on the postgres wiki with a simple high-level
explanation of what the https://postgr.es/m/MESSAGE_ID URL format is
and how to construct one of these URLs?
For example, can this be used for all postgres mailing lists or only
certain lists (like hackers)?
It's prob
On Mon, Feb 24, 2025 at 11:50 AM Dominique Devienne
wrote:
> We lookup whether there's a list of aliases for "Allison". If there are,
> we send them in $3 as an array
of string (e.g. ['All', 'Alli', ...], and the first one matching (thanks to
> order by ord limit 1) is returned, if any.
>
Thank
On 2/24/25 05:57, Schmid Andreas wrote:
-Ursprüngliche Nachricht-
I think that lives here:
https://salsa.debian.org/postgresql/postgresql-common
Yes, thanks for the hint. The commit which apparently introduced the change is
https://salsa.debian.org/postgresql/postgresql-common/-/commit
Matthias Apitz wrote:
> Thanks. I did \l before which gives:
>
> List of databases
>Name| Owner | Encoding | Collate |Ctype| ICU Locale
> | Locale Provider | Access privileges
> +--+--+--
On Mon, Feb 24, 2025 at 5:39 PM Greg Sabino Mullane
wrote:
> On Mon, Feb 24, 2025 at 4:46 AM Dominique Devienne
> wrote:
>
>> But now we have a new requirement, for "fuzzy find". I.e. the client can
>> ask for names
>> which are not the exact in-DB names, but also aliases of those names.
>>
> ..
On Mon, Feb 24, 2025 at 9:37 AM Adrian Klaver
wrote:
> On 2/24/25 03:50, Laurenz Albe wrote:
> > On Mon, 2025-02-24 at 20:56 +1300, Marcelo Fernandes wrote:
> >> I am experiencing an interesting behavior in PostgreSQL and would like
> to seek
> >> some clarification.
>
>
> >>
> >> Can anyone expl
On Mon, Feb 24, 2025 at 4:46 AM Dominique Devienne
wrote:
> But now we have a new requirement, for "fuzzy find". I.e. the client can
> ask for names
> which are not the exact in-DB names, but also aliases of those names.
>
...
> join unnest($3::text[]) with ordinality as aliases(name, ord) on c.
On 2/24/25 03:50, Laurenz Albe wrote:
On Mon, 2025-02-24 at 20:56 +1300, Marcelo Fernandes wrote:
I am experiencing an interesting behavior in PostgreSQL and would like to seek
some clarification.
Can anyone explain how PostgreSQL "knows about" the default value that has just
been dropped a
On 2/23/25 23:56, Marcelo Fernandes wrote:
Hi folks,
I am experiencing an interesting behavior in PostgreSQL and would like to seek
some clarification.
In the following snippet, I first add a column with a default value, then drop
that default. However, when I query the table, the column still
On Mon, Feb 24, 2025 at 3:51 PM Rob Sargent wrote:
> API:
> > * The first type never relies on fuzzy-find.
>
> Then have that app type use the simple, fast query.
>
I'm sorry, but that's neither helpful, nor relevant. --DD
On Mon, 2025-02-24 at 13:07 +0100, Matthias Apitz wrote:
> Thanks. I did \l before which gives:
>
> List of databases
> Name | Owner | Encoding | Collate | Ctype | ICU Locale |
> Locale Provider | Access privileges
>
Dominique Devienne writes:
> But during those "restore" transactions, I must also make role-to-role
> grants,
> which AFAIK involve adding rows to pg_auth_members. So they are not subject
> to the same "no support for concurrent updates in the catalog-manipulation"
> you mentioned, as schema-to-ro
On Mon, Feb 24, 2025 at 6:53 AM Matthias Apitz
wrote:
[snip]
> pgsql -Usisis sisis
>
> sisis=# REINDEX (VERBOSE) DATABASE sisis;
> sisis=# ALTER COLLATION "de_DE.utf8" REFRESH VERSION;
> ALTER COLLATION
>
> Correct?
>
>
Just reindex those with text columns.
create or replace view dba.all_indices
API:
> * The first type never relies on fuzzy-find.
Then have that app type use the simple, fast query. After all each app/code is
making an explicit choice which yesterday was the same and tomorrow will be
different.
> -Ursprüngliche Nachricht-
> I think that lives here:
> https://salsa.debian.org/postgresql/postgresql-common
Yes, thanks for the hint. The commit which apparently introduced the change is
https://salsa.debian.org/postgresql/postgresql-common/-/commit/d9139fa42a39b5b6fabbffc9f020fad4
Thanks. I did \l before which gives:
List of databases
Name| Owner | Encoding | Collate |Ctype| ICU Locale
| Locale Provider | Access privileges
+--+--+-+-++--
On Mon, Feb 24, 2025 at 12:33 PM Matthias Apitz
wrote:
> Thanks for your hint, Jeremy. But this does not work either:
>
> postgres=# SELECT collname, collversion FROM pg_collation where collname =
> 'de_DE.utf8';
> collname | collversion
> +-
> de_DE.utf8 | 2.38
> (1 r
On Mon, 2025-02-24 at 12:53 +0100, Matthias Apitz wrote:
> If I understand the other reply from Laurenz Albe right, the correct
> procedure would be:
>
> pgsql -Usisis sisis
> sisis=# REINDEX (VERBOSE) DATABASE sisis;
> sisis=# ALTER COLLATION "de_DE.utf8" REFRESH VERSION;
> ALTER COLLATION
>
>
Thanks. I tried a lot of combinations. Based on the output of \l
List of databases
Name| Owner | Encoding | Collate |Ctype| ICU Locale
| Locale Provider | Access privileges
+--+--+-+-
On Mon, 2025-02-24 at 20:56 +1300, Marcelo Fernandes wrote:
> I am experiencing an interesting behavior in PostgreSQL and would like to seek
> some clarification.
>
> In the following snippet, I first add a column with a default value, then drop
> that default. However, when I query the table, the
On Mon, 2025-02-24 at 02:32 -0800, Jeremy Schneider wrote:
> On Mon, 24 Feb 2025 11:08:43 +0100
> Matthias Apitz wrote:
> > What is the procedure on 13.1 to bring the external (glibc) version
> > in sync with. the used version in the PostgreSQL database?
>
> If I recall correctly, between version
Thanks for your hint, Jeremy. But this does not work either:
postgres=# SELECT collname, collversion FROM pg_collation where collname =
'de_DE.utf8';
collname | collversion
+-
de_DE.utf8 | 2.38
(1 row)
postgres=# ALTER COLLATION de_DE.utf8 REFRESH VERSION;
ERROR: sche
On Mon, 24 Feb 2025 11:08:43 +0100
Matthias Apitz wrote:
>
> What is the procedure on 13.1 to bring the external (glibc) version
> in sync with. the used version in the PostgreSQL database?
If I recall correctly, between versions 10 and 14 you need to use ALTER
COLLATION name REFRESH VERSION on
Hello,
When the Linux OS is updated, for example from SLES 15 SP5 to SP6, the
version of the glibc is sometimes updated, for example from 2.31 to 2.38.
For existing databases this gives on SQL a warning as:
user@rechner: $SC_SQL -Usisis sisis
WARNING: database "sisis" has a collation version mis
Hi,
We have a few dozen queries involving grandparent, parent, child table
triplets,
to implement a pre-existing API on top of PostgreSQL. That API is not
SQL-based
nor SQL "friendly" either, that's why we detect patterns in the APIs
inputs, to use
different SQL queries, as (important) optimizatio
On Thu, Feb 20, 2025 at 4:27 PM Tom Lane wrote:
> Dominique Devienne writes:
> > Error: DDL Error: GRANT USAGE ON SCHEMA "SCH1", "SCH2" TO "SCH2:RO",
> > "SCH2:RW", "SCH2:SU": #XX000: ERROR: tuple concurrently updated
>
> Since both restores tried to grant some permissions on SCH1, they
> both
31 matches
Mail list logo
