00100870019
full backup: 20240829-105625F
timestamp start/stop: 2024-08-29 18:53:32+05:30 / 2024-08-29
20:24:13+05:30
wal start/stop: 000100860063 /
000100860074
database size: 146.9GB, database backup size: 146.9GB
As always, thanks very much for the confirmation.
On Fri, Aug 30, 2024 at 12:18 PM Tom Lane wrote:
> Morris de Oryx writes:
> > From what I've seen in the wild, and can sort out from the source, I
> think
> > that ltree does *not* need to load rows from heap.
>
> The comment in ltree_consistent
Morris de Oryx writes:
> From what I've seen in the wild, and can sort out from the source, I think
> that ltree does *not* need to load rows from heap.
The comment in ltree_consistent is pretty definitive:
/* All cases served by this function are exact */
*recheck = false;
> I
I'm trying to determine if an ltree GiST index search *ever *needs to load
a row out of heap for a recheck, of if the index entry itself includes
enough information for a definitive answer. I believe that this is
controlled by the recheck flag in the consistency function.
>From what I've seen in t
On Fri, 30 Aug 2024 at 11:18, Rumpi Gravenstein wrote:
>
> Which returns:
> logical_partition_keyusage_texttxtrpo_txtindxmx_indxprvnxtnxt2prv2prv3
> "TEST_DATA"
> "F(T61)(EXPORT)" "F(T61)(EXPORT)" "F" "1" "7" *"F"* "(" "(" "[NULL]"
> "[NULL]"
> "TEST_DATA"
> "F(T61)(EXPORT)" "F(T61)(EXPORT)" "("
Rumpi Gravenstein writes:
> Is this a PostgreSQL bug?
Maybe, but you haven't provided enough information to let anyone else
reproduce the behavior.
Personally I'm suspicious that because your lag() calls are over
partition by p.logical_partition_key, p.txt order by indx
but then you filter
Experts,
I am running on
PostgreSQL 14.13 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0
20210514 (Red Hat 8.5.0-22), 64-bit
I have the following query which returns what I expect:
with
d(logical_partition_key, model_usage) as ( values( 'TEST_DATA' ,
'F(T61)(EXPORT)' )
)
,
usg_txt as
oserver.
>>>
>> ...
>>
>>> If so, does the backup process start again from scratch ? or it
>>> resumes from where the backup process is stopped ?
>>>
>>
>> It resumes. You will see a message like this:
>>
>> WARN: res
List,
I am doing a full backup using PgBackRest from a production server to
Reposerver.
My connection is IPSec VPN over ILL ( 8 Mbps link) between the
Production DB Server and the remote RepoServer.
I understood the bottleneck of 8 Mbps between servers. (Server NICs 10Gbps
and switch 10G)
m scratch ? or it
>> resumes from where the backup process is stopped ?
>>
>
> It resumes. You will see a message like this:
>
> WARN: resumable backup 20240829-091727F of same type exists -- invalid
> files will be removed then the backup will resume
>
> Any
On Thu, Aug 29, 2024 at 10:12 AM Greg Sabino Mullane
wrote:
> On Thu, Aug 29, 2024 at 9:31 AM KK CHN wrote:
>
>> "Unable to acquire lock on file '/tmp/pgbackrest/Repo-backup.lock'
>>
>
> When this happens, take a look inside this file. If there is another
> pgbackrest process running, the pid wi
On Thu, Aug 29, 2024 at 9:31 AM KK CHN wrote:
> "Unable to acquire lock on file '/tmp/pgbackrest/Repo-backup.lock'
>
When this happens, take a look inside this file. If there is another
pgbackrest process running, the pid will be inside that file. Kill that
process before trying to run another b
Thanks for the reply, Tom.
Makes sense to me.
Worth saying - one very large misunderstanding that was pointed out to me was
that the position limit is not per character - it is per word. This makes sense
given the parser parses per word - but I completely missed it. It basically
completely cha
r the requested immediate checkpoint completes
2024-08-29 16:38:18.003 P00 INFO: backup start archive =
00010085009A, lsn = 85/9AD8
2024-08-29 16:38:18.003 P00 INFO: check archive for prior segment
000100850099
WARN: resumable backup 20240829-105625F of same type exi
es. You will see a message like this:
WARN: resumable backup 20240829-091727F of same type exists -- invalid
files will be removed then the backup will resume
Any suggestions much appreciated
>
Boost your process-max as high as you are able to speed up your backup time.
Cheers,
Greg
15 matches
Mail list logo
