pgsql: pgbench: Move constant into format string

pgbench: Move constant into format string As coded, the row data strings generated for pgbench_accounts' COPY in the client-side data generation were always assigning 0 for one of its attributes. This simplifies a bit an upcoming patch to switch client-side data generation of pgbench to use COPY

Re: pgsql: Report index vacuum progress.

On Tue, Jul 11, 2023 at 12:53 PM Michael Paquier wrote: > > On Tue, Jul 11, 2023 at 03:36:32AM +, Masahiko Sawada wrote: > > This uses the new parallel message type for progress reporting added > > by be06506e7. > > Seems like this should be f188972. Hmm, right. I forgot to update the commit

Re: pgsql: Report index vacuum progress.

On Tue, Jul 11, 2023 at 03:36:32AM +, Masahiko Sawada wrote: > This uses the new parallel message type for progress reporting added > by be06506e7. Seems like this should be f188972. -- Michael signature.asc Description: PGP signature

pgsql: Report index vacuum progress.

Report index vacuum progress. This commit adds two columns: indexes_total and indexes_processed, to pg_stat_progress_vacuum system view to show the index vacuum progress. These numbers are reported in the "vacuuming indexes" and "cleaning up indexes" phases. This uses the new parallel message typ

pgsql: Add new parallel message type to progress reporting.

Add new parallel message type to progress reporting. This commit adds a new type of parallel message 'P' to allow a parallel worker to poke at a leader to update the progress. Currently it supports only incremental progress reporting but it's possible to allow for supporting of other backend prog

pgsql: Add BEGIN/COMMIT for transactional messages during decoding.

Add BEGIN/COMMIT for transactional messages during decoding. In test_decoding module, when skip_empty_xacts option was specified, add BEGIN/COMMIT for transactional messages. This makes the handling of transactional messages consistent irrespective of whether skip_empty_xacts option was specified.

pgsql: Don't expose Windows' mbstowcs_l() and wcstombs_l().

Don't expose Windows' mbstowcs_l() and wcstombs_l(). Windows has similar functions with leading underscores. Previously, we provided the rename via a macro in win32_port.h. In fact its functions are not always good replacements for the Unix functions, since they can't deal with UTF-8. They are

pgsql: Be more rigorous about local variables in PostgresMain().

Be more rigorous about local variables in PostgresMain(). Since PostgresMain calls sigsetjmp, any local variables that are not marked "volatile" have a risk of unspecified behavior. In practice this means that when control returns via longjmp, such variables might get reset to their values as of

pgsql: Be more rigorous about local variables in PostgresMain().

Be more rigorous about local variables in PostgresMain(). Since PostgresMain calls sigsetjmp, any local variables that are not marked "volatile" have a risk of unspecified behavior. In practice this means that when control returns via longjmp, such variables might get reset to their values as of

pgsql: Be more rigorous about local variables in PostgresMain().

Be more rigorous about local variables in PostgresMain(). Since PostgresMain calls sigsetjmp, any local variables that are not marked "volatile" have a risk of unspecified behavior. In practice this means that when control returns via longjmp, such variables might get reset to their values as of

pgsql: Be more rigorous about local variables in PostgresMain().

Be more rigorous about local variables in PostgresMain(). Since PostgresMain calls sigsetjmp, any local variables that are not marked "volatile" have a risk of unspecified behavior. In practice this means that when control returns via longjmp, such variables might get reset to their values as of

pgsql: Be more rigorous about local variables in PostgresMain().

Be more rigorous about local variables in PostgresMain(). Since PostgresMain calls sigsetjmp, any local variables that are not marked "volatile" have a risk of unspecified behavior. In practice this means that when control returns via longjmp, such variables might get reset to their values as of

pgsql: Be more rigorous about local variables in PostgresMain().

Be more rigorous about local variables in PostgresMain(). Since PostgresMain calls sigsetjmp, any local variables that are not marked "volatile" have a risk of unspecified behavior. In practice this means that when control returns via longjmp, such variables might get reset to their values as of

pgsql: Be more rigorous about local variables in PostgresMain().

Be more rigorous about local variables in PostgresMain(). Since PostgresMain calls sigsetjmp, any local variables that are not marked "volatile" have a risk of unspecified behavior. In practice this means that when control returns via longjmp, such variables might get reset to their values as of

pgsql: Fix pgindent

Fix pgindent for commit e53a611523 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e004cb0394402a26b7142721e59a4f8e179bd1e4 Modified Files -- src/backend/tcop/utility.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Fix pgindent

Fix pgindent for commit e53a611523 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a44d96add2eb377ab70055a54b713c5c78380383 Modified Files -- src/backend/tcop/utility.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Message wording improvements

Message wording improvements Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2631ebab7b18bdc079fd86107c47d6104a6b3c6e Modified Files -- src/backend/access/common/reloptions.c | 2 +- src/backend/backup/basebackup_zstd.c

pgsql: Message wording improvements

Message wording improvements Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e53a611523af0195d7025b979d29ea4d166ad762 Modified Files -- src/backend/access/common/reloptions.c | 2 +- src/backend/backup/basebackup_zstd.c