On Wed, Apr 11, 2012 at 5:40 PM, Bruce Momjian wrote:
> On Wed, Apr 04, 2012 at 07:26:58PM -0700, Harold Giménez wrote:
> > There could be incoming connections for a number of
> > reasons: either the user or the user's applications are reestablishing
> > connections, or something like collectd on
On Wed, Apr 04, 2012 at 07:26:58PM -0700, Harold Giménez wrote:
> Hi all,
>
> I've written a pg_upgrade wrapper for upgrading our users (heroku)
> to postgres 9.1. In the process I encountered a specific issue that
> could easily be improved. We've had this process work consistently
> for many use
On Sat, Apr 07, 2012 at 01:13:23PM +0300, Peter Eisentraut wrote:
> On ons, 2012-04-04 at 19:26 -0700, Harold Giménez wrote:
> > It would also be nice if the invocation of pg_ctl didn't pipe its
> > output to /dev/null. I'm sure it would contain information that would
> > directly point at the root
On ons, 2012-04-04 at 19:26 -0700, Harold Giménez wrote:
> It would also be nice if the invocation of pg_ctl didn't pipe its
> output to /dev/null. I'm sure it would contain information that would
> directly point at the root cause and could've saved some debugging and
> hand waving time.
This asp
On Thu, Apr 5, 2012 at 17:34, Tom Lane wrote:
> Stephen Frost writes:
>> * Andres Freund (and...@anarazel.de) wrote:
>>> Why would pipes be more useful? Its not like you could build useful
>>> pipelines
>>> with them.
>
>> The point is to avoid the risk that someone else could connect to the
>>
On Thursday, April 05, 2012 06:12:48 PM Tom Lane wrote:
> Andres Freund writes:
> > On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
> >> Yeah, that would be a small pain in the neck, but it eliminates a huge
> >> pile of practical difficulties, like your blithe assumption that you can
> >>
Andres Freund writes:
> On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
>> Yeah, that would be a small pain in the neck, but it eliminates a huge
>> pile of practical difficulties, like your blithe assumption that you can
>> find a "private directory" somewhere (wrong) or disallow access t
On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
> Andres Freund writes:
> >> The point is to avoid the risk that someone else could connect to the
> >> database at the same time you're doing work on it.
> >
> > I got that. I just fail to see what the advantage of using two pipes
> > inste
Andres Freund writes:
>> The point is to avoid the risk that someone else could connect to the
>> database at the same time you're doing work on it.
> I got that. I just fail to see what the advantage of using two pipes instead
> of one socket as every other plain connection would be?
Yeah, tha
Stephen Frost writes:
> * Andres Freund (and...@anarazel.de) wrote:
>> Why would pipes be more useful? Its not like you could build useful
>> pipelines
>> with them.
> The point is to avoid the risk that someone else could connect to the
> database at the same time you're doing work on it.
Rig
Hi,
Not sure if were just missing each others point?
On Thursday, April 05, 2012 05:20:04 PM Stephen Frost wrote:
> > Why would pipes be more useful? Its not like you could build useful
> > pipelines with them.
>
> The point is to avoid the risk that someone else could connect to the
> database
* Andres Freund (and...@anarazel.de) wrote:
> Hm. Changing libpq to use two pipes at the same time sounds considerably more
> invasive than basically just changing the socket creation and some minor
> details.
It's not something we'd back-patch, but I don't believe it'd be very
difficult to impl
On Thursday, April 05, 2012 04:44:11 PM Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > I wonder if it wouldn't be better to pass a named pipe under windows and
> > use a AF_UNIX socket everwhere else. Both should be pretty easily usable
> > with the existing code. PG already
* Andres Freund (and...@anarazel.de) wrote:
> I wonder if it wouldn't be better to pass a named pipe under windows and use
> a
> AF_UNIX socket everwhere else. Both should be pretty easily usable with the
> existing code. PG already seems to use named pipes under windows, so...
I didn't think T
On Thursday, April 05, 2012 03:46:54 PM Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane wrote:
> >> Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
> >> talking to a standalone backend, but nobody's gotten round to making
> >> that poss
Robert Haas writes:
> On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane wrote:
>> Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
>> talking to a standalone backend, but nobody's gotten round to making
>> that possible.
> Are you thinking about something like postgres --single
>
On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane wrote:
> Stephen Frost writes:
>> The single-user option *sounds* viable, but, iirc, it actually isn't due
>> to the limitations on what can be done in that mode.
>
> Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
> talking to a
Stephen Frost writes:
> The single-user option *sounds* viable, but, iirc, it actually isn't due
> to the limitations on what can be done in that mode.
Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
talking to a standalone backend, but nobody's gotten round to making
tha
Harold,
* Harold Giménez (harold.gime...@gmail.com) wrote:
> Possible workarounds on the current version:
This has actually been discussed before and unfortunately there aren't
any trivial solutions.
> * Rewrite pg_hba.conf temporarily while the pg_upgrade script runs to
> disallow any other con
Hi all,
I've written a pg_upgrade wrapper for upgrading our users (heroku) to
postgres 9.1. In the process I encountered a specific issue that could
easily be improved. We've had this process work consistently for many users
both internal and external, with the exception of just a few for whom the
20 matches
Mail list logo
