Re: making relfilenodes 56 bits

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: making relfilenodes 56 bits
Дата
Msg-id CAFiTN-u4dAEbRUZp1Ry7+QzERnjKDjwafo=wRAEkz84W--0Rcw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: making relfilenodes 56 bits  (vignesh C <vignesh21@gmail.com>)
Ответы Re: making relfilenodes 56 bits  (vignesh C <vignesh21@gmail.com>)
Список pgsql-hackers
On Wed, Jul 27, 2022 at 3:27 PM vignesh C <vignesh21@gmail.com> wrote:
>

> Thanks for the updated patch, Few comments:
> 1) The format specifier should be changed from %u to INT64_FORMAT
> autoprewarm.c -> apw_load_buffers
> ...............
> if (fscanf(file, "%u,%u,%u,%u,%u\n", &blkinfo[i].database,
>    &blkinfo[i].tablespace, &blkinfo[i].filenumber,
>    &forknum, &blkinfo[i].blocknum) != 5)
> ...............
>
> 2) The format specifier should be changed from %u to INT64_FORMAT
> autoprewarm.c -> apw_dump_now
> ...............
> ret = fprintf(file, "%u,%u,%u,%u,%u\n",
>   block_info_array[i].database,
>   block_info_array[i].tablespace,
>   block_info_array[i].filenumber,
>   (uint32) block_info_array[i].forknum,
>   block_info_array[i].blocknum);
> ...............
>
> 3) should the comment "entry point for old extension version" be on
> top of pg_buffercache_pages, as the current version will use
> pg_buffercache_pages_v1_4
> +
> +Datum
> +pg_buffercache_pages(PG_FUNCTION_ARGS)
> +{
> +       return pg_buffercache_pages_internal(fcinfo, OIDOID);
> +}
> +
> +/* entry point for old extension version */
> +Datum
> +pg_buffercache_pages_v1_4(PG_FUNCTION_ARGS)
> +{
> +       return pg_buffercache_pages_internal(fcinfo, INT8OID);
> +}
>
> 4) we could use the new style or ereport by removing the brackets
> around errcode:
> +                               if (fctx->record[i].relfilenumber > OID_MAX)
> +                                       ereport(ERROR,
> +
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> +
> errmsg("relfilenode" INT64_FORMAT " is too large to be represented as
> an OID",
> +
>  fctx->record[i].relfilenumber),
> +
> errhint("Upgrade the extension using ALTER EXTENSION pg_buffercache
> UPDATE")));
>
> like:
> ereport(ERROR,
>
> errcode(ERRCODE_INVALID_PARAMETER_VALUE),
>
> errmsg("relfilenode" INT64_FORMAT " is too large to be represented as
> an OID",
>
> fctx->record[i].relfilenumber),
>
> errhint("Upgrade the extension using ALTER EXTENSION pg_buffercache
> UPDATE"));
>
> 5) Similarly in the below code too:
> +       /* check whether the relfilenumber is within a valid range */
> +       if ((relfilenumber) < 0 || (relfilenumber) > MAX_RELFILENUMBER)
> +               ereport(ERROR,
> +                               (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> +                                errmsg("relfilenumber " INT64_FORMAT
> " is out of range",
> +                                               (relfilenumber))));
>
>
> 6) Similarly in the below code too:
> +#define CHECK_RELFILENUMBER_RANGE(relfilenumber)
>          \
> +do {
>                                                          \
> +       if ((relfilenumber) < 0 || (relfilenumber) > MAX_RELFILENUMBER) \
> +               ereport(ERROR,
>                                                  \
> +
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),                      \
> +                                errmsg("relfilenumber " INT64_FORMAT
> " is out of range",       \
> +                                               (relfilenumber)))); \
> +} while (0)
> +
>
>
> 7) This error code looks similar to CHECK_RELFILENUMBER_RANGE, can
> this macro be used here too:
> pg_filenode_relation(PG_FUNCTION_ARGS)
>  {
>         Oid                     reltablespace = PG_GETARG_OID(0);
> -       RelFileNumber relfilenumber = PG_GETARG_OID(1);
> +       RelFileNumber relfilenumber = PG_GETARG_INT64(1);
>         Oid                     heaprel;
>
> +       /* check whether the relfilenumber is within a valid range */
> +       if ((relfilenumber) < 0 || (relfilenumber) > MAX_RELFILENUMBER)
> +               ereport(ERROR,
> +                               (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> +                                errmsg("relfilenumber " INT64_FORMAT
> " is out of range",
> +                                               (relfilenumber))));
>
>
> 8) I felt this include is not required:
> diff --git a/src/backend/access/transam/varsup.c
> b/src/backend/access/transam/varsup.c
> index 849a7ce..a2f0d35 100644
> --- a/src/backend/access/transam/varsup.c
> +++ b/src/backend/access/transam/varsup.c
> @@ -13,12 +13,16 @@
>
>  #include "postgres.h"
>
> +#include <unistd.h>
> +
>  #include "access/clog.h"
>  #include "access/commit_ts.h"
>
> 9) should we change elog to ereport to use the New-style error reporting API
> +       /* safety check, we should never get this far in a HS standby */
> +       if (RecoveryInProgress())
> +               elog(ERROR, "cannot assign RelFileNumber during recovery");
> +
> +       if (IsBinaryUpgrade)
> +               elog(ERROR, "cannot assign RelFileNumber during binary
> upgrade");
>
> 10) Here nextRelFileNumber is protected by RelFileNumberGenLock, the
> comment stated OidGenLock. It should be slightly adjusted.
> typedef struct VariableCacheData
> {
> /*
> * These fields are protected by OidGenLock.
> */
> Oid nextOid; /* next OID to assign */
> uint32 oidCount; /* OIDs available before must do XLOG work */
> RelFileNumber nextRelFileNumber; /* next relfilenumber to assign */
> RelFileNumber loggedRelFileNumber; /* last logged relfilenumber */
> XLogRecPtr loggedRelFileNumberRecPtr; /* xlog record pointer w.r.t.
> * loggedRelFileNumber */

Thanks for the review I have fixed these except,
> 9) should we change elog to ereport to use the New-style error reporting API
I think this is internal error so if we use ereport we need to give
error code and all and I think for internal that is not necessary?

> 8) I felt this include is not required:
it is using access API so we do need <unistd.h>

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Refactor to make use of a common function for GetSubscriptionRelations and GetSubscriptionNotReadyRelations.
Следующее
От: David Geier
Дата:
Сообщение: Reducing planning time on tables with many indexes