Uh...we also met duplicate rows with primary key column through restoring
database by pg_basebackup.
H.
I don't think its an issue with primary key index corruption.
2017-07-01 7:30 GMT+08:00 Adrian Klaver :
> On 06/30/2017 07:33 AM,
On 06/30/2017 07:33 AM, Timokhin Maxim wrote:
Sure, here it is.
pg_basebackup -h servername -R -P -D /data/upgrade/94 -U pgsql -v
—xlog-method=stream —checkpoint=fast
/usr/pgsql-9.5/bin/initdb -D /data/upgrade/95/ —encoding=utf8
—locale=ru_RU.utf8 —lc-collate=ru_RU.utf8 —lc-ctype=ru_RU.utf8
On 06/30/2017 11:35 AM, Niel Smith wrote:
Please reply to list also.
Ccing list.
Also to help with replies in the future could you change your posting
style to something like:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
Thanks.
What version of Postgres and where did you
You're right I have forgotten to say, the OS is RHEL 7.
Actually I'm reading about.
Thanks!
-
Dame un poco de fe, eso me bastará.
Rozvo Ware Solutions
--
View this message in context:
On Fri, Jun 30, 2017 at 11:36 AM, DrakoRod wrote:
> > Do you control the app?
>
> Nop Just I know how it's developed.
>
> > The app has a pooling component and you still are having problems, have
> > you looked at what the pooler is actually doing?
>
> As far as I know,
> Do you control the app?
Nop Just I know how it's developed.
> The app has a pooling component and you still are having problems, have
> you looked at what the pooler is actually doing?
As far as I know, the wildfly's jdbc pool. No really I don't know what are
doing. I suspect that problem
On Fri, Jun 30, 2017 at 9:07 AM, Adrian Klaver
wrote:
> On 06/30/2017 04:58 AM, Timokhin Maxim wrote:
>
>> BTW, we are moving using:
>>
>> pg_basebackup -h servername -R -P -D /data/upgrade/94 -U pgsql -v
>> —xlog-method=stream —checkpoint=fast
>>
>
> Going from 9.4 to
On 06/30/2017 04:58 AM, Timokhin Maxim wrote:
BTW, we are moving using:
pg_basebackup -h servername -R -P -D /data/upgrade/94 -U pgsql -v
—xlog-method=stream —checkpoint=fast
Going from 9.4 to 9.6 is a major version upgrade and you cannot use
pg_basebackup for that. Besides I can't see how
After setting seq_page_cost to 3 the execution plan became good, without
SeqScan, but it seems strange to set seq_page_cost almost equal to
random_page_cost, therefore i've set seq_page_cost back to defaults, increased
the statistics for "sub_id" in "mba_test.subscr_param" to 1000. That gave