On 5/8/23 22:07, Laurenz Albe wrote:
Yes, that is safe.
But it is not compatible with the old setup when it comes to lc_time,
lc_messages and the others. You should use sv_SE.UTF-8 for these
locale categories.
Note that that won't cause problems with upgrading the C library.
Yours,
Laurenz A
On Tue, May 9, 2023 at 3:15 AM Michael Paquier wrote:
>
> On Mon, May 08, 2023 at 07:15:20PM +0530, Dilip Kumar wrote:
> > I am able to reproduce this using the steps given above, I am also
> > trying to analyze this further. I will send the update once I get
> > some clue.
>
> Have you been able
Hi,
On 2023-05-08 17:46:37 -0700, Andres Freund wrote:
> My current gut feeling is that we should use datconnlimit == -2 to prevent
> connections after reaching DropDatabaseBuffers() in dropdb(), and use a new
> column in 16, for both createdb() and dropdb().
Attached is a rough prototype of that
Hi,
On 2023-05-08 14:04:00 -0700, Andres Freund wrote:
> But perhaps a similar approach could be the solution? My gut says that the
> rought direction might allow us to keep dropdb() a single transaction.
I started to hack on the basic approach of committing after the catalog
changes. But then I
On Mon, May 08, 2023 at 06:04:23PM -0400, Tom Lane wrote:
> Andres seems to think it's a problem with aborting a DROP DATABASE.
> Adding more data might serve to make the window wider, perhaps.
And the odds get indeed much better once I use these two toys:
CREATE OR REPLACE FUNCTION create_tables(
On Tue, May 9, 2023 at 10:04 AM Tom Lane wrote:
> Michael Paquier writes:
> > One thing I was wondering about to improve the odds of the hits is to
> > be more aggressive with the number of relations created at once, so as
> > we are much more aggressive with the number of pages extended in
> > p
Michael Paquier writes:
> One thing I was wondering about to improve the odds of the hits is to
> be more aggressive with the number of relations created at once, so as
> we are much more aggressive with the number of pages extended in
> pg_class from the origin database.
Andres seems to think it
On Mon, May 08, 2023 at 07:15:20PM +0530, Dilip Kumar wrote:
> I am able to reproduce this using the steps given above, I am also
> trying to analyze this further. I will send the update once I get
> some clue.
Have you been able to reproduce this on HEAD or at the top of
REL_15_STABLE, or is tha
Hi,
On 2023-05-08 20:27:14 +, Evgeny Morozov wrote:
> On 8/05/2023 9:47 pm, Andres Freund wrote:
> > Did you have any occasions where CREATE or DROP DATABASE was interrupted?
> > Either due the connection being terminated or a crash?
>
> I've uploaded an edited version of the PG log for the ti
On 8/05/2023 9:47 pm, Andres Freund wrote:
> Did you have any occasions where CREATE or DROP DATABASE was interrupted?
> Either due the connection being terminated or a crash?
I've uploaded an edited version of the PG log for the time as
https://objective.realityexists.net/temp/log-extract-2023-05
On Mon, 2023-05-08 at 16:35 +0200, Oscar Carlberg wrote:
> We have a bunch of existing Postgres 10 clusters running on CentOS 7,
> which have been initialized (initdb) with these collation options;
>
> -E 'UTF-8'
> --lc-collate=sv_SE.UTF-8
> --lc-ctype=sv_SE.UTF-8
> --lc_monetary=sv_SE.UTF-8
> --
Hi,
On 2023-05-07 16:10:28 +, Evgeny Morozov wrote:
> Yes, kind of. We have a test suite that creates one test DB and runs a
> bunch of tests on it. Two of these tests, however, create another DB
> each (also by cloning the same template DB) in order to test copying
> data between DBs. It's on
Alvaro Herrera writes:
> Maybe it would be sensible to make STRATEGY_FILE=FILE_COPY the default
> again, for branch 15, before today's release.
If we had more than one such report, I'd be in favor of that.
But I think it's a bit premature to conclude that the copy
strategy is to blame.
Hello,
We have a bunch of existing Postgres 10 clusters running on CentOS 7,
which have been initialized (initdb) with these collation options;
-E 'UTF-8'
--lc-collate=sv_SE.UTF-8
--lc-ctype=sv_SE.UTF-8
--lc_monetary=sv_SE.UTF-8
--lc-numeric=sv_SE.UTF-8
--lc-time=sv_SE.UTF-8
--lc-messages=en_U
On Mon, May 8, 2023 at 7:55 AM Michael Paquier wrote:
>
> On Sun, May 07, 2023 at 10:30:52PM +1200, Thomas Munro wrote:
> > Bug-in-PostgreSQL explanations could include that we forgot it was
> > dirty, or some backend wrote it out to the wrong file; but if we were
> > forgetting something like per
Kent Tong writes:
> I have a complex query involving over 15 joins and a CTE query and it takes
> over 17s to complete.
If you want constructive comments about that, you're going to need to show
us the whole thing (and the underlying tables' schemas). Little bits in
isolation are not very intell
On 5/8/23 07:29, Kent Tong wrote:
Hi,
I have a complex query involving over 15 joins and a CTE query and it
takes over 17s to complete. The output of EXPLAIN ANALYZE includes
(somewhere deep inside):
Index Scan using document_pkey on document document0_
(cost=0.29..8.31 rows=1 width
On 5/8/23 05:24, Age Apache wrote:
I am designing a database for a web application. In the near future I will
require past data for Audit, Security and Analysis purpose. But storing
all that data will increase the database size. What are some well known
approaches to archiving data for later us
Hi,
I have a complex query involving over 15 joins and a CTE query and it takes
over 17s to complete. The output of EXPLAIN ANALYZE includes (somewhere
deep inside):
Index Scan using document_pkey on document document0_ (cost=0.29..8.31
rows=1 width=3027) (actual time=16243.959..16243.961 rows=1
Consider table partitioning. You can detach, save and delete partitions, and
you can restore and attach partitions.
On 8 May 2023 12:24:06 CEST, Age Apache wrote:
>I am designing a database for a web application. In the near future I will
>require past data for Audit, Security and Analysis purpo
I am designing a database for a web application. In the near future I will
require past data for Audit, Security and Analysis purpose. But storing all
that data will increase the database size. What are some well known
approaches to archiving data for later use without increasing the database
size?
On 2023-May-07, Thomas Munro wrote:
> Did you previously run this same workload on versions < 15 and never
> see any problem? 15 gained a new feature CREATE DATABASE ...
> STRATEGY=WAL_LOG, which is also the default. I wonder if there is a
> bug somewhere near that, though I have no specific ide
On 8/05/2023 4:24 am, Michael Paquier wrote:
> here are the four things running in parallel so as I can get a failure
> in loading a critical index when connecting
Wow, that is some amazing detective work! We do indeed create tables
during our tests, specifically partitions of tables copied from t
Okay - that worked.
How did you know that would work? That's incredible.
On Sun, May 7, 2023 at 4:25 PM Tom Lane wrote:
> "Michael P. McDonnell" writes:
> > I have 2 stored procedures that need to run back to back. It could
> > convert to a single one - but it's easier from a maintenance perspe
24 matches
Mail list logo
