List,
I successfully configured pgbackrest (pgBackRest 2.52.1) on RHEL 9.4 with
EPAS 16.1 for a couple of production servers and a Remote Repo Server.
Seems everything is working as expected.
I have a serious concern of archive dir growing day by day..
1. In the EPAS serverI have postg
> On Sep 19, 2024, at 22:46, KK CHN wrote:
>
> 1. In the EPAS serverI have postgres.conf with
> archive_command = 'pgbackrest --stanza=EMI_Repo archive-push %p && cp %p
> /data/archive/%f'
>
> The problem is that the /data/archive folder is growing within a few days
> to 850GB
Hi Team
--snapshot=*snapshotname*
(Use the specified synchronized snapshot when making a dump of the database
This option is useful when needing to synchronize the dump with a logical
replication slot) as per the pgdg
How do we synchronize the dump with a logical replication slot
with --snapsho
Siraj G writes:
> Please find below the query in the format and its execution plan:
[ blink... ] I'm not sure what you are using there, but it is
*not* Postgres. There are assorted entries in the execution
plan that community Postgres has never heard of, such as
> -> Remove duplicate (P0, IS_S
Below are the results for the posted methods. Tested it on local and it
gave no difference in timing between the method-2 andmethod-3. Failed to
run in dbfiddle somehow.
Also I was initially worried if adding the trigger to the our target table,
will worsen the performance as because , it will mak
Hello Tech gents!
I am sorry if I am asking the wrong question to this group, but wanted
assistance in converting a query replacing subqueries with joins.
Please find the query below (whose cost is very high):
select em_exists_id from IS_SEC_FILT WHERE (IS_SEC_FILT_GUID) NOT IN
(SELECT IS_OBJ_GU
On 9/19/24 21:07, Siraj G wrote:
Hello Tech gents!
I am sorry if I am asking the wrong question to this group, but wanted
assistance in converting a query replacing subqueries with joins.
Please find the query below (whose cost is very high):
Add the output of the EXPLAIN ANALYZE for the qu
Hello Adrian!
Please find below the query in the format and its execution plan:
SELECT
em_exists_idFROM
IS_SEC_FILTWHERE (IS_SEC_FILT_GUID)NOT IN (
SELECT
IS_OBJ_GUID
FROM
TMP_IS_SEC_FILT T0,
IS_PROJ P0
WHERE
T0.IS_PROJ_GUID = P0.IS_PROJ_GUID
On Thu, Sep 19, 2024 at 5:40 PM Ron Johnson wrote:
> On Thu, Sep 19, 2024 at 5:24 AM Lok P wrote:
>
>>
>>
>> [snip]
>
>> DO $$
>> DECLARE
>> num_inserts INTEGER := 10;
>> batch_size INTEGER := 50;
>> start_time TIMESTAMP;
>> end_time TIMESTAMP;
>> elapsed_time INTERVAL;
>
On Thu, Sep 19, 2024 at 11:31 AM Ron Johnson
wrote:
>
> [snip]
>
>>
>> Method-4
>>
>> INSERT INTO parent_table VALUES (1, 'a'), (2, 'a');
>> INSERT INTO child_table VALUES (1,1, 'a'), (1,2, 'a');
>> commit;
>>
>
> If I knew that I had to load a structured input data file (even if it had
> pare
On 9/19/24 05:24, Greg Sabino Mullane wrote:
On Thu, Sep 19, 2024 at 5:17 AM veem v
This is really difficult to diagnose from afar with only snippets of
logs and half-complete descriptions of your business logic. Pull
everyone involved into a room with a whiteboard, and produce a document
des
Paul Foerster writes:
> we have SLES 15.5 which has glibc 2.31. Our admin told us that he's about to
> install the SLES 15.6 update which contains glibc 2.38.
> I have built our PostgreSQL software from source on SLES 15.5, because we
> have some special requirements which the packages cannot fu
On 9/19/24 11:14, Tom Lane wrote:
Paul Foerster writes:
we have SLES 15.5 which has glibc 2.31. Our admin told us that
he's about to install the SLES 15.6 update which contains glibc
2.38.
2) Does the glibc update have any impact?
Maybe. We don't really track glibc changes, so I can't say
On 9/19/24 13:07, Joe Conway wrote:
On 9/19/24 11:14, Tom Lane wrote:
Paul Foerster writes:
we have SLES 15.5 which has glibc 2.31. Our admin told us that
he's about to install the SLES 15.6 update which contains glibc
2.38.
2) Does the glibc update have any impact?
Maybe. We don't really
On 2024-09-19 16:37:41 +0200, Paul Foerster wrote:
> we have SLES 15.5 which has glibc 2.31. Our admin told us that he's
> about to install the SLES 15.6 update which contains glibc 2.38.
>
> I have built our PostgreSQL software from source on SLES 15.5, because
> we have some special requirements
Hi Adrian,
> On 19 Sep 2024, at 17:00, Adrian Klaver wrote:
>
> I would take a look at:
>
> https://wiki.postgresql.org/wiki/Locale_data_changes
>
> It refers to the glibc 2.8 change in particular, but includes some generic
> tips that could prove useful.
>
>
> The glibc change log below mi
Hi Tom,
> On 19 Sep 2024, at 17:14, Tom Lane wrote:
>
> No, I wouldn't expect that to be necessary.
I was hoping one of the pros would say that. 🤣
> Maybe. We don't really track glibc changes, so I can't say for sure,
> but it might be advisable to reindex indexes on string columns.
Advisabl
Hi,
we have SLES 15.5 which has glibc 2.31. Our admin told us that he's about to
install the SLES 15.6 update which contains glibc 2.38.
I have built our PostgreSQL software from source on SLES 15.5, because we have
some special requirements which the packages cannot fulfill. So I have
questio
On 9/19/24 07:37, Paul Foerster wrote:
Hi,
we have SLES 15.5 which has glibc 2.31. Our admin told us that he's about to
install the SLES 15.6 update which contains glibc 2.38.
I have built our PostgreSQL software from source on SLES 15.5, because we have
some special requirements which the pa
On Thu, 19 Sept 2024 at 03:02, Adrian Klaver
wrote:
>
>
> This needs clarification.
>
> 1) To be clear when you refer to parent and child that is:
> FK
> parent_tbl.fld <--> child_tbl.fld_fk
>
> not parent and child tables in partitioning scheme?
>
> 2) What are the table schemas
On Thu, Sep 19, 2024 at 5:17 AM veem v wrote:
> 2024-09-18 17:05:56 UTC:100.72.10.66(54582):USER1@TRANDB:[14537]:DETAIL:
> Process 14537 waits for ShareLock on transaction 220975629; blocked by
> process 14548.
>
You need to find out exactly what commands, and in what order, all these
processes
On Thu, Sep 19, 2024 at 5:24 AM Lok P wrote:
>
> On Thu, Sep 19, 2024 at 11:31 AM Ron Johnson
> wrote:
>
>>
>> [snip]
>>
>>>
>>> Method-4
>>>
>>> INSERT INTO parent_table VALUES (1, 'a'), (2, 'a');
>>> INSERT INTO child_table VALUES (1,1, 'a'), (1,2, 'a');
>>> commit;
>>>
>>
>> If I knew that
On Thu, 19 Sept 2024 at 17:54, Greg Sabino Mullane
wrote:
> On Thu, Sep 19, 2024 at 5:17 AM veem v wrote:
>
>> 2024-09-18 17:05:56 UTC:100.72.10.66(54582):USER1@TRANDB:[14537]:DETAIL:
>> Process 14537 waits for ShareLock on transaction 220975629; blocked by
>> process 14548.
>>
>
> You need to
Hi Joe,
> On 19 Sep 2024, at 19:07, Joe Conway wrote:
>
> Every glibc major version change potentially impacts the sorting of some
> strings, which would require reindexing. Whether your actual data trips into
> any of these changes is another matter.
>
> You could check by doing something eq
Hi Peter,
> On 19 Sep 2024, at 19:43, Peter J. Holzer wrote:
>
> I wrote a small script[1] which prints all unicode code points and a few
> selected[2] longer strings in order. If you run that before and after
> the upgrade and the output doesn't change, you are probably be fine.
> (It checks on
On 9/19/24 13:56, Paul Foerster wrote:
On 19 Sep 2024, at 17:14, Tom Lane wrote:
Maybe. We don't really track glibc changes, so I can't say for sure,
but it might be advisable to reindex indexes on string columns.
Advisable is a word I undfortunately can't do much with. We have
terabytes and
Hi Joe,
> On 19 Sep 2024, at 20:09, Joe Conway wrote:
>
> See my thread-adjacent email, but suffice to say that if there are collation
> differences that do affect your tables/data, and you allow any inserts or
> updates, you may wind up with corrupted data (e.g. duplicate data in your
> othe
27 matches
Mail list logo
