On Fri, Jun 15, 2018 at 08:54:52 +0200,
Laurenz Albe wrote:
Absolutely, but it should be easy to run a few tests with only a single row
insert that confirms your theory.
Thanks.
On Fri, Jun 15, 2018 at 08:54:52 +0200,
Laurenz Albe wrote:
Bruno Wolff III wrote:
I think I know what is happening, but I wanted to see if my understanding
is correct.
I have a perl after insert trigger for a table with a non-null column element
and I am getting an occasional error when
On Thu, Jun 14, 2018 at 23:04:24 -0500,
Bruno Wolff III wrote:
I have a perl after insert trigger for a table with a non-null column
element and I am getting an occasional error when the trigger executes
for printing a null value which is $TD->{new}{element}. However, I do
the ins
I think I know what is happening, but I wanted to see if my understanding
is correct.
I have a perl after insert trigger for a table with a non-null column element
and I am getting an occasional error when the trigger executes for
printing a null value which is $TD->{new}{element}. However, I
On Tue, Oct 23, 2018 at 20:23:14 -0500,
Bruno Wolff III wrote:
While reloading a database cluster to move from 10.5 to 11, I'm
getting out of memory crashes that I did see when doing reloads on pg
10.
The statement flagged in the log is this:
2018-10-23 16:44:34.815 CDT [126839] STATEMENT
On Fri, Oct 26, 2018 at 13:44:07 +0100,
Tom Lane wrote:
Bruno Wolff III writes:
As a short term work around, could I create the index first and use
insert statements, each in their own transaction, to get the table loaded
with the index?
Yes; it might also be that you don't even need
It looks like it got past creating the exclude constraint based on the
ordering of commands in the dump file. However creating a more normal
spgist index is taking a very long time with a lot of disk wait time.
CPU usage seems pretty low for the amount of time it has been working
on building
On Wed, Oct 24, 2018 at 10:21:11 +0100,
Tom Lane wrote:
Bruno Wolff III writes:
If I have a substantial database dump file to provide for reproducing this
do you prefer it on a web server somewhere? I expect that mailing very
large attachments to the lists is a bad idea.
No, don't do
While reloading a database cluster to move from 10.5 to 11, I'm getting
out of memory crashes that I did see when doing reloads on pg 10.
The statement flagged in the log is this:
2018-10-23 16:44:34.815 CDT [126839] STATEMENT: ALTER TABLE ONLY
public.iplocation
ADD CONSTRAINT
On Wed, Oct 24, 2018 at 09:33:48 +0100,
Tom Lane wrote:
Bruno Wolff III writes:
While reloading a database cluster to move from 10.5 to 11, I'm getting
out of memory crashes that I did see when doing reloads on pg 10.
The statement flagged in the log is this:
2018-10-23 16:44:34.815 CDT
On Fri, Oct 26, 2018 at 10:16:09 +0100,
Tom Lane wrote:
Bruno Wolff III writes:
I have something that seems to produce it on rhel7. Fedora isn't working
well either, but the difference may be due to postgresql.conf being
different or some difference in the Fedora build.
Hmm, in my hands
On Wed, Oct 19, 2022 at 19:59:52 -0400,
Tom Lane wrote:
The release notes could probably use some tweaking here. It looks to
me like pg_dumpall (and hence pg_upgrade) will adjust the ownership and
permissions of template1's public schema to match what was in the old
installation, but it
I noticed when I did an upgrade from Postgres 14 to 15 that the public
schema in template1 was still owned by postgres instead of pg_database_owner.
I was expecting it to change because the release notes said that new
database clusters would have that. But shouldn't new clusters use what
is
On Wed, Oct 19, 2022 at 23:30:58 +0200,
Thomas Kellerer wrote:
Bruno Wolff III schrieb am 19.10.2022 um 22:36:
I noticed when I did an upgrade from Postgres 14 to 15 that the
public schema in template1 was still owned by postgres instead of
pg_database_owner. I was expecting it to change
On Wed, Oct 19, 2022 at 19:59:52 -0400,
Tom Lane wrote:
The release notes could probably use some tweaking here. It looks to
me like pg_dumpall (and hence pg_upgrade) will adjust the ownership and
permissions of template1's public schema to match what was in the old
installation, but it
15 matches
Mail list logo
