On Fri, Dec 6, 2013 at 04:04:36PM +0100, Andres Freund wrote:
On 2013-12-05 23:01:28 +0200, Heikki Linnakangas wrote:
On 12/05/2013 10:37 PM, Robert Haas wrote:
On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It might be unpleasant to use in some cases, though.
Why
On 2013-12-05 23:01:28 +0200, Heikki Linnakangas wrote:
On 12/05/2013 10:37 PM, Robert Haas wrote:
On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It might be unpleasant to use in some cases, though.
Why would there be more than a few cases in the first place? Who is
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-05 23:01:28 +0200, Heikki Linnakangas wrote:
Right. Not all of the parameters will make sense for a stand-alone backend
though, like the hostname and port number. And I think you need need a new
parameter to pass the path to the
On 2013-12-06 11:02:48 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
My feeling is that we should just treat the executable name and data
directory path as new connection parameters, which'd be ignored in
normal-connection mode, just as some other parameters will be
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-06 11:02:48 -0500, Tom Lane wrote:
I think the special-purpose command line switches you mention can be
passed through PGOPTIONS, rather than inventing a new parameter -- do you
have an objection to that?
I am not sure if they currently
On 5 December 2013 01:55, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2013-11-14 at 12:11 +0530, Amit Kapila wrote:
If an application wants to allow these connection parameters to be
used, it would need to do PQenableStartServer() first. If it doesn't,
those connection parameters will
On 2013-12-04 20:55:08 -0500, Peter Eisentraut wrote:
On Thu, 2013-11-14 at 12:11 +0530, Amit Kapila wrote:
If an application wants to allow these connection parameters to be
used, it would need to do PQenableStartServer() first. If it doesn't,
those connection parameters will be
On 12/5/13, 6:07 AM, Simon Riggs wrote:
On 5 December 2013 01:55, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2013-11-14 at 12:11 +0530, Amit Kapila wrote:
If an application wants to allow these connection parameters to be
used, it would need to do PQenableStartServer() first. If it
I think this proposal is a bit deadlocked now.
- There are technical concerns about launching a server executable from
within a client.
- There are conceptual concerns about promoting an embedded database mode.
On the other hand:
- Everyone would like to have a way to use psql (and other basic
On 2013-12-05 11:39:29 -0500, Peter Eisentraut wrote:
I think this proposal is a bit deadlocked now.
- There are technical concerns about launching a server executable from
within a client.
- There are conceptual concerns about promoting an embedded database mode.
On the other hand:
On Thu, Dec 5, 2013 at 11:52 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-12-05 11:39:29 -0500, Peter Eisentraut wrote:
I think this proposal is a bit deadlocked now.
- There are technical concerns about launching a server executable from
within a client.
- There are conceptual
Robert Haas robertmh...@gmail.com writes:
Yeah, seriously. I don't understand what the big deal is here. The
right design here is 99.44% clear here, and the committer (presumably
Tom) can handle the other 0.56% however he'd like. Let's do this and
move on.
Yeah, but the remaining 0.56% is
On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm pretty much persuaded by Andres' point that we should not allow a
child process to be launched under a client app without clear permission
from the code of the app (and *not* just some environment variable that
might have
On 12/05/2013 10:37 PM, Robert Haas wrote:
On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It might be unpleasant to use in some cases, though.
Why would there be more than a few cases in the first place? Who is
going to use this beyond psql, pg_dump(all), and pg_upgrade,
On Thu, 2013-11-14 at 12:11 +0530, Amit Kapila wrote:
If an application wants to allow these connection parameters to be
used, it would need to do PQenableStartServer() first. If it doesn't,
those connection parameters will be rejected.
Stupid idea: Would it work that we require an
On Thu, Dec 5, 2013 at 7:25 AM, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2013-11-14 at 12:11 +0530, Amit Kapila wrote:
If an application wants to allow these connection parameters to be
used, it would need to do PQenableStartServer() first. If it doesn't,
those connection parameters
On Thu, 2013-12-05 at 09:02 +0530, Amit Kapila wrote:
This is certainly not a stupid idea, rather something on similar lines
has been discussed previously in this thread.
Tom has suggested something similar, but I am not sure if there was a
conclusion on that point. Please see the
relavant
On Thu, Nov 21, 2013 at 9:54 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Nov 21, 2013 at 8:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
Here what I have in mind is that:
Why would you make psql behave differently from our other command-line
On Thu, Nov 21, 2013 at 8:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
Here what I have in mind is that:
a. In pg_dump or other internal utilities where we want to use this
feature, they should call PQenableStart() or some other API before
calling
Amit Kapila amit.kapil...@gmail.com writes:
Here what I have in mind is that:
a. In pg_dump or other internal utilities where we want to use this
feature, they should call PQenableStart() or some other API before
calling PQConnect() which will indicate that it wants to operate
as a
On Thu, Nov 21, 2013 at 9:11 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Nov 21, 2013 at 2:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
The argument elsewhere in this thread was that the reason for putting
this in the connection options was so
On 11/14/13, 1:41 AM, Amit Kapila wrote:
Security Concern
-
If a user can specify libpq connection options, he can now execute
any file he wants by passing it as standalone_backend.
Method to resolve Security concern
Peter Eisentraut pete...@gmx.net writes:
I would consider sidestepping this entire issue by having the
stand-alone backend create a Unix-domain socket and have a client
connect to that in the normal way.
Hmm. But that requires the stand-alone backend to take on at least
some properties of a
On 2013-11-20 10:48:20 -0500, Tom Lane wrote:
constraining what can be executed as a standalone backend. Would
it work to insist that psql/pg_dump launch the program named postgres
from the same bin directory they're in, rather than accepting a path
from the connection string?
But why do we
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-20 10:48:20 -0500, Tom Lane wrote:
constraining what can be executed as a standalone backend. Would
it work to insist that psql/pg_dump launch the program named postgres
from the same bin directory they're in, rather than accepting a
On 2013-11-20 11:08:33 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-20 10:48:20 -0500, Tom Lane wrote:
constraining what can be executed as a standalone backend. Would
it work to insist that psql/pg_dump launch the program named postgres
from the same
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think we'd be better off trying to fix the security issue by
constraining what can be executed as a standalone backend. Would
it work to insist that psql/pg_dump launch the program named postgres
from the same bin directory they're in, rather than
On 2013-11-20 17:19:42 +0100, Andres Freund wrote:
That just pushes the problem up a level --- how are you going to tell
psql, pg_dump, or other programs that they should do that?
An explicit parameter. A program imo explicitly needs to be aware that a
PQconnect() suddenly starts forking
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-20 11:08:33 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Something like PQstartSingleUser(dsn) returning a established connection
seems better to me.
That just pushes the problem up a level --- how are you going
On 11/20/13, 11:31 AM, Stephen Frost wrote:
Couldn't that be an issue for people who have multiple major versions of
binaries installed? In particular, the default on the system for psql
might be 9.3 while the cluster you're trying to recover may be 9.2. Of
course, in that case you might say
On 11/20/13, 10:48 AM, Tom Lane wrote:
Perhaps more to the point, I think this approach actually breaks one of
the principal good-thing-in-emergencies attributes of standalone mode,
namely being sure that nobody but you can connect. With this, you're
right back to having a race condition as
On Wed, Nov 20, 2013 at 10:13 AM, Peter Eisentraut pete...@gmx.net wrote:
On 11/14/13, 1:41 AM, Amit Kapila wrote:
Security Concern
-
If a user can specify libpq connection options, he can now execute
any file he wants by passing it as standalone_backend.
On 11/20/13, 3:24 PM, Robert Haas wrote:
The point is that client applications should expose whether or not to
set this function as a command-line switch separate from whatever they
accept in terms of connection strings. So pg_dump should have a flag
called --standalone-server or something
On Wed, Nov 20, 2013 at 3:32 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/20/13, 3:24 PM, Robert Haas wrote:
The point is that client applications should expose whether or not to
set this function as a command-line switch separate from whatever they
accept in terms of connection strings.
Peter Eisentraut pete...@gmx.net writes:
The argument elsewhere in this thread was that the reason for putting
this in the connection options was so that you do *not* have to patch up
every client to be able to use this functionality. If you have to add
separate options everywhere, then you
On Wed, Nov 20, 2013 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
To my mind, the create a socket and hope nobody else can get to it
approach is exactly one of the main things we're trying to avoid here.
If you'll recall, awhile back we had a big discussion about how pg_upgrade
could
On 2013-11-20 15:44:03 -0500, Tom Lane wrote:
In practice, as long as psql and pg_dump and pg_upgrade can do it, I
think we've covered most of the interesting bases.
I'd say vacuumdb/reindexdb should be added to that list. In my
experience xid wraparound and corrupted system indexes are the
On Wed, Nov 20, 2013 at 05:38:14PM -0500, Gurjeet Singh wrote:
On Wed, Nov 20, 2013 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
To my mind, the create a socket and hope nobody else can get to it
approach is exactly one of the main things we're trying to avoid here.
If you'll
On Thu, Nov 21, 2013 at 2:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
The argument elsewhere in this thread was that the reason for putting
this in the connection options was so that you do *not* have to patch up
every client to be able to use this
On Fri, Nov 15, 2013 at 6:51 AM, Simon Riggs si...@2ndquadrant.com wrote:
Not enough. This feature is clearly being suggested as a way to offer
Postgres in embedded mode for users by a back door. Doing that forces
us to turn off many of the server's features and we will take a huge
step
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 15, 2013 at 6:51 AM, Simon Riggs si...@2ndquadrant.com wrote:
Not enough. This feature is clearly being suggested as a way to offer
Postgres in embedded mode for users by a back door. Doing that forces
us to turn off many of the server's
On Fri, Nov 15, 2013 at 5:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 14 November 2013 03:41, Amit Kapila amit.kapil...@gmail.com wrote:
I have gone through the mail chain of this thread and tried to find
the different concerns or open ends for this patch.
Not enough. This feature is
On 14 November 2013 03:41, Amit Kapila amit.kapil...@gmail.com wrote:
I have gone through the mail chain of this thread and tried to find
the different concerns or open ends for this patch.
Not enough. This feature is clearly being suggested as a way to offer
Postgres in embedded mode for
On 2013-11-15 09:51:28 -0200, Simon Riggs wrote:
On 14 November 2013 03:41, Amit Kapila amit.kapil...@gmail.com wrote:
I have gone through the mail chain of this thread and tried to find
the different concerns or open ends for this patch.
Not enough. This feature is clearly being
Andres Freund and...@2ndquadrant.com writes:
I think fixing single user mode to work halfway reasonable is enough
justification for the feature. Having to deal with that when solving
critical issues is just embarassing.
+1
But: I very, very much agree with the other concerns around this.
On 15 November 2013 09:00, Andres Freund and...@2ndquadrant.com wrote:
This
should be a patch to fix single user mode, not one to make postgres into
a single process database.
+1
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
On Fri, Nov 15, 2013 at 6:06 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
But: I very, very much agree with the other concerns around this. This
should be a patch to fix single user mode, not one to make postgres into
a single process database. It's not, and trying to make it by using
I have gone through the mail chain of this thread and tried to find
the different concerns or open ends for this patch.
Summarisation of the discussion and concerns for this patch:
1. Security concern in interface
2. Security concern in Windows implementation
3. Handling of Ctrl-C/SIGTERM
4.
Amit Kapila amit.kapil...@gmail.com writes:
Any objections for adding this idea/patch to CF?
You should certainly add it to the CF. You've listed lots of matters
for review, but that's no reason to not get it in the queue to be
reviewed.
regards, tom lane
--
Sent via
On 2012-11-12 19:21:28 +, Simon Riggs wrote:
On 10 September 2012 17:50, Tom Lane t...@sss.pgh.pa.us wrote:
The point of the proposal that I am making is to have a simple,
low-maintenance solution for people who need a single-application
database. A compromise somewhere in the middle
On 13 November 2012 06:14, Amit kapila amit.kap...@huawei.com wrote:
I get the installability thang, very very much, I just don't see the
single process thing as the only solution. At very least an open
minded analysis of the actual problem and ways of solving it is called
for, not just reach for
Simon Riggs escribió:
So even if this solution doesn't meet all requirements of single
process solution (and neither I think it is written to address all)
but can't we think of it as first version and then based on
requirements extend it to have other capabilities:
a. to have a mechnism
On 13 November 2012 13:05, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Simon Riggs escribió:
So even if this solution doesn't meet all requirements of single
process solution (and neither I think it is written to address all)
but can't we think of it as first version and then based on
Simon Riggs si...@2ndquadrant.com writes:
The most popular relational database in the world is Microsoft Access,
not MySQL. Access appears desirable because it allows a single user to
create and use a database (which is very good). But all business
databases have a requirement for at least one
On Tue, Nov 13, 2012 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
The most popular relational database in the world is Microsoft Access,
not MySQL. Access appears desirable because it allows a single user to
create and use a database (which is very
On 13 November 2012 17:38, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
The most popular relational database in the world is Microsoft Access,
not MySQL. Access appears desirable because it allows a single user to
create and use a database (which is very good).
Simon Riggs si...@2ndquadrant.com writes:
On 13 November 2012 17:38, Tom Lane t...@sss.pgh.pa.us wrote:
... The fact of the matter is that there is *lots* of demand
for simple single-user databases, and what I'm proposing is at least a
first step towards getting there.
I agree there is lots
Preface: I think there's some great commentary here, and find myself
agreeing
pretty whole-heartedly.
On Tue, Nov 13, 2012 at 2:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 13 November 2012 17:38, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
The most
Tom Lane t...@sss.pgh.pa.us writes:
I agree there is lots of demand for simple single-user databases and I
wish that too. What I don't agree with is something that casts that
requirement in stone by architecturally/permanently disallowing
secondary connections.
If you want secondary
On Fri, Sep 14, 2012 at 6:42 AM, Amit kapila amit.kap...@huawei.com wrote:
On Tuesday, September 11, 2012 7:07 PM Amit Kapila wrote:
On Monday, September 10, 2012 8:20 PM Amit Kapila wrote:
On Sunday, September 09, 2012 1:37 PM Amit Kapila wrote:
On Friday, September 07, 2012 11:19 PM Tom Lane
On 10 September 2012 17:50, Tom Lane t...@sss.pgh.pa.us wrote:
The point of the proposal that I am making is to have a simple,
low-maintenance solution for people who need a single-application
database. A compromise somewhere in the middle isn't likely to be an
improvement for anybody. For
On Mon, Nov 12, 2012 at 1:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 10 September 2012 17:50, Tom Lane t...@sss.pgh.pa.us wrote:
The point of the proposal that I am making is to have a simple,
low-maintenance solution for people who need a single-application
database. A compromise
On 12 November 2012 21:26, Merlin Moncure mmonc...@gmail.com wrote:
I couldn't disagree more. The patch is small, logical, and fixes an
awful problem, namely that --single mode is basically unusable. As to
your wider point (namely, that you can't connect to it, therefore it's
bad), it has
On Monday, November 12, 2012 8:31 PM Merlin Moncure wrote:
On Fri, Sep 14, 2012 at 6:42 AM, Amit kapila amit.kap...@huawei.com wrote:
On Tuesday, September 11, 2012 7:07 PM Amit Kapila wrote:
On Monday, September 10, 2012 8:20 PM Amit Kapila wrote:
On Sunday, September 09, 2012 1:37 PM Amit
On Tuesday, November 13, 2012 3:11 AM Simon Riggs wrote:
On 12 November 2012 21:26, Merlin Moncure mmonc...@gmail.com wrote:
I couldn't disagree more. The patch is small, logical, and fixes an
awful problem, namely that --single mode is basically unusable. As to
your wider point (namely,
On Tuesday, September 11, 2012 7:07 PM Amit Kapila wrote:
On Monday, September 10, 2012 8:20 PM Amit Kapila wrote:
On Sunday, September 09, 2012 1:37 PM Amit Kapila wrote:
On Friday, September 07, 2012 11:19 PM Tom Lane wrote:
Heikki Linnakangas hlinn...@iki.fi writes:
Would socketpair(2) be
On Monday, September 10, 2012 8:20 PM Amit Kapila wrote:
On Sunday, September 09, 2012 1:37 PM Amit Kapila wrote:
On Friday, September 07, 2012 11:19 PM Tom Lane wrote:
Heikki Linnakangas hlinn...@iki.fi writes:
Would socketpair(2) be simpler?
I've not done anything yet about the potential
On Sunday, September 09, 2012 1:37 PM Amit Kapila wrote:
On Friday, September 07, 2012 11:19 PM Tom Lane wrote:
Heikki Linnakangas hlinn...@iki.fi writes:
Would socketpair(2) be simpler?
I've not done anything yet about the potential security issues
associated with untrusted libpq connection
On Sun, Sep 2, 2012 at 8:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Notably, while the lack of any background processes is just what you want
for pg_upgrade and disaster recovery, an ordinary application is probably
going to want to rely on autovacuum; and we need bgwriter and other
background
On Mon, Sep 10, 2012 at 11:12 AM, Gurjeet Singh singh.gurj...@gmail.com wrote:
On Sun, Sep 2, 2012 at 8:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Notably, while the lack of any background processes is just what you want
for pg_upgrade and disaster recovery, an ordinary application is probably
On 10.09.2012 18:12, Gurjeet Singh wrote:
On Sun, Sep 2, 2012 at 8:23 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Notably, while the lack of any background processes is just what you want
for pg_upgrade and disaster recovery, an ordinary application is probably
going to want to rely on autovacuum;
On Mon, Sep 10, 2012 at 11:43 AM, Heikki Linnakangas hlinn...@iki.fiwrote:
On 10.09.2012 18:12, Gurjeet Singh wrote:
On Sun, Sep 2, 2012 at 8:23 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Notably, while the lack of any background processes is just what you want
for pg_upgrade and disaster
Gurjeet Singh singh.gurj...@gmail.com writes:
On Mon, Sep 10, 2012 at 11:43 AM, Heikki Linnakangas hlinn...@iki.fiwrote:
[scratches head] How's that different from the normal postmaster mode?
As I described in later paragraphs, it'd behave like an embedded database,
like SQLite etc., so the
The point of the proposal that I am making is to have a simple,
low-maintenance solution for people who need a single-application
database. A compromise somewhere in the middle isn't likely to be an
improvement for anybody. For instance, if you want to have additional
connections, you open
Josh Berkus j...@agliodbs.com wrote:
In fact, most of the folks who would want an embedded PostgreSQL
either want no authentication at all, or only a single password.
So supporting authentication options other than trust or md5 is
not required, or desired AFAIK.
I don't know whether it's
On Mon, Sep 10, 2012 at 9:59 AM, Josh Berkus j...@agliodbs.com wrote:
The point of the proposal that I am making is to have a simple,
low-maintenance solution for people who need a single-application
database. A compromise somewhere in the middle isn't likely to be an
improvement for
On Friday, September 07, 2012 11:19 PM Tom Lane wrote:
Heikki Linnakangas hlinn...@iki.fi writes:
Would socketpair(2) be simpler?
I've not done anything yet about the potential security issues
associated with untrusted libpq connection strings. I think this
is still at the proof-of-concept
Amit kapila amit.kap...@huawei.com writes:
1. does this follow the behavior that admin users will not be allowed to
invoke postgres child process?
That's an interesting question. I'm not sure if we'd want to disable
the no-root check on the Unix side, but it might make sense to. But
this has
Hi,
On Wednesday, September 05, 2012 06:00:18 PM Tom Lane wrote:
anara...@anarazel.de and...@anarazel.de writes:
I am not saying its bad that it is slower, that's absolutely OK. Just
that it will take a variable amount of time till you can run pgdump
again and its not easily detectable
On Sunday, September 09, 2012 8:46 PM Tom Lane wrote:
Amit kapila amit.kap...@huawei.com writes:
1. does this follow the behavior that admin users will not be allowed to
invoke postgres child process?
That's an interesting question. I'm not sure if we'd want to disable
the no-root check on
A Dijous, 6 de setembre de 2012 00:30:53, Josh Berkus va escriure:
In general I think the selling point for such a feature would be no
administrative hassles, and I believe that has to go not only for the
end-user experience but also for the application-developer experience.
If you have to
Heikki Linnakangas hlinn...@iki.fi writes:
Would socketpair(2) be simpler?
Attached is a revised version of the patch that uses socketpair(2).
This is definitely a lot less invasive --- the backend side of the
patch, in particular, is far shorter, and there are fewer portability
hazards since
On 07.09.2012 10:49, Tom Lane wrote:
Heikki Linnakangashlinn...@iki.fi writes:
Would socketpair(2) be simpler?
Attached is a revised version of the patch that uses socketpair(2).
This is definitely a lot less invasive --- the backend side of the
patch, in particular, is far shorter, and
Heikki Linnakangas hlinn...@iki.fi writes:
It's worth noting that now that libpq constructs the command line to
execute postgres --child= -D datadir, we'll be stuck with that set
of arguments forever, because libpq needs to be able to talk to
different versions. Or at least we'd need to
Heikki Linnakangas hlinn...@iki.fi writes:
On 07.09.2012 10:49, Tom Lane wrote:
I'm a bit tempted though to pull out and apply the portions of the
patch that replace libpq's assorted ad-hoc closesocket() calls with
a centralized pqDropConnection routine. I think that's probably a good
idea
On Thu, Sep 6, 2012 at 12:56 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2012-09-05 at 17:03 -0400, Tom Lane wrote:
In general I think the selling point for such a feature would be no
administrative hassles, and I believe that has to go not only for the
end-user experience but also for the
On Friday, September 07, 2012 11:21:00 PM Merlin Moncure wrote:
On Thu, Sep 6, 2012 at 12:56 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2012-09-05 at 17:03 -0400, Tom Lane wrote:
In general I think the selling point for such a feature would be no
administrative hassles, and I believe
On 9/2/12 7:23 PM, Tom Lane wrote:
4. As coded, the backend assumes the incoming pipe is on its FD 0 and the
outgoing pipe is on its FD 1. This made the command line simple but I'm
having second thoughts about it: if anything inside the backend tries to
read stdin or write stdout, unpleasant
On Wed, Sep 5, 2012 at 10:29 PM, Andrew Dunstan and...@dunslane.net wrote:
On 09/05/2012 10:14 PM, Tom Lane wrote:
The people who would be interested in this are currently using something
like SQLite within a single application program.
Exactly. I think it's worth stating that this has
On Wed, 2012-09-05 at 17:03 -0400, Tom Lane wrote:
In general I think the selling point for such a feature would be no
administrative hassles, and I believe that has to go not only for the
end-user experience but also for the application-developer experience.
If you have to manage
On Wed, Sep 5, 2012 at 7:31 AM, Amit Kapila amit.kap...@huawei.com wrote:
On Tuesday, September 04, 2012 12:40 AM Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Sep 3, 2012 at 8:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I have another question after thinking about that for
On Wednesday, September 05, 2012 3:58 PM Magnus Hagander wrote:
On Wed, Sep 5, 2012 at 7:31 AM, Amit Kapila amit.kap...@huawei.com wrote:
On Tuesday, September 04, 2012 12:40 AM Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Sep 3, 2012 at 8:51 PM, Tom Lane
On Tuesday, September 04, 2012 12:11:28 PM Amit Kapila wrote:
On Tuesday, September 04, 2012 11:00 AM Andres Freund wrote:
On Tuesday, September 04, 2012 06:20:59 AM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I can see why that would be nice, but is it really realistic?
Andres Freund and...@2ndquadrant.com writes:
I don't find that a convincing comparison. Normally don't need to shutdown
the
server between two pg_dump commands. Which very well might be scripted.
Especially as for now, without a background writer/checkpointer writing stuff
beforehand, the
anara...@anarazel.de and...@anarazel.de writes:
I am not saying its bad that it is slower, that's absolutely OK. Just that it
will take a variable amount of time till you can run pgdump again and its not
easily detectable without looping and trying again.
Well, that's why the proposed libpq
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@2ndquadrant.com writes:
I don't find that a convincing comparison. Normally don't need to
shutdown the
server between two pg_dump commands. Which very well might be
scripted.
Especially as for now, without a background
Tom,
However, there are some additional things
we'd need to think about before advertising it as a fit solution for that.
Notably, while the lack of any background processes is just what you want
for pg_upgrade and disaster recovery, an ordinary application is probably
going to want to rely
Josh Berkus j...@agliodbs.com writes:
However, there are some additional things
we'd need to think about before advertising it as a fit solution for that.
Notably, while the lack of any background processes is just what you want
for pg_upgrade and disaster recovery, an ordinary application is
On Wed, Sep 5, 2012 at 01:50:06PM -0700, Josh Berkus wrote:
Tom,
However, there are some additional things
we'd need to think about before advertising it as a fit solution for that.
Notably, while the lack of any background processes is just what you want
for pg_upgrade and disaster
On 9/5/12 5:03 PM, Tom Lane wrote:
I don't see people wanting to use this feature for unit tests.
If this is going to become an official feature (as opposed to an
internal interface only for use by pg_upgrade), then I think that's
exactly what people will want to use it for. In fact, it might
1 - 100 of 136 matches
Mail list logo
