Running a pg_upgrade task is causing Segmentation fault:
command: "/usr/lib/postgresql/9.3/bin/pg_dump" --host "/var/lib/postgresql"
--port 50432 --username "postgres" --schema-only --quote-all-identifiers
--binary-upgrade --format=custom --file="pg_upgrade_dump_6064585.custom"
"u" >> "pg_upgrade
Is there a way to rename an installed extension?
I have written an extension, but I don't like the name I originally chose,
and I would therefore like to rename it. However, it is installed on a
production system, from which it cannot be uninstalled, and I would like to
rename it there, too.
How
On Sat, Sep 14, 2013 at 6:32 AM, Moshe Jacobson wrote:
> How do I migrate my 9.1 directory to a new file system with the least
> downtime possible?
>
> I don't know if this makes any difference, but my pg_xlog directory is on
> its own volume as well, so I would have to unmount it and remount it a
On Sat, Sep 14, 2013 at 11:26 AM, CS DBA wrote:
> 3) before the swap do another rsync to bring the db as close to sync'ed as
> possible
>
> 4) shut down the primary db
>
> 5) do a final rsync (should have little to nothing to sync)
>
> 6) start the secondary db
>
Thanks. That's how I normally do
On 09/14/2013 08:51 AM, Kevin Grittner wrote:
Adrian Klaver wrote:
create table float_test (id int, f_fld double precision);
insert into float_test values (1, 6.31);
insert into float_test values (2, 6.32);
select * from float_test ;
id | f_fld
+---
1 | 6.31
2 | 6.32
(
Adrian Klaver wrote:
> create table float_test (id int, f_fld double precision);
> insert into float_test values (1, 6.31);
> insert into float_test values (2, 6.32);
> select * from float_test ;
>
> id | f_fld
> +---
> 1 | 6.31
> 2 | 6.32
> (2 rows)
If, instead of those insert
David Noel wrote:
> I've read through the documentation, found a few examples using
> "for update" syntax, and it looks like you're right. Would
> transaction level SERIALIZABLE also work? It does seem messier
> though, having to handle errors thrown due to concurrent
> transactions.
The SERIALI
We've done this across servers, maybe it would work for you:
1) rsync the entire db to the second file system
2) do another rsync each day until you are ready to swap (of course only
changed files will be moved)
3) before the swap do another rsync to bring the db as close to sync'ed
as possi
On Sat, Sep 14, 2013 at 9:40 AM, Michael Nolan wrote:
> Have you considered setting up a synchronously replicated slave database
> on the new file system (using a port other than 5432), getting it in sync,
> then shutting both databases down (master first), switching the slave over
> to become th
Have you considered setting up a synchronously replicated slave database on
the new file system (using a port other than 5432), getting it in sync,
then shutting both databases down (master first), switching the slave over
to become the master and restarting just that database on port 5432?
--
Mike
How do I migrate my 9.1 directory to a new file system with the least
downtime possible?
I don't know if this makes any difference, but my pg_xlog directory is on
its own volume as well, so I would have to unmount it and remount it as
well, but I would not have to copy over my xlogs.
I figure the
On 14/09/2013 04:31, Jov wrote:
> T
> he log shipping is useful when SR slave can not catch up the master and
> hungry enough to cause replication stop work.For example,when you want
> to stop the slave for a long time or do a large copy from,the
> wal_keep_segments on master reached，SR slave may n
Am 13.09.2013 um 18:47 schrieb David Noel :
>> ...have you used the "for update" clause in your select statements?
>
> Hi Ralf, thanks for the reply. I was unaware of the "for update"
> construct. Thank you!
>
>> My understanding is, that "for update" does what you need.
>
[...]
> My question
>
>Symbolic links being used.
>It also creates batch file that could be used to delete old cluster after
>upgrade.
>It's all in the docs.
>
>Regards,
>Igor Neyman
I see, it should be this step:
Delete old cluster
Once you are satisfied with the upgrade, you can delete the old cluster's data
d
Oh sorry, it is typo. It should be Igor Neyman.
It was 3AM in my timezone and I was sleepy.
From: Ivan Voras
To: Patrick Dung
Cc: Stephen Frost ; "pgsql-general@postgresql.org"
; Tom Lane
Sent: Saturday, September 14, 2013 4:08 AM
Subject: Re: [GENERAL] Ma
On Fri, Sep 13, 2013 at 10:00 PM, Bill Moran wrote:
>
> Looking at using LDAP to ease the pain of maintaining user accounts across
> many tens of PostgreSQL servers ...
>
> As documented, LDAP solves a few of the problems we have -- since everyone
> will be in LDAP, we can use LDAP's password comp
16 matches
Mail list logo
