[GENERAL] Problems with pg_upgrade.

Dear all, I’m trying to upgrade from 9.0 to 9.2 with out any success. the pg_upgrade script fails with the message Old and new cluster install users have different values for pg_authid.oid: geo-route-in:~ bror$ /opt/local//lib/postgresql92/bin/pg_upgrade -b /opt/local//lib/postgresql9

Re: [GENERAL] Problems with pg_upgrade.

Bror Jonsson writes: > I’m trying to upgrade from 9.0 to 9.2 with out any success. the pg_upgrade > script fails with the message Old and new cluster install users have > different values for pg_authid.oid: > geo-route-in:~ bror$ /opt/local//lib/postgresql92/bin/pg_upgrade -b > /opt/local//lib

Re: [GENERAL] Problems with pg_upgrade.

Thanks! Is there any way to figure out which the original superuser was? :-)B On Jul 29, 2014, at 12:41, Tom Lane wrote: > Bror Jonsson writes: >> I’m trying to upgrade from 9.0 to 9.2 with out any success. the pg_upgrade >> script fails with the message Old and new cluster install users

Re: [GENERAL] Problems with pg_upgrade.

On 7/29/2014 9:41 AM, Tom Lane wrote: Bror Jonsson writes: >I'm trying to upgrade from 9.0 to 9.2 with out any success. the pg_upgrade script fails with the message Old and new cluster install users have different values for pg_authid.oid: >geo-route-in:~ bror$/opt/local//lib/postgresql92/bin

Re: [GENERAL] Problems with pg_upgrade.

Bror Jonsson writes: > Is there any way to figure out which the original superuser was? You got a surplus of superusers? Anyway, it should be the one with OID 10. select * from pg_authid where oid = 10; regards, tom lane -- Sent via pgsql-general mailing list (pgsql

Re: [GENERAL] PG_TERMINATE_BACKEND not working.

Then same problem with you,and any idea? -- View this message in context: http://postgresql.1045698.n5.nabble.com/PG-TERMINATE-BACKEND-not-working-tp5732379p5812909.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-gener

[GENERAL] TZ_OFFSET

Hello, select TZ_OFFSET ('US/Eastern') from dual ; it's returning in oracle -- -04:00 but in postgres select TZ_OFFSET ('US/Eastern'); its'returning like function tz_offset('us/Eastern') does not exist; let me know how to solve issue

Re: [GENERAL] TZ_OFFSET

2014-07-28 13:19 GMT+03:00 Ramesh T : > select TZ_OFFSET ('US/Eastern'); > > its'returning like function tz_offset('us/Eastern') does not exist; > SELECT * FROM pg_catalog.pg_timezone_names WHERE name='US/Eastern'; -- Victor Y. Yegorov

[GENERAL] Is there any way to recover updated values from the table(Need old value)

Hi All, Is there any way to get history value in postgres database because in one table unfortunately we have updated value but we need old data check ,Is there any way to find old (Same table has updated multiple times),We need oldest data, please inform me is there any way to recover data? Tha

Re: [GENERAL] Is there any way to recover updated values from the table(Need old value)

On 7/29/2014 12:50 PM, gajendra s v wrote: Is there any way to get history value in postgres database because in one table unfortunately we have updated value but we need old data check ,Is there any way to find old (Same table has updated multiple times),We need oldest data, please inform me i

Re: [GENERAL] Is there any way to recover updated values from the table(Need old value)

On 7/29/2014 1:06 PM, gajendra s v wrote: Thanks for quick reply. Sorry I didnt get base backup means, but I have database dump of every day ,our database is in AWS EC2. so take a dump from before you overwrote the data you need, restore it to a scratch database, and copy out your data. -

Re: [GENERAL] tab_to_sting

Ramesh T wrote > Hi, > when i ran below statement its working fine.. >select string_agg(part_id::text,':') from part; > But, > SELECT tab_to_largeStringcheck(cast(string_agg(part_id::text,':')as > t_varchar2_tab)) FROM part > > > [image: Inline image 1] > > when i ran like > > SELECT > qa

Re: [GENERAL] Is there any way to recover updated values from the table(Need old value)

On 7/29/2014 1:29 PM, gajendra s v wrote: Sorry to disturb you again, I have imported old backup, is there any way to find how many times transaction has happened for 24 hrs duration to perticular table with update query because by mistakenly our java application has update different values one

[GENERAL] Joining on CTE is unusually slow?

I have a CTE that produces some row ids. I want to do a query with a complicated join based on those row ids. I've tried running them split into two (run CTE query, collect row ids, then run the complicated query with id IN (id_1, id_2, id_3)) and it takes only a few seconds to run, but when I run

Re: [GENERAL] Joining on CTE is unusually slow?

Jon Rosebaugh wrote > This takes over eight minutes to run. Is this the expected behavior when > joining on CTE expressions? > > I realize I haven't given the full schema/metadata/explain output as > explained in the "Slow Query Questions" wiki page You should at least provide some explain a/o ex

Re: [GENERAL] statement_timeout doesn't work

On Mon, Jul 21, 2014 at 11:32 AM, Sergey Konoplev wrote: > On Mon, Jul 21, 2014 at 10:16 AM, David G Johnston > wrote: >>> So, If I separate the commands everything will will work as expected, >>> correct? >> >> I would assume so. >> >> If you wait to send the DROP/ALTER index commands until the