Re: stxkind only explain two elements. left two unexplained.

[David G. Johnston]

On Tuesday, April 5, 2022, Jian He  wrote:

> PostgreSQL: Documentation: 10: 51.51. pg_statistic_ext
> 
>
>> stxkind : An array containing codes for the enabled statistics kinds;
>> valid values are: d for n-distinct statistics, f for functional
>> dependency statistics
>
>
Read the current version of the docs.

 David J.

stxkind only explain two elements. left two unexplained.

[Jian He]

PostgreSQL: Documentation: 10: 51.51. pg_statistic_ext


> stxkind : An array containing codes for the enabled statistics kinds;
> valid values are: d for n-distinct statistics, f for functional
> dependency statistics


select distinct stxkind from pg_statistic_ext ;
return:

 stxkind
> -
>  {d}
>  {m}
>  {f}
>  {e}
> (4 rows)


 I guess *e *for expression statistics. Since I create the following
statistics object.

create statistics flight_expr1 on(
extract
(month from scheduled_departure at time zone 'Asia/Kolkata')
) from flights;

select stxkind from pg_statistic_ext where stxname =  'flight_expr';

and it return *e.*
But I am not sure what does *m *mean?

It would be better to full explain all these four elements in the doc.

Re: Improve documentation for pg_upgrade, standbys and rsync

[Bruce Momjian]

On Tue, Apr  5, 2022 at 01:10:38PM -0400, Stephen Frost wrote:
> To be more explicit though- we should write a tool to do this.  We
> shouldn't try to document a way to do it because it's hard to get right.
> While rsync is very capable, what's needed to really do this goes beyond
> what we could reasonably put into any rsync command or really even into
> a documented procedure.  I get that we already have it documented (and
> I'll note that doing so was against my recommendation..) and that some
> folks (likely those who follow this mailing list) have had success using
> it, but I'd really rather we just take it out and put it on a wiki
> somewhere as a "we need a tool that does this stuff" and hope that
> someone finds time to write one.

Well, I think pg_upgrade needs a tool, let alone for standby upgrades,
but 13 years in, no one has written one, so I am not holding my breath. 
Also, we need to document the procedure _somewhere_ --- if we don't the
only procedure is embedded in a tool. and that seems even worse than
what we have now.

> It should really be both- things to do on the primary ahead of time
> (truncate all unlogged tables, make sure there aren't any orphaned
> temporary tables, etc), and then things to do on the replicas after
> shutting the primary down (basically, make sure they are fully caught up
> with where the primary was at shutdown).  I tried to explain that in my
> prior email but perhaps didn't do a very good job.
> 
> > Also, let me express my general terror at the idea of anyone actually
> > using this procedure.
> 
> I mean, yeah, I agree.

I thought that was true for pg_upgrade in general?  ;-)

Seems like a pull up your sleeves and hold your nose --- I am good at
those tasks.  ;-)  Should I work on this?  Tangentially, I see that my
old macros fastgetattr and heap_getattr have finally been retired by
commit e27f4ee0a7.  :-)

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson

Re: Improve documentation for pg_upgrade, standbys and rsync

[Stephen Frost]

Greetings,

* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jul 26, 2021 at 3:11 PM Stephen Frost  wrote:
> > * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > > Thanks for looking at this!
> >
> > Sure.  Thanks for working on it!
> 
> Stephen, do you intend to do something about this patch in terms of
> getting it committed? You're the only reviewer but haven't responded
> to the thread for more than 5 months.

I tried to be clear in the last email on the thread, the one which you
just responded to, here:

* Stephen Frost (sfr...@snowman.net) wrote:
> This, of course, all comes back to the original complaint I had about
> documenting this approach, which is that these things should only be
> done by someone extremely familiar with the PG codebase, until and
> unless we write an actual tool to do this.

To be more explicit though- we should write a tool to do this.  We
shouldn't try to document a way to do it because it's hard to get right.
While rsync is very capable, what's needed to really do this goes beyond
what we could reasonably put into any rsync command or really even into
a documented procedure.  I get that we already have it documented (and
I'll note that doing so was against my recommendation..) and that some
folks (likely those who follow this mailing list) have had success using
it, but I'd really rather we just take it out and put it on a wiki
somewhere as a "we need a tool that does this stuff" and hope that
someone finds time to write one.

> I don't feel that I know this area of the documentation well enough to
> feel comfortable passing judgement on whether this change is an
> improvement or not. However I do feel somewhat uncomfortable with
> this:
> 
> -   
> -Prepare for standby server upgrades
> -
> -
> - If you are upgrading standby servers using methods outlined in
> section  - linkend="pgupgrade-step-replicas"/>, verify that the old standby
> - servers are caught up by running 
> pg_controldata
> - against the old primary and standby clusters.  Verify that the
> - Latest checkpoint location values match in all clusters.
> - (There will be a mismatch if old standby servers were shut down
> - before the old primary or if the old standby servers are still running.)
> - Also, make sure wal_level is not set to
> - minimal in the
> postgresql.conf file on the
> - new primary cluster.
> -
> -   
> 
> Right now, we say that you should stop the standby servers and then
> prepared for standby server upgrades. With this patch, we say that you
> should first prepare for standby server upgrades, and then stop the
> standby servers. But the last part of the text about preparing for
> standby server upgrades now mentions things to be done after carrying
> out the next step where the servers are actually stopped. That seems
> confusing. Perhaps we need two separate steps here, one to be
> performed before stopping both servers and the other after.

It should really be both- things to do on the primary ahead of time
(truncate all unlogged tables, make sure there aren't any orphaned
temporary tables, etc), and then things to do on the replicas after
shutting the primary down (basically, make sure they are fully caught up
with where the primary was at shutdown).  I tried to explain that in my
prior email but perhaps didn't do a very good job.

> Also, let me express my general terror at the idea of anyone actually
> using this procedure.

I mean, yeah, I agree.

Thanks,

Stephen


signature.asc
Description: PGP signature

Re: Improve documentation for pg_upgrade, standbys and rsync

[Robert Haas]

On Mon, Jul 26, 2021 at 3:11 PM Stephen Frost  wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > Thanks for looking at this!
>
> Sure.  Thanks for working on it!

Stephen, do you intend to do something about this patch in terms of
getting it committed? You're the only reviewer but haven't responded
to the thread for more than 5 months.

I don't feel that I know this area of the documentation well enough to
feel comfortable passing judgement on whether this change is an
improvement or not. However I do feel somewhat uncomfortable with
this:

-   
-Prepare for standby server upgrades
-
-
- If you are upgrading standby servers using methods outlined in
section , verify that the old standby
- servers are caught up by running pg_controldata
- against the old primary and standby clusters.  Verify that the
- Latest checkpoint location values match in all clusters.
- (There will be a mismatch if old standby servers were shut down
- before the old primary or if the old standby servers are still running.)
- Also, make sure wal_level is not set to
- minimal in the
postgresql.conf file on the
- new primary cluster.
-
-   

Right now, we say that you should stop the standby servers and then
prepared for standby server upgrades. With this patch, we say that you
should first prepare for standby server upgrades, and then stop the
standby servers. But the last part of the text about preparing for
standby server upgrades now mentions things to be done after carrying
out the next step where the servers are actually stopped. That seems
confusing. Perhaps we need two separate steps here, one to be
performed before stopping both servers and the other after.

Also, let me express my general terror at the idea of anyone actually
using this procedure.

Regards,

-- 
Robert Haas
EDB: http://www.enterprisedb.com