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 cause
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 users
On Wed, Apr 11, 2012 at 5:40 PM, Bruce Momjian br...@momjian.us 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
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 aspect
On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thursday, April 05, 2012 03:46:54 PM Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane t...@sss.pgh.pa.us 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
* 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
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 seems
* 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
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 at
Stephen Frost sfr...@snowman.net 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
Andres Freund and...@anarazel.de 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
On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
Andres Freund and...@anarazel.de 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
Andres Freund and...@anarazel.de 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
On Thursday, April 05, 2012 06:12:48 PM Tom Lane wrote:
Andres Freund and...@anarazel.de 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
On Thu, Apr 5, 2012 at 17:34, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net 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
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
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
Stephen Frost sfr...@snowman.net 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
20 matches
Mail list logo
