Dear Members!
I would like to ask if the PG 10-11 versions are also affected by MAT VIEW
security problems?
They aren't listed in this page:
https://www.postgresql.org/support/security/CVE-2024-0985/
But maybe that's because PG 10 and 11 are no longer supported - and not
because they aren't
On Mon, Feb 12, 2024 at 10:12 PM Adrian Garcia Badaracco <
adr...@adriangb.com> wrote:
> I am using Timescale so I'll be mentioning some timestamp stuff but I
> think this is a general postgres question for the most part.
>
> I have a table with some fixed, small columns (id, timestamp, etc) and
I am using Timescale so I'll be mentioning some timestamp stuff but I think
this is a general postgres question for the most part.
I have a table with some fixed, small columns (id, timestamp, etc) and a
large JSONB column (let's call it `attributes`). `attributes` has 1000s of
schemas, but given
On Tue, 13 Feb 2024 at 02:01, Ron Johnson wrote:
> On Mon, Feb 12, 2024 at 3:23 PM veem v wrote:
> [snip]
>
>> So it looks like the fixed length data type(like integer, float) should
>> be the first choice while choosing the data type of the attributes
>> wherever possible, as these are native
On Mon, Feb 12, 2024 at 3:23 PM veem v wrote:
[snip]
> So it looks like the fixed length data type(like integer, float) should be
> the first choice while choosing the data type of the attributes
> wherever possible, as these are native types.
>
Correct.
> (Like choosing "Integer/float" over
Thank you so much for the clarification.
On Mon, 12 Feb 2024 at 03:40, Peter J. Holzer wrote:
> The fixed width types are those that the CPU can directly process:
> Integers with 16, 32 and 64 bits, floating point numbers with 32 and 64
> bits. The CPU can read and write them with a single
> Is there any way to track those historical executions and be able to find
the exact root cause of the slow executions confidently?
https://www.postgresql.org/docs/current/auto-explain.html
auto_explain.log_min_duration = '5s' ## or large enough to capture your
quickest one
Do NOT enable
Thank You.
On Mon, 12 Feb 2024 at 22:17, Greg Sabino Mullane
wrote:
> Sure will try to test and see how it behaves when the number of
>> simultaneous queries (here 32/4=8 concurrent queries) exceed the
>> max_parallel_workers limit. Though I am expecting the further queries
>> exceeding the
On 2/12/24 08:42, Adrian Klaver wrote:
On 2/11/24 15:13, ste...@gmail.com wrote:
Thanks, Adrian, for the suggestion, but same problem.
I've just tried to execute "ANALYZE" (on the whole database) after the
import of all the tables (with COPY) and before the other queries, but
the query
On Mon, Feb 12, 2024 at 5:08 AM Dávid Suchan
wrote:
> Hi, I was wondering what is the safest pg_upgrade version upgrade distance
> going from 9.6 version. Do I need to go version by version or I can go from
> 9.6 to 15?
You can go direct. You really should go to 16 though. If nothing else, you
Karsten Hilbert writes:
> Am Mon, Feb 12, 2024 at 09:31:50AM -0500 schrieb Ron Johnson:
>> https://www.postgresql.org/docs/16/pgupgrade.html
>> "pg_upgrade supports upgrades from 9.2.X and later to the current major
>> release of PostgreSQL, including snapshot and beta releases."
> Just to be
>
> When the user clicks to the second page , it will see the next set of rows
> i.e 100 to 200 and next will see 200 to 300 and so on till the result set
> finishes.
>
As others have pointed out, that still makes no sense. You will either fail
to show certain rows completely, or have a stale
On 2/11/24 15:13, ste...@gmail.com wrote:
Thanks, Adrian, for the suggestion, but same problem.
I've just tried to execute "ANALYZE" (on the whole database) after the import
of all the tables (with COPY) and before the other queries, but the query always hangs (I
hope this was the way you
On Mon, Feb 12, 2024 at 1:50 AM veem v wrote:
> So we were thinking, adding many column to a table should be fine in
> postgres (as here we have a use case in which total number of columns may
> go till ~500+). But then, considering the access of columns towards the
> end of a row is going to
On Tue, Feb 6, 2024 at 12:15 AM Lok P wrote:
> Another thing I noticed the shared_buffer parameters set as 2029684 in
> this instance, which comes to ~21MB and that seems very small for a
> database operating in large scale. And I see we have RAM in the instance
> showing as ~256GB. So thinking
Am Mon, Feb 12, 2024 at 09:31:50AM -0500 schrieb Ron Johnson:
> https://www.postgresql.org/docs/16/pgupgrade.html
> "pg_upgrade supports upgrades from 9.2.X and later to the current major
> release of PostgreSQL, including snapshot and beta releases."
Just to be sure: it should be stressed that
On Mon, Feb 12, 2024 at 5:08 AM Dávid Suchan
wrote:
> Hi, I was wondering what is the safest pg_upgrade version upgrade distance
> going from 9.6 version. Do I need to go version by version or I can go from
> 9.6 to 15? We have a very huge database(TBs) with one replication server,
> so we will
I have upgraded from 9.5 to 14 using the -link option. It works fine.
I equally had streaming replication running on it.
I break(split brain) replication and upgrade the standby, once it done and
everything is running smoothly, I then install version 14 to the old
primary and just configure
On Mon, Feb 12, 2024 at 7:50 AM veem v wrote:
> I think that's not much of a concern with PostgreSQL because you can't
>> update a row in-place anyway because of MVCC.
>
>
> Good to know. So it means here in postgres, there is no such concern like
> "row chaining", "row migration" etc.
>
which
On 2024-02-12 20:07, Dávid Suchan wrote:
Hi, I was wondering what is the safest pg_upgrade version upgrade
distance
going from 9.6 version. Do I need to go version by version or I can go
from
9.6 to 15? We have a very huge database(TBs) with one replication
server,
so we will first run the
Hi, I was wondering what is the safest pg_upgrade version upgrade distance
going from 9.6 version. Do I need to go version by version or I can go from
9.6 to 15? We have a very huge database(TBs) with one replication server,
so we will first run the pgupgrade on the main server and then rsync to a
21 matches
Mail list logo
