Greetings,
Happy to hear you successfully performed pgBackRest for a 50TB DB. Out of
curiosity I would like to know your infrastructure settings.
1. The connectivity protocoal and bandwidth you used for your backend
storage ? Is it iSCSI, FC FCoE or GbE ? what's the exact reason for
the 26 H
Hi Stephen
No, I did not try that. Let me try that now and report the numbers here,
both in terms of size and time taken.
Thanks for the suggestion.
On Tue, Oct 3, 2023 at 10:39 PM Stephen Frost wrote:
> Greetings,
>
> On Mon, Oct 2, 2023 at 20:08 Abhishek Bhola <
> abhishek.bh...@japannext.co
On Tue, Oct 3, 2023 at 7:33 PM Lincoln Swaine-Moore
wrote:
> Hi all,
>
> I'm attempting to generate some reports using user-driven timezones for
> UTC data, and I'm having trouble writing a query that meets the following
> criteria:
>
> 1) Data should be averaged at one of daily, hourly, or 15 mi
Hi all,
I'm attempting to generate some reports using user-driven timezones for UTC
data, and I'm having trouble writing a query that meets the following
criteria:
1) Data should be averaged at one of daily, hourly, or 15 minute
granularities (user-driven).
2) Data over a given period should refl
On 10/3/23 10:32, Johnson, Bruce E - (bjohnson) wrote:
I am trying to import an oracle schema with ora2pg and running into an
odd error when the import_all.sh script gets to a specific view.
The error is:
However when I re-run the import_all.sh script it errors out at the same
place with th
I am trying to import an oracle schema with ora2pg and running into an odd
error when the import_all.sh script gets to a specific view.
The error is:
psql:schema/views/RESERVER_VISIBLE_RESTRICTION_view.sql:10: ERROR: operator
does not exist: character = integer
LINE 1: ...r.resource_id = rg.re
Am 02.10.23 um 13:27 schrieb Matthias Apitz:
Hello,
One of our clients running our LMS on top of PostgreSQL 13.1 created a
ticket with these messages:
2023-09-30 16:50:50.951 CEST [18117] ERROR: deadlock detected
2023-09-30 16:50:50.951 CEST [18117] DETAIL: Process 18117 waits for ShareLoc
On Tue, Oct 3, 2023 at 10:27 AM Don Seiler wrote:
> On the source (PG 12.15) instance, we have bumped max_replication_slots
> and max_wal_senders to 50, and max_sync_workers_per_subscription to 10.
>
Forgot to note that on the subscriber (PG 15.4) instance,
max_sync_workers_per_subscription is 4
Good morning,
I'm trying to set up native logical replication from PG 12.15 (Ubuntu
18.04) to 15.4 (Ubuntu 22.04). I wanted to set up 3 publications to split
up the work. I initially created the three publications with a handful of
tables each. On the source (PG 12.15) instance, we have bumped
max
On 10/3/23 09:37, Douglas Reed wrote:
Hi the full pg_basebackup command was;
pg_basebackup -h 172.110.6.5 -D /var/lib/pgsql/12/data -R -U postgres
--wal-method=stream
I get consistently successful results in v15 using this set of commands
(where the service options reference the primary
On 10/3/23 02:59, Harry Green wrote:
Dear All,
I'd like to thank you for your excellent input on this problem. We have
now resolved this issue and I thought I would mention how. The topic of
the function being used as a check constraint had come up and I had
rejected this because it was the n
Hi the full pg_basebackup command was;
pg_basebackup -h 172.110.6.5 -D /var/lib/pgsql/12/data -R -U postgres
--wal-method=stream
Regards
Doug Reed dougreed...@yahoo.com
Greetings,
On Mon, Oct 2, 2023 at 20:08 Abhishek Bhola
wrote:
> As said above, I tested pgBackRest on my bigger DB and here are the
> results.
> Server on which this is running has the following config:
> Architecture: x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:
On 2023-10-03 05:55:51 -0400, Amn Ojee Uw wrote:
> psql -U my_group_worker -d my_group_db
>
> psql: error: connection to server on socket
> "/var/run/postgresql/.s.PGSQL.5432"
> failed: FATAL: Peer authentication failed for user "my_group_worker"
>
> *** What am I doing wrong?
PostgreSQL uses
On 10/2/23 10:21, Wim Bertels wrote:
Tom Lane schreef op ma 02-10-2023 om 10:21 [-0400]:
Wim Bertels writes:
* but if you put more than 1 option, then it doesn't?:
#psql
postgresql://myuser@myserver/mydb?connect_timeout=10&target_session
_attrs=any
Maybe you forgot to quote that? Ampersand i
On 10/2/23 09:38, Douglas Reed wrote:
Hi guys
The servers are virtual running on Nutanix
We are running Pg version 12 (12.10)
On Linux km-data1.rs.fsbtech.com 5.4.191-1.el7.elrepo.x86_64 #1 SMP Tue
Apr 26 12:14:16 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux
48G/16 x CPU (Master and slave)
Time
Thank you for your answer.
вт, 3 окт. 2023 г., 17:22 MATSUO Takatoshi :
> It's not normal behavior.
>
> Pgsql RA is developed here.
> https://github.com/ClusterLabs/resource-agents/blob/main/heartbeat/pgsql
> You may get better advice if you ask on this mailing list.
> https://oss.clusterlabs.org
On Tuesday, October 3, 2023, Amn Ojee Uw wrote:
>
> Using the 'sudo -u postgres psql' command
>
> *psql -U my_group_worker -d my_group_db*
>
> *psql: error: connection to server on socket
> "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication
> failed for user "my_group_worker**
Hi,
I have a customer approaching transaction wraparound, about 3million
transaction IDs away at the moment.
Postgres 9.5 (yes, I know...)
Somewhat mislead by the message to vacuum the database in single user
mode, they are now in single user mode and are running "vacuum full"
on the "worst" data
It's not normal behavior.
Pgsql RA is developed here.
https://github.com/ClusterLabs/resource-agents/blob/main/heartbeat/pgsql
You may get better advice if you ask on this mailing list.
https://oss.clusterlabs.org/mailman/listinfo/users
2023年10月3日(火) 18:03 Sergey Cherukhin :
> I already have re
Dear All,I'd like to thank you for your excellent input on this problem. We
have now resolved this issue and I thought I would mention how. The topic of
the function being used as a check constraint had come up and I had rejected
this because it was the name given to a function which does some
Hi there.
Using the 'sudo -u postgres psql' command I created a group and two
accounts in the group, I also created a database for one of the
accounts. Now, I'd like to login PG-15, using my new account and
connecting to my new database, but PG-15 complains. See the example
below, I think it
On Tue, 3 Oct 2023 at 22:03, wrote:
> So one last question, should I expect the patch to land in version 17 only or
> is there chance that it will also be in lower versions right away?
It wouldn't ever be put into anything earlier than 17.
David
Thank you very much Laurenz and David. Looking forward to it and unfortunatelly
no, I am not in position to review that...
So one last question, should I expect the patch to land in version 17 only or
is there chance that it will also be in lower versions right away?
LJ
Sent with Proton Mai
On Tue, 2023-10-03 at 08:05 +, byme@byme.email wrote:
> "This obfuscates our monitoring because the same query with different amount
> of arguments gets translated into this:
> IN ($1, $2)
> and so on."
>
> The questions are:
> 1. Shouldnt IN behave so that the query in pg_stat_statements wou
I already have rep_mode set to "sync", but the primary node switches to
async mode only if the replica is shutted down correctly. When I shut down
the replica by powering it off to emulate power unit failure, primary
remains in sync mode until "pcs resource cleanup" is performed. I think it
is poss
On Tue, 3 Oct 2023 at 21:07, wrote:
> P.S.: The only serious discussion I was able to find about it was from 2015
> here, everyone basically stating that the improvement would be useful.
> https://postgrespro.com/list/thread-id/1880012
There is some active discussion and a patch which aims to i
Am 02.10.23 um 13:27 schrieb Matthias Apitz:
Hello,
One of our clients running our LMS on top of PostgreSQL 13.1 created a
ticket with these messages:
2023-09-30 16:50:50.951 CEST [18117] ERROR: deadlock detected
2023-09-30 16:50:50.951 CEST [18117] DETAIL: Process 18117 waits for ShareLoc
Thank you for response. Unfortunately, I have to update one section which I
wrote wrong, it should have
been this way:
"This obfuscates our monitoring because the same query with different amount of
arguments gets translated into this:
IN ($1, $2)
and so on."
The questions are:
1. Shouldnt IN b
On Tue, Oct 3, 2023 at 9:17 AM Laurenz Albe
wrote:
> On Tue, 2023-10-03 at 09:08 +0200, Dominique Devienne wrote:
> > In my case, it's OK not to be transactional, for these experiments. Is
> there a way
> > to lock the table and do the rewriting w/o generating any WAL? I don't
> have any experie
On Tue, 2023-10-03 at 09:08 +0200, Dominique Devienne wrote:
> In my case, it's OK not to be transactional, for these experiments. Is there
> a way
> to lock the table and do the rewriting w/o generating any WAL? I don't have
> any experience
> with unlogged tables, but should I take an exclusiv
On Tue, Oct 03, 2023 at 09:08:49AM +0200, Dominique Devienne wrote:
> In my case, it's OK not to be transactional, for these experiments. Is
> there a way
> to lock the table and do the rewriting w/o generating any WAL? I don't have
> any experience
> with unlogged tables, but should I take an exc
On Tue, Oct 3, 2023 at 6:45 AM Michael Paquier wrote:
> On Tue, Oct 03, 2023 at 06:31:27AM +0200, Laurenz Albe wrote:
> > On Tue, 2023-10-03 at 12:33 +1100, rob stone wrote:
> >> Would running CLUSTER on the table use the new parameters for the re-
> >> write?
> >
> > No, as far as I know.
>
> No
33 matches
Mail list logo
