On Wed, Dec 7, 2022 at 10:20:09AM +0800, qihua wu wrote:
> Per the following link: https://www.sobyte.net/post/2022-08/postgres-snapshot/
> To get a snapshot we need to know xmin, xmax and xip. my question is why do we
> need them? Since every tuple in a page has t_xmin and t_xmax based on the pag
Per the following link:
https://www.sobyte.net/post/2022-08/postgres-snapshot/
To get a snapshot we need to know xmin, xmax and xip. my question is why do
we need them? Since every tuple in a page has t_xmin and t_xmax based on
the page layout(
https://www.postgresql.org/docs/current/storage-page-l
Greetings!
I am getting the following message using DEBUG logging, telling me that a
particular GIST index is suboptimal. This is for a table with ids and date
ranges that are supposed to be non-overlapping. Here is the index def:
"my_fact_table_id_as_of_date_excl" EXCLUDE USING gist (id WITH =
On 12/5/22 11:49, Nunya Business wrote:
Good afternoon,
I've recently run into a weird issue that I'm trying to gather more data
on before sending an official bug report on the off chance that it's
already been addressed.
Within my schema there is a table that has a GENERATED ALWAYS column
"Nunya Business" writes:
> Within my schema there is a table that has a GENERATED ALWAYS column
> that calls a plpgsql function. The called function has a "row type"
> variable declared that references a view. While the schema itself
> functions properly day to day, and pg_dumpall works as e
Good afternoon,
I've recently run into a weird issue that I'm trying to gather more data
on before sending an official bug report on the off chance that it's
already been addressed.
Within my schema there is a table that has a GENERATED ALWAYS column
that calls a plpgsql function. The calle
On Thu, Dec 1, 2022 at 7:40 AM Vijaykumar Jain
wrote:
>
>
>> I do not recall zfs snapshots took anything resource intensive, and it was
>> quick.ill ask around for actual time.
>
>
> Ok just a small note, out ingestion pattern is write anywhere, read globally.
> So we did stop ingestion while s
On Tue, 6 Dec, 2022, 4:17 pm Pavel Stehule, wrote:
> Hi
>
> for record - the problem was probably in using plpgsql_check together with
> PL debugger (plugin_debugger). Both extensions use the PLpgSQL DBG API, but
> this API is not designed to be used by more extensions. plpgsql_check has
> implem
Hey,
There is pg_monitor role. I can "Read/execute various monitoring views and
functions. This role is a member of pg_read_all_settings, pg_read_all_stats
and pg_stat_scan_tables."
https://www.postgresql.org/docs/14/predefined-roles.html
Cheers,
Mateusz
wt., 6 gru 2022 o 13:37 Wiwwo Staff napi
Hi there!
Is there (a way to have) a "monitoring only" role in PG?
This role should have access to stat views only,maybe something more, but
no access to data whatsoever.
Tnx!
Hi
for record - the problem was probably in using plpgsql_check together with
PL debugger (plugin_debugger). Both extensions use the PLpgSQL DBG API, but
this API is not designed to be used by more extensions. plpgsql_check has
implemented some workaround, but it should be loaded last if this
work
11 matches
Mail list logo
