W dniu 01.07.2021 o 22:27, Adrian Klaver pisze:
On 7/1/21 12:56 PM, W.P. wrote:
W dniu 01.07.2021 o 16:19, Laurenz Albe pisze:
On Thu, 2021-07-01 at 10:56 +0200, W.P. wrote:
I have a PG 11.12 (was 9.5 or 9.5) upgraded from 9.x (during OS
upgrade).
One table is now damaged, trying to dump it
On Wed, 30 Jun 2021 at 04:49, Tom Lane wrote:
> George Tarasov writes:
> > So, my questions are there any rules / descriptions / agreements inside
> > the PostgreSQL Project that define which global variables inside a core
> > code should by specified by a PGDLLIMPORT and which should not?? Or
>
On 7/1/21 12:56 PM, W.P. wrote:
W dniu 01.07.2021 o 16:19, Laurenz Albe pisze:
On Thu, 2021-07-01 at 10:56 +0200, W.P. wrote:
I have a PG 11.12 (was 9.5 or 9.5) upgraded from 9.x (during OS
upgrade).
One table is now damaged, trying to dump it results in server restart,
message is "invalid re
W dniu 01.07.2021 o 16:19, Laurenz Albe pisze:
On Thu, 2021-07-01 at 10:56 +0200, W.P. wrote:
I have a PG 11.12 (was 9.5 or 9.5) upgraded from 9.x (during OS upgrade).
One table is now damaged, trying to dump it results in server restart,
message is "invalid record length maximum is yyy" (
Good day!
There's a query inside a DO block which -- because it's parameterized -- I'd
rather analyze while it's in the FOR loop of a DO block, instead of pulling
it out and hard-coding the parameters.
Is this possible?
No.
Why not to use auto_explain module?
postgres=# LOAD 'auto_explain';
L
On Thu, Jul 1, 2021 at 9:22 AM Michael Lewis wrote:
> It sounds like you are wanting to run 'explain analyze [query]' inside a
> loop inside a DO block. That isn't possible as far as I know, but
> auto_explain and log_nested_statements should be able to let you profile
> the whole thing and perha
Ron writes:
> There's a query inside a DO block which -- because it's parameterized -- I'd
> rather analyze while it's in the FOR loop of a DO block, instead of pulling
> it out and hard-coding the parameters.
> Is this possible?
No.
The thing to do to duplicate the behavior of a plpgsql quer
It sounds like you are wanting to run 'explain analyze [query]' inside a
loop inside a DO block. That isn't possible as far as I know, but
auto_explain and log_nested_statements should be able to let you profile
the whole thing and perhaps you can pick out the part you want from the
logs.
Postgresql 12.5
There's a query inside a DO block which -- because it's parameterized -- I'd
rather analyze while it's in the FOR loop of a DO block, instead of pulling
it out and hard-coding the parameters.
Is this possible? If so, where do I put the EXPLAIN statement?
--
Angular momentum
On Thu, 2021-07-01 at 10:56 +0200, W.P. wrote:
> I have a PG 11.12 (was 9.5 or 9.5) upgraded from 9.x (during OS upgrade).
>
> One table is now damaged, trying to dump it results in server restart,
> message is "invalid record length maximum is yyy" (from memory).
>
> How can I (?) repair t
čt 1. 7. 2021 v 15:27 odesílatel Pavel Stehule
napsal:
>
>
> čt 1. 7. 2021 v 15:26 odesílatel Ron napsal:
>
>> Postgresql 12.5
>>
>>
>> What's the canonical Postgresql method for doing, for example, this?
>> SELECT relname, MAXOF(last_vacuum, last_autovacuum)
>> FROM pg_stat_user_tables;
>>
>> S
čt 1. 7. 2021 v 15:26 odesílatel Ron napsal:
> Postgresql 12.5
>
>
> What's the canonical Postgresql method for doing, for example, this?
> SELECT relname, MAXOF(last_vacuum, last_autovacuum)
> FROM pg_stat_user_tables;
>
> Seeing both last_vacuum and last_autovacuum is useful, of course, but
> s
Postgresql 12.5
What's the canonical Postgresql method for doing, for example, this?
SELECT relname, MAXOF(last_vacuum, last_autovacuum)
FROM pg_stat_user_tables;
Seeing both last_vacuum and last_autovacuum is useful, of course, but
sometimes I only want to see the "really" last time it was va
On Thu, 1 Jul 2021 at 22:06, wrote:
> I have several tables with generated columns. If I restore the plain dumped
> data (insert statements from pg_dump) I'll get the error message "Column xyz
> is a generated column.". The exception is understandably, no question (and is
> well documented). In
Hi there,
I have a PG 11.12 (was 9.5 or 9.5) upgraded from 9.x (during OS upgrade).
One table is now damaged, trying to dump it results in server restart,
message is "invalid record length maximum is yyy" (from memory).
Also fails pg_dumpall.
How can I (?) repair this table? (for recent
Hi,
I have several tables with generated columns. If I restore the plain dumped
data (insert statements from pg_dump) I'll get the error message "Column xyz is
a generated column.". The exception is understandably, no question (and is well
documented). In case of the error no insert takes place
Hi there,
I have a PG 11.12 (was 9.5 or 9.5) upgraded from 9.x (during OS upgrade).
One table is now damaged, trying to dump it results in server restart,
message is "invalid record length maximum is yyy" (from memory).
Also fails pg_dumpall.
How can I (?) repair this table? (for recent
I would like to avoid using superuser to create subscriptions (logical
replication). If I do not use superuser, I get the following error message
"must be superuser to create subscriptions". Is there a way to void using
superuser to create a subscription? What is pg_subscription_users that I
18 matches
Mail list logo
