On Wed, 7 Aug 2024 at 16:44, Christophe Pettus wrote:
> Child partitions should be autovacuumed and autoanalyzed just like any other
> table; they are not prohibited from autovacuum in any way by default. It's
> probably a good idea to investigate why they are not being picked up by
> autovacu
> On Aug 6, 2024, at 21:13, Michael Harris wrote:
>
> 1. What is the consequence of not having good statistics on partitioned
> table level, if you do have good statistics on the partition level?
The child partitions are just tables, and all of the same issues that can arise
from bad stat
Hi Vamsi,
We have been doing these steps to setup streaming replication
--Primay-Server
CREATE ROLE repl REPLICATION LOGIN PASSWORD 'your_password';
postgresql.conf
listen_addresses = '*'
wal_level = replica
archive_mode = on
archive_command = 'copy %p \\path_to_archive\\%f'
max_wal_senders =
Hello Experts,
Our application has a database with a large number of partitioned tables
used to store time series data.
It is partitioned by time: new data is populated into the current
partition, old partitions eventually get dropped, and the partitions in
between are largely static.
I had not
> On Aug 6, 2024, at 19:45, Laurenz Albe wrote:
> I am surprised by that. Would you say that most storage systems will happily
> give you a
> garbage block if there was a hardware problem somewhere?
"Most" is hard for me to judge. HDDs can have uncorrected and undetected
errors, definitely
On Tue, 2024-08-06 at 09:29 -0700, Christophe Pettus wrote:
>
> > On Aug 6, 2024, at 08:11, bruno vieira da silva
> > wrote:
> >
> > so my question is why data checksums aren't enabled by default on pg?
>
> At this point, mostly historical reasons. They're also superfluous if your
> underlyi
Hi Team,
we have upgraded postgresql version 11 to 14 on windows server 2016, post
upgrade we configured streaming replication. the data is not getting
replicated. but compared to version 11, 14 is very different in
configuring replication. Tried from documentation from postgres site. no
luck, Any
On Tue, Aug 6, 2024 at 5:07 PM yudhi s wrote:
> Hi All,
> We are having a use case in which we are having transaction data for
> multiple customers in one of the Postgres databases(version 15.4) and we
> are consuming it from multiple sources(batch file processing, kafka event
> processing etc).
On Tue, Aug 6, 2024 at 11:44 PM Peter J. Holzer wrote:
> I assume that "1254" here is the code page.
> But you specified --encoding=UTF-8 above, so your default locale uses a
> different encoding than the template databases. I would expect that to
> cause problems if the template databases contain
Hi All,
We are having a use case in which we are having transaction data for
multiple customers in one of the Postgres databases(version 15.4) and we
are consuming it from multiple sources(batch file processing, kafka event
processing etc). It's currently stored in normalized form postgres
with con
On Tue, Aug 6, 2024 at 10:38 PM Sandeep Thakkar
wrote:
> On Tue, Aug 6, 2024 at 4:06 PM Sandeep Thakkar
> wrote:
[v15]
>>> XXX debug raw: setup_locale_encoding = "Turkish_Türkiye.1254"
>>> XXX debug hex: setup_locale_encoding = { 54 75 72 6b 69 73 68 5f 54 fc 72
>>> 6b 69 79 65 2e 31 32 35
The penalty is not "considerable", but it is not completely trivial either.
But it's more on the trivial side. Part of the problem is that it is hard
to measure, as it is very workload dependent. As to why it is not the
default, Postgres is very careful and conservative by default, and not
everybod
> On Aug 6, 2024, at 08:11, bruno vieira da silva wrote:
>
> so my question is why data checksums aren't enabled by default on pg?
At this point, mostly historical reasons. They're also superfluous if your
underlying file system or storage hardware does storage-level corruption checks
(whi
On Tue, Aug 6, 2024 at 11:12 AM bruno vieira da silva
wrote:
> Hello.
> I've been dealing with some database corruption events, so i've been
> wondering to enable data checksums on my deployments.
>
> so my question is why data checksums aren't enabled by default on pg? the
> pg doc
> mentions a
Hello.
I've been dealing with some database corruption events, so i've been
wondering to enable data checksums on my deployments.
so my question is why data checksums aren't enabled by default on pg? the
pg doc
mentions a considerable performance penality, how considerable it is?
Thanks
--
Bruno
On Tue, Aug 6, 2024 at 4:31 PM Tom Lane wrote:
> Dominique Devienne writes:
> > Hi. Now that v17beta2 is part of my dev-env, I'm trying out the new API.
> > And I discover there's no version macro for conditional compilation in
> > LIBPQ...
>
> Indeed, that's an oversight, and there's a number o
Dominique Devienne writes:
> Hi. Now that v17beta2 is part of my dev-env, I'm trying out the new API.
> And I discover there's no version macro for conditional compilation in
> LIBPQ...
Indeed, that's an oversight, and there's a number of other things
we added to libpq-fe.h between 16 and 17 tha
Hi. Now that v17beta2 is part of my dev-env, I'm trying out the new API.
And I discover there's no version macro for conditional compilation in LIBPQ...
I found https://www.postgresql.org/message-id/968815.1623936849%40sss.pgh.pa.us
where Tom thinks that a horrible idea, and instead proposes a new
On 2024-08-06 16:06:51 +0530, Sandeep Thakkar wrote:
> On Tue, Aug 6, 2024 at 10:57 AM Thomas Munro wrote:
>
> On Mon, Aug 5, 2024 at 8:50 PM Sandeep Thakkar
> wrote:
> > This issue is seen only on v16 and not the back branches (tested on 15
> and 14) and also confirmed by @Ertan
On Tue, Aug 6, 2024 at 4:06 PM Sandeep Thakkar <
sandeep.thak...@enterprisedb.com> wrote:
>
>
> On Tue, Aug 6, 2024 at 10:57 AM Thomas Munro
> wrote:
>
>> On Mon, Aug 5, 2024 at 8:50 PM Sandeep Thakkar
>> wrote:
>> > This issue is seen only on v16 and not the back branches (tested on 15
>> and 1
On Tue, Aug 6, 2024 at 10:57 AM Thomas Munro wrote:
> On Mon, Aug 5, 2024 at 8:50 PM Sandeep Thakkar
> wrote:
> > This issue is seen only on v16 and not the back branches (tested on 15
> and 14) and also confirmed by @Ertan Küçükoglu at
> https://github.com/EnterpriseDB/edb-installers/issues/127
On Mon, Aug 5, 2024 at 2:26 PM David Rowley wrote:
> Meson is now the only available method for Visual Studio builds."
Thanks David. My colleague figured it out, thanks to your pointers. Cheers, --DD
Hi,
This parameter is supported only on systems that support TCP_KEEPINTVL. And
please ensure that you are not accidentally connecting through a
Unix-domain socket. If the result of this query is null then it is a Unix
socket based connection.
SELECT client_addr FROM pg_stat_activity WHERE pid =
23 matches
Mail list logo
