> On Jan 24, 2022, at 10:02 PM, Michael Harris wrote:
>
> My apologies,
>
> After posting this and looking at how it appears I realised that line
> wrapping makes the tables totally illegible.
>
> Here they are again with all unnecessary columns removed and others shortened.
>
> locktype |
My apologies,
After posting this and looking at how it appears I realised that line
wrapping makes the tables totally illegible.
Here they are again with all unnecessary columns removed and others shortened.
locktype | database | relation | pid |mode |
granted |
Hello Experts
I'm hoping you will be able to help me with a tricky issue.
We've recently updated our application to PG 14.1, and in the test instance we
have started to see some alarming undetected deadlocks.
An example of what we have seen is:
locktype | database | relation | page | tuple |
Ein Vorschlag:
> Inklusivität und angemessenes Verhalten
>
> Das PostgreSQL-Projekt steht jedem offen, der Interesse an
> der Arbeit mit PostgreSQL hat, unabhängig von seinem
> Erfahrungsstand mit der Software oder mit Technologie im
> Allgemeinen. Wir fördern die Entwicklung und Beiträge aller
>
Hannes Erven writes:
> I'm looking at a "SELECT * FROM pg_stat_statements" output and am
> puzzled by the huge differences between min/max_exec_time even for
> simple queries.
> The most extreme example is probably the statement used by the
> application's connection health check:
> SELECT 1
>
Hi community,
I'm looking at a "SELECT * FROM pg_stat_statements" output and am
puzzled by the huge differences between min/max_exec_time even for
simple queries.
The most extreme example is probably the statement used by the
application's connection health check:
SELECT 1
min=0.001, mean
On Mon, Jan 24, 2022 at 9:25 AM Dominique Devienne
wrote:
> On Mon, Jan 24, 2022 at 3:48 PM David G. Johnston
> wrote:
> > On Monday, January 24, 2022, Dominique Devienne
> wrote:
> >>
> >> After re-reading
> >> https://www.postgresql.org/docs/14/sql-createfunction.html in light of
> >> Tom's a
If interval_end_date is always 1 day ahead, why store it at all?
Dependencies on a custom stats object wouldn't do anything I don't think
because they are offset. They are 100% correlated, but not in a way that
any of the existing stat types capture as far as I can figure.
On 1/24/22 08:27, Dominique Devienne wrote:
On Mon, Jan 24, 2022 at 3:48 PM David G. Johnston
wrote:
On Monday, January 24, 2022, Dominique Devienne wrote:
After re-reading
https://www.postgresql.org/docs/14/sql-createfunction.html in light of
Tom's answer,
does that mean that our `SET searc
On Mon, Jan 24, 2022 at 3:48 PM David G. Johnston
wrote:
> On Monday, January 24, 2022, Dominique Devienne wrote:
>>
>> After re-reading
>> https://www.postgresql.org/docs/14/sql-createfunction.html in light of
>> Tom's answer,
>> does that mean that our `SET search_path TO {0}, 'pg_temp'`
>> wor
Hi,
We have a fairly big table (22 million rows) which has a start and end
timestamp with time zone and other columns. Some of the columns plus
start timestamp make a primary key. The end timestamp is exactly one
day ahead of the start timestamp for each row and there are
approximately 1 row
On Monday, January 24, 2022, Dominique Devienne wrote:
>
> After re-reading
> https://www.postgresql.org/docs/14/sql-createfunction.html in light of
> Tom's answer,
> does that mean that our `SET search_path TO {0}, 'pg_temp'`
> workaround, in the trigger below,
> to not depend on the search_path
The PostgreSQL Community Code of Conduct Committee has received a draft of
the German translation of the Code of Conduct Policy updated August 18,
2020 for review.
The English version of the Policy is at:
https://www.postgresql.org/about/policies/coc/
The translation was contributed by:
- Gun
On Mon, Jan 24, 2022 at 11:19 AM Ganesh Korde wrote:
> On Mon, 24 Jan 2022, 3:22 pm Dominique Devienne, wrote:
>> Is there any way to achieve that, beside our current `SET search_path`
>> workaround?
> This might help.
> Alter user SET search_path TO myschema,public;
> No need to set search_pa
On Mon, 24 Jan 2022, 3:22 pm Dominique Devienne,
wrote:
> Hi. In
> https://www.mail-archive.com/pgsql-general@lists.postgresql.org/msg29321.html
> I asked:
>
> > On Tue, Jan 11, 2022 at 5:30 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> > > On Tuesday, January 11, 2022, Dominique
Hi. In
https://www.mail-archive.com/pgsql-general@lists.postgresql.org/msg29321.html
I asked:
> On Tue, Jan 11, 2022 at 5:30 PM David G. Johnston
> wrote:
> > On Tuesday, January 11, 2022, Dominique Devienne >
> > wrote:
> >> This means the template-schema name is part of the DDL for the schem
Thanks, works perfectly!
On Sun, Jan 23, 2022 at 4:22 PM Tom Lane wrote:
> Paul van der Linden writes:
> > Thanks for the clarification, but giving up performance is a no-go for
> us.
> > Also I have my concerns about shemaqualifying each and every use of the
> ->
> > operator, there are really
17 matches
Mail list logo
