On 21 April 2015 at 04:21, Dennis wrote:
> OK thanks. One of the motivations for asking these questions is that we
> are investigating ways to implement automated node removal from a VIP pool.
> We would like to be able to have the VIP management software (a dumb load
> balancer currently) be ab
On Mon, 2015-04-20 at 18:05 -0400, Bruce Momjian wrote:
> On Mon, Apr 20, 2015 at 03:02:48PM -0700, Adrian Klaver wrote:
> > >But pg_upgrade supports tablespaces, and I assume pg_dump/pg_restore do
> > >as well.
> > >
> >
> > I don't think it is about the underlying programs, it is about
> > te
On 04/20/2015 03:18 PM, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Mon, Apr 20, 2015 at 07:06:37PM -0300, Alvaro Herrera wrote:
ISTM there's a documentation bug here: in the code, the "dump" method
checks for tablespaces and raises an error if they are found, but the
"upgrade" method does no
Bruce Momjian wrote:
> On Mon, Apr 20, 2015 at 07:06:37PM -0300, Alvaro Herrera wrote:
> > ISTM there's a documentation bug here: in the code, the "dump" method
> > checks for tablespaces and raises an error if they are found, but the
> > "upgrade" method does not check. I think the documentation
On Mon, Apr 20, 2015 at 07:06:37PM -0300, Alvaro Herrera wrote:
> ISTM there's a documentation bug here: in the code, the "dump" method
> checks for tablespaces and raises an error if they are found, but the
> "upgrade" method does not check. I think the documentation should state
> that only the
ISTM there's a documentation bug here: in the code, the "dump" method
checks for tablespaces and raises an error if they are found, but the
"upgrade" method does not check. I think the documentation should state
that only the dump method does not support tablespaces.
Bruce Momjian wrote:
> On Mo
On Mon, Apr 20, 2015 at 03:02:48PM -0700, Adrian Klaver wrote:
> >But pg_upgrade supports tablespaces, and I assume pg_dump/pg_restore do
> >as well.
> >
>
> I don't think it is about the underlying programs, it is about
> teaching the wrapper script what do with the choices. Sort of like
> pgAdmi
On 04/20/2015 02:42 PM, Bruce Momjian wrote:
On Mon, Apr 20, 2015 at 02:41:09PM -0700, Adrian Klaver wrote:
On 04/20/2015 12:49 PM, Bruce Momjian wrote:
On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote:
For what it's worth: Debian provides a
pg_upgradecluster
tailored to its
On Mon, Apr 20, 2015 at 02:41:09PM -0700, Adrian Klaver wrote:
> On 04/20/2015 12:49 PM, Bruce Momjian wrote:
> >On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote:
> >>>For what it's worth: Debian provides a
> >>>
> >>> pg_upgradecluster
> >>>
> >>>tailored to its specific setup of Postgr
On 04/20/2015 12:49 PM, Bruce Momjian wrote:
On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote:
For what it's worth: Debian provides a
pg_upgradecluster
tailored to its specific setup of PostgreSQL clusters. That
has worked well for me across several major version bumps.
Karst
Another update (let me know if I'm mailing too much).
> 59.73% postmaster [kernel.kallsyms] [k]
> compaction_alloc
The compaction_alloc function seemed to point to issues with transparent
huge pages (THP.) I tried to turn this off with:
echo never > /sys/kernel/mm/transparen
OK thanks. One of the motivations for asking these questions is that we are
investigating ways to implement automated node removal from a VIP pool. We
would like to be able to have the VIP management software (a dumb load balancer
currently) be able to query the health of a particular node dire
On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote:
> > For what it's worth: Debian provides a
> >
> > pg_upgradecluster
> >
> > tailored to its specific setup of PostgreSQL clusters. That
> > has worked well for me across several major version bumps.
> >
> > Karsten
> >
>
> Indeed
On Mon, Apr 20, 2015 at 11:40 AM, David G. Johnston
wrote:
> On Mon, Apr 20, 2015 at 7:57 AM, Merlin Moncure wrote:
>>
>> On Sat, Apr 18, 2015 at 5:37 PM, Jim Nasby
>> wrote:
>> > On 4/18/15 12:47 AM, David G. Johnston wrote:
>> >>
>> >> If you could find a way to pass a value of type some_table
Would you be able to get a stack trace of a backend that's holding an
extension lock? Or maybe perf would provide some insight.
The outage occurred again but briefer. There were no ExclusiveLock
messages, presumably because the timeout for logging locks was not
exceeded. But all available c
På mandag 20. april 2015 kl. 20:27:39, skrev Jim Nasby mailto:jim.na...@bluetreble.com>>: [snip]
ISTM what would be better is allowing people to define new LO tables, so
we're not stuck trying to cram all LOs into a single table.
As for returning free space, that's a bit of a challenge period,
On 4/17/15 4:29 PM, Andreas Joseph Krogh wrote:
På fredag 17. april 2015 kl. 21:11:05, skrev Jim Nasby
mailto:jim.na...@bluetreble.com>>:
On 4/15/15 9:22 AM, Andreas Joseph Krogh wrote:
> På onsdag 15. april 2015 kl. 16:05:22, skrev Adam Hooper
> mailto:a...@adamhooper.com>>:
On Mon, Apr 20, 2015 at 9:40 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Apr 20, 2015 at 7:57 AM, Merlin Moncure
> wrote:
>
>> On Sat, Apr 18, 2015 at 5:37 PM, Jim Nasby
>> wrote:
>> > On 4/18/15 12:47 AM, David G. Johnston wrote:
>> >>
>> >> If you could find a way to p
On Mon, Apr 20, 2015 at 7:57 AM, Merlin Moncure wrote:
> On Sat, Apr 18, 2015 at 5:37 PM, Jim Nasby
> wrote:
> > On 4/18/15 12:47 AM, David G. Johnston wrote:
> >>
> >> If you could find a way to pass a value of type some_table into the
> >> function - instead of the name/text 'some_table‘ - you
On Sat, Apr 18, 2015 at 5:37 PM, Jim Nasby wrote:
> On 4/18/15 12:47 AM, David G. Johnston wrote:
>>
>> If you could find a way to pass a value of type some_table into the
>> function - instead of the name/text 'some_table‘ - you could possibly
>> use polymorphic pseudotypes...just imagining here
On 16 April 2015 at 23:58, Dennis wrote:
> I need some clarification on how to monitor BDR nodes. In particular
> determining replication lag. As an example, I have a two node cluster with
> nodes ‘A’ and ‘B’.I need to be able to look at node ‘B’ and determine if
> it is lagging behind n
21 matches
Mail list logo