Hi Laurenz,
> On 14 Apr 2025, at 19:36, Laurenz Albe wrote:
>
> You cannot "bake in into" PostgreSQL, but you can grab the ICU source,
> install it in /usr/local or similar and build PostgreSQL against that.
> You will have to fiddle with CFLAGS and LDFLAGS so that the build process
> uses the C
Hi Tom, hi Laurenz
> On 14 Apr 2025, at 16:36, Tom Lane wrote:
>
> Laurenz Albe writes:
>> You would have to build PostgreSQL yourself with a fixed version of ICU
>> that you never upgrade if you want to avoid the problem.
[...]
> 2. It's at least *possible* to use your own fixed-version ICU
>
Hi Ron,
> On 12 Mar 2025, at 17:59, Ron Johnson wrote:
>
> Developers making DDL changes on production databases?
Of course not. But I can't block developer databases. That'd make a few hundred
developers happy.
> Or are there prod and dev databases on the same instance? If so, then know
>
Hi Joe,
> On 13 Mar 2025, at 03:55, Joe Conway wrote:
>
> If you are desperate you could start with
> https://github.com/awslabs/compat-collation-for-glibc and create a new branch
> for your current version of SLES/glibc and deploy the resulting rpm to RHEL.
> At least in theory. FWIW I was a
Hi Adrian,
> On 12 Mar 2025, at 22:37, Adrian Klaver wrote:
>
> What version of RH are you migrating to?
That'd be currently Red Hat 9 with glibc 2.34.
Cheers,
Paul
Hi Greg,
> On 12 Mar 2025, at 21:31, Greg Sabino Mullane wrote:
>
> Keep in mind that you only need to reindex text-based indexes. Ints are still
> gonna int. So it might not be too bad.
Yes, I know, but unfortunately the worst case index of them all will still take
a few hours.
Cheers,
Paul
Hi Ron,
> On 12 Mar 2025, at 21:50, Ron Johnson wrote:
>
> No, I think it's 100% on point: logically replicate the Prod databases, while
> pg_dump/pg_restore of the dev and pre-prod databases happen on weekends.
Yes, I live for and in the company. 🤣 SNCR.
No, seriously, I'm one of only two Po
Hi Adrian,
> On 12 Mar 2025, at 21:26, Adrian Klaver wrote:
>
> A good summary of the glibc issue:
>
> https://wiki.postgresql.org/wiki/Locale_data_changes
>
> With distro information:
>
> https://wiki.postgresql.org/wiki/Locale_data_changes#What_Linux_distributions_are_affected
I know the a
Hi Christophe,
> On 12 Mar 2025, at 12:16, Christophe Pettus wrote:
>
> You *can* apply DDL while logical replication is going on, as long as you do
> so in a disciplined way. This generally means applying it to the subscriber
> before you apply it to the publisher, and making sure that any c
Hi Ron,
> On 11 Mar 2025, at 20:34, Ron Johnson wrote:
>
> If you don't do much DDL, the LR should be quite workable.
DDL during logical replication unfortunately is a show-stopper.
Cheers,
Paul
Hi Devrim, Thomas, Adrian, Ron, Joe,
answering to myself as answering to five postings in one go is impossible. 🤣
> Are there any obstacles that definitely make that a no-go? Do I risk
> corruption? It's both Linux, just a different distribution.
The question was a bit of an idea. So the glibc
Hi,
we are considering changing the PostgreSQL platform from SUSE SLE to Red Hat.
To keep service interruptions as short as possible, the idea is to set up a
streaming replication from the SUSE server to be replaced to a temporary Red
Hat server and then replace that SUSE server with the newly
Hi Adrian,
> On 13 Feb 2025, at 19:05, Adrian Klaver wrote:
>
> Then run pg_restore -s -f db_name.sql against whatever is the dump file
> produced by pg_dump -Fc -Z1 ...
>
> It will create a plain text version of the schema definitions, no data in the
> file db_name.sql. Then you can see if G
Hi Adrian,
> On 13 Feb 2025, at 17:40, Adrian Klaver wrote:
>
> Per:
>
> https://www.postgresql.org/docs/current/ddl-priv.html
>
> "If the “Access privileges” column is empty for a given object, it means the
> object has default privileges (that is, its privileges entry in the relevant
> sys
Hi Adrian,
sorry for the late answer. I'm just too busy.
> On 7 Feb 2025, at 17:19, Adrian Klaver wrote:
>
>> With create database being "template template0", this is what my
>> script does. But I need the -cC options for pg_restore to get ACLs back.
>> Leaving out either one of them will no
Hi Daniel,
> On 7 Feb 2025, at 14:29, Daniel Verite wrote:
>
> Still, you may check it with pg_amcheck [1] or try rebuilding it
> just in case.
Thanks. I guess this is good advice. I will try that on Monday.
Cheers,
Paul
Hi Adrian,
> On 6 Feb 2025, at 19:44, Adrian Klaver wrote:
>
> By ACL do you mean roles?
>
> If so roles are global to the cluster not the database, so I am not seeing -C
> being relevant.
>
> If not you will need to be more specific about what you are referring to.
I did a "pg_dumpall -r >r
Hi Adrian,
> On 6 Feb 2025, at 17:31, Adrian Klaver wrote:
>
> 1) Log into postgres database and do:
>
> a) DROP DATABASE mydb;
> b) CREATE DATABASE mydb ;
>
> 2) pg_restore -d mydb mydb.dump.gz
With create database being "template template0", this is what my
script does. But I need the -cC
Hi Guillaume,
> On 6 Feb 2025, at 15:51, Guillaume Lelarge
> wrote:
>
> You're right. Now I see the "create database" query in your previous email. I
> should have been more careful, sorry for the noise.
No problem.
> Well, the doc says that --disable-triggers is only relevant for data-only
Hi Guillaume,
> On 6 Feb 2025, at 11:13, Guillaume Lelarge
> wrote:
>
> You probably don't need --disable-triggers. You should fix errors in the
> order they appear. The first one is on the drop of the database:
>
> ERROR: cannot drop the currently open database
>
> pg_restore can't drop th
Hi,
I have a problem which I don't understand. I have and do:
instance a, libc based, PostgreSQL 15.10:
mydb=# \l mydb
List of databases
Name | Owner | Encoding | Collate |Ctype| ICU Locale | Locale
Provider | Access priv
Hi Alvaro,
> On 30 Nov 2024, at 08:41, Alvaro Herrera wrote:
>
> Only if you have self-referencing FKs in partitioned tables. It
> would be an interesting data point to verify whether this reports
> anything else. Also, I'd be really curious if your databases include
> the case I'm suspicious
Hi Alvaro,
> On 29 Nov 2024, at 18:15, Alvaro Herrera wrote:
>
> This all was to say that the query in the release notes is undoubtedly
> wrong. After thinking some more about it, I think the fix is to add 1
> to the number of constraints:
>
> SELECT conrelid::pg_catalog.regclass AS "constrain
Hi Tom, hi Alvaro,
> On 27 Nov 2024, at 19:52, Tom Lane wrote:
>
> Okay, so I was able to reproduce this from scratch on HEAD:
great, thanks.
> I doubt that there's anything actually wrong with the catalog state at
> this point (perhaps Alvaro would confirm that). That leads to the
> conclusi
Hi Tom,
> On 26 Nov 2024, at 22:25, Tom Lane wrote:
>
> I would have expected an empty result too. Can you confirm that
> p_ci_pipelines used to be a partition of something? Can you show us
> the full DDL (or psql \d+ output) for the partitioned table it
> used to be part of, and for that matt
Hi Adrian,
> On 26 Nov 2024, at 17:56, Adrian Klaver wrote:
>
> Did you commit the statements?
Yes. I have autocommit on, the psql default.
> Are you using concurrent sessions to do this?
No. I do this in one session. 1. select, 2. drop, 3. add, 4. select.
> When you run the query again do y
Hi,
> [postgres@post1 bin]$ ./repmgr -f /var/lib/pgsql/repmgr.conf primary register
> ERROR: following errors were found in the configuration file:
> syntax error in file "/var/lib/pgsql/repmgr.conf" line 3, near token
> "data_directory"
> syntax error in file "/var/lib/pgsql/repmgr.conf" lin
Hi,
I have a question regarding the recent security update for PostgreSQL 15.
We have a gitlab database. It used to run on the PostgreSQL 15.8 software. I
updated from 15.8 to 15.10 and executed the corrective actions as outlined in:
https://www.postgresql.org/about/news/postgresql-171-165-159-
Hi,
the PostgreSQL 15.9 release notes instruct to look out for especially detached
partitions with foreign key constraints. I'm in the process of updating our
databases from 15.8 to 15.9 now and found a case where the select statement
returns a constraint.
The release notes say nothing about w
Hi Alvaro,
> On 19 Nov 2024, at 17:34, Alvaro Herrera wrote:
>
> It doesn't really matter when you do it, because the constraint only
> gets broken by running DETACH with the old server code. You have
> already run the DETACH sometime in the past (that's how the constraint
> got broken), which
Hi Adrian,
> On 19 Nov 2024, at 17:17, Adrian Klaver wrote:
>
> Read this:
>
> https://www.postgresql.org/about/news/out-of-cycle-release-scheduled-for-november-21-2024-2958/
>
> and hold off awhile.
Thanks very much. I will.
Cheers,
Paul
Hi Tom,
> On 19 Nov 2024, at 17:25, Tom Lane wrote:
>
> Generally speaking, our release notes are addressed to someone who's
> already installed the update (or a later one).
Thank you for the advice.
Cheers,
Paul
Hi Adrian,
> On 22 Sep 2024, at 18:53, Adrian Klaver wrote:
>
> https://www.postgresql.org/docs/17/release-17.html#RELEASE-17-HIGHLIGHTS
>
> Add a builtin platform-independent collation provider (Jeff Davis)
>
> This supports C and C.UTF-8 collations.
I must admit that I haven't read the read
Hi Peter,
> On 21 Sep 2024, at 00:33, Peter J. Holzer wrote:
>
> I don't use SLES but I would expect it to have an RPM for it.
>
> If you have any test machine which you can upgrade before the production
> servers (and given the amount of data and availability requirements you
> have, I really
Hi Joe,
> On 19 Sep 2024, at 20:09, Joe Conway wrote:
>
> See my thread-adjacent email, but suffice to say that if there are collation
> differences that do affect your tables/data, and you allow any inserts or
> updates, you may wind up with corrupted data (e.g. duplicate data in your
> othe
Hi Peter,
> On 19 Sep 2024, at 19:43, Peter J. Holzer wrote:
>
> I wrote a small script[1] which prints all unicode code points and a few
> selected[2] longer strings in order. If you run that before and after
> the upgrade and the output doesn't change, you are probably be fine.
> (It checks on
Hi Joe,
> On 19 Sep 2024, at 19:07, Joe Conway wrote:
>
> Every glibc major version change potentially impacts the sorting of some
> strings, which would require reindexing. Whether your actual data trips into
> any of these changes is another matter.
>
> You could check by doing something eq
Hi Tom,
> On 19 Sep 2024, at 17:14, Tom Lane wrote:
>
> No, I wouldn't expect that to be necessary.
I was hoping one of the pros would say that. 🤣
> Maybe. We don't really track glibc changes, so I can't say for sure,
> but it might be advisable to reindex indexes on string columns.
Advisabl
Hi Adrian,
> On 19 Sep 2024, at 17:00, Adrian Klaver wrote:
>
> I would take a look at:
>
> https://wiki.postgresql.org/wiki/Locale_data_changes
>
> It refers to the glibc 2.8 change in particular, but includes some generic
> tips that could prove useful.
>
>
> The glibc change log below mi
Hi,
we have SLES 15.5 which has glibc 2.31. Our admin told us that he's about to
install the SLES 15.6 update which contains glibc 2.38.
I have built our PostgreSQL software from source on SLES 15.5, because we have
some special requirements which the packages cannot fulfill. So I have
questio
Hi Sonam,
On Tue, Mar 17, 2020 at 11:30 AM Sonam Sharma wrote:
>
> I have setup replication using repmgr. Wanted to know how much time the slave
> node will take to become new primary ?? If any document, can someone please
> share of auto failover. With automatic failover, how much time the sl
Hi,
an underscore matches a single character, any character. You'd have to
escape it and tell the query what the escape character is if you want
it to be treated as a standard character:
db=# create table t(t text);
CREATE TABLE
db=# insert into t(t) values ('fox'), ('fo_'), ('fo_x');
INSERT 0 3
Hi,
I think "create database" always creates the "public" schema. So, all
is well. All you have to do is drop it after running the dump.sql
script.
Cheers,
Paul
On Wed, Mar 4, 2020 at 2:43 PM Олег Самойлов wrote:
>
> Hi all. PostgresQL 12.1. Strange behaviour with pg_dump and absent public
> s
43 matches
Mail list logo
