On 12 Oct 2014, at 18:41, Arun Gokule arun.gok...@gmail.com 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 =
On Mon, Oct 13, 2014 at 12:11 AM, Stephen Davies sdav...@sdc.com.au 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
On Sun, Oct 12, 2014 at 9:11 PM, Stephen Davies 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 V9.3 environment.
I have used pg_dump and pg_restore (or postgis_restore.pl) as required by
the combination of
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 sdav...@sdc.com.au
mailto:sdav...@sdc.com.au wrote:
I am in the process of migrating several PostgreSQL databases from a
32-bit V9.1.4
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 sdav...@sdc.com.au wrote:
I have fixed this by manually granting access where necessary but wonder
whether the original issue is a bug or something that I
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
---
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
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
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
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
On Sat, Oct 11, 2014 at 5:01 AM, Adrian Klaver adrian.kla...@aklaver.com
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
11 matches
Mail list logo
