On 12 Oct 2014, at 18:41, Arun Gokule wrote:
> Hi,
>
> I am executing pg_advisory_locks using the following set of statements:
>
> SELECT pg_advisory_lock(317,2);
> UPDATE posts SET dislikers = array_remove(dislikers, 7) WHERE id = 317;
> update posts set num_dislikes = icount(dislikers), u
On Mon, Oct 13, 2014 at 12:11 AM, Stephen Davies wrote:
> I have fixed this by manually granting access where necessary but wonder
> whether the original issue is a bug or something that I have missed in the
> migration.
pg_dump emits the necessary GRANTs for the tables.
Did you use pg_dumpall -
On Sun, Oct 12, 2014 at 9:11 PM, Stephen Davies wrote:
> I am in the process of migrating several PostgreSQL databases from a
> 32-bit V9.1.4 environment to a 64-bit V9.3 environment.
>
> I have used pg_dump and pg_restore (or postgis_restore.pl) as required by
> the combination of version and wo
Nope. All went very smoothly apart from these grant issues.
On 14/10/14 01:57, Jeff Janes wrote:
On Sun, Oct 12, 2014 at 9:11 PM, Stephen Davies mailto:sdav...@sdc.com.au>> wrote:
I am in the process of migrating several PostgreSQL databases from a
32-bit V9.1.4 environment to a 64-bit
No. Just pg_dump and pg_restore/postgis_restore.pl.
On 13/10/14 22:24, Vick Khera wrote:
On Mon, Oct 13, 2014 at 12:11 AM, Stephen Davies wrote:
I have fixed this by manually granting access where necessary but wonder
whether the original issue is a bug or something that I have missed in the
m
On 10/13/2014 04:27 PM, Stephen Davies wrote:
Nope. All went very smoothly apart from these grant issues.
I think what Jeff was after was any error messages related to the grant
issues. I would expect that if users where granted access to tables and
where now denied, there would be an error o
---
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
---
BEGIN:VCARD
VERSION:3.0
N:Brewster;Israel;;;
FN:Israel Brewster
ORG:Frontier Flying Service
I no longer have the logs but I do not recall any errors during the restores.
The first I knew of the issue was when scripts started failing because access
was denied to some tables for the nominated user.
Due to other, non-PostgreSQL issues, I am going to have to repeat some of the
migration
On 10/13/2014 04:28 PM, Stephen Davies wrote:
No. Just pg_dump and pg_restore/postgis_restore.pl.
Roles(users) are global to a cluster so they will not be picked up by
pg_dump. You have the options of:
1) Using pg_dumpall to dump the entire cluster into a text file
http://www.postgresql.org
Thanks for that. I shall use it when I do the repeat migration.
Cheers,
Stephen
On 14/10/14 10:21, Adrian Klaver wrote:
On 10/13/2014 04:28 PM, Stephen Davies wrote:
No. Just pg_dump and pg_restore/postgis_restore.pl.
Roles(users) are global to a cluster so they will not be picked up by pg_d
On Sat, Oct 11, 2014 at 5:01 AM, Adrian Klaver
wrote:
> On 10/10/2014 10:41 AM, Nick Barnes wrote:
>
>
>> I understand why the FK insert needs to lock on the PK row. But why is
>> the PK delete trying to lock the FK row? If it finds one, won't the
>> delete fail anyway? If it doesn't find one, wh
11 matches
Mail list logo
