On 12/07/17 05:00, Steve Litt wrote:
Hi all,
Please tell me this is a mistake:
https://wiki.postgresql.org/wiki/Systemd
Why a database system should care about how processes get started is
beyond me. Systemd is an entangled mess that every year subsumes more
and more of the operating system, i
On 11 July 2017 at 05:49, Zhu, Joshua wrote:
> An update… after manually removing the record for ‘node4’ from
> bdr.bdr_nodes, corresponding record in bdr.bdr_connections, and associated
> replication slot (with pg_drop_replication_slot), rejoining was successful.
>
>
>
> I was under the impressi
Tom Lane wrote:
> "Hu, Patricia" writes:
>> The server and client encoding are both set to UTF8, and according to this
>> http://www.fileformat.info/info/unicode/char/2013/index.htm en dash is a
>> valid UTF8
>> character, but when running a script with insert statement with en dash
>> character
rihad wrote:
> Hi there. We have a working database that was unfortunately created by
> initdb with default ("C") collation & ctype. All other locale specific
> settings have the value en_US.UTF-8 in postgresql.conf. The database
> itself is multilingual and all its data is stored in UTF-8. Sorting
On Tue, Jul 11, 2017 at 9:51 PM, Steve Litt
wrote:
> Hi all,
>
> Please tell me this is a mistake:
>
> https://wiki.postgresql.org/wiki/Systemd
>
> Why a database system should care about how processes get started is
> beyond me. Systemd is an entangled mess that every year subsumes more
> and mo
Postgres 9.2
We have a POSTGRES database that we have been backing up via Incremental
backups.
We had an incident where we had to recover from backup. Our software vendor
has completed a restore and we have lost 10 days of data. There is no
explanation as to the reason we have sustained this loss
Thanks Laurenz, that nailed it. It was what Tom was saying, except I didn't
figure out how.
Thanks,
Patricia
-Original Message-
From: Albe Laurenz [mailto:laurenz.a...@wien.gv.at]
Sent: Wednesday, July 12, 2017 5:31 AM
To: 'Tom Lane *EXTERN*'; Hu, Patricia
Cc: pgsql general (pgsql-ge
On Wed, 12 Jul 2017, chris faber wrote:
I would appreciate the communities help in the following:
1. Determine if data from the incremental backups can be restored or
recovered.
2. Determine if data can be recovered from individual files backed up from
main Postgres data directory.
Chris,
chris faber wrote:
> Postgres 9.2
>
> We have a POSTGRES database that we have been backing up via Incremental
> backups.
You are talking of a physical base backup and WAL archives, right?
> We had an incident where we had to recover from backup. Our software vendor
> has completed
> a restore
Hi,
i have configure a master-replica replication with new pglogical 2.0.
I have to replicate data over MPLS/VPN, so there is a possibility that the
link temporarily interrupts.
I know that you have to be accurately estimated pg_xlog folder.
How can I handle the prolonged interruption of the link?
I just finished a point in time recovery from a rsync physical data file
backup + wal archive.Of course it works!You can also achieve the same goal
through pg_basebackup.
By your descriptions, your vendor seems to use logical backup through pg_dump.
Anyway you can only achieve no data loss thro
On 12 July 2017 at 00:51, Steve Litt wrote:
> Hi all,
>
> Please tell me this is a mistake:
>
> https://wiki.postgresql.org/wiki/Systemd
>
> Why a database system should care about how processes get started is
> beyond me. Systemd is an entangled mess that every year subsumes more
> and more of th
On 07/12/2017 01:54 PM, Albe Laurenz wrote:
rihad wrote:
Hi there. We have a working database that was unfortunately created by
initdb with default ("C") collation & ctype. All other locale specific
settings have the value en_US.UTF-8 in postgresql.conf. The database
itself is multilingual and a
rihad writes:
> On 07/12/2017 01:54 PM, Albe Laurenz wrote:
>> As you see, your index is still sorted according to the C collation
>> and scanning it returns wrong results.
> This ordering issue can certainly be classified as an inconsistency, but
> nothing to lose sleep over. Is this all that i
On 07/12/2017 09:31 PM, Tom Lane wrote:
rihad writes:
On 07/12/2017 01:54 PM, Albe Laurenz wrote:
As you see, your index is still sorted according to the C collation
and scanning it returns wrong results.
This ordering issue can certainly be classified as an inconsistency, but
nothing to lose
On 07/12/2017 09:31 PM, Tom Lane wrote:
rihad writes:
On 07/12/2017 01:54 PM, Albe Laurenz wrote:
As you see, your index is still sorted according to the C collation
and scanning it returns wrong results.
This ordering issue can certainly be classified as an inconsistency, but
nothing to lose
Thanks for the clarification.
Looks like I am running into a different issue: while trying to pin down
precisely the steps (and the order in which to perform them) needed to
remove/rejoin a node, the removal/rejoining exercise was repeated a number of
times, and stuck again:
1. The status
rihad writes:
> What if only English letters are used in the textual indices (ascii
> 0-127), would they still be impacted after datctype&datcollate
> "C"->"en_US.UTF-8" change?
Yes, as even minimal testing would have told you. C sort order is
more case-sensitive, for instance.
I think that none of the recovery information functions (
https://www.postgresql.org/docs/9.6/static/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE)
can distinguish a hot standby which is connected to an idle master, versus
one which is disconnected. For example, because the master has crashed
On 07/12/2017 11:25 PM, Tom Lane wrote:
rihad writes:
What if only English letters are used in the textual indices (ascii
0-127), would they still be impacted after datctype&datcollate
"C"->"en_US.UTF-8" change?
Yes, as even minimal testing would have told you. C sort order is
more case-sensi
On 13 July 2017 at 01:56, Zhu, Joshua wrote:
> Thanks for the clarification.
>
>
>
> Looks like I am running into a different issue: while trying to pin down
> precisely the steps (and the order in which to perform them) needed to
> remove/rejoin a node, the removal/rejoining exercise was repeate
21 matches
Mail list logo
