Unfortunately, I'am getting the error as below when I start the gossip. I had
followed the same steps as you mentioned.
REFLECT:I'm not in the list of gossip hosts, exiting
(the hosts are [cluster_1|cluster_2])
cluster_1 cluster_2 are node names are the in /etc/hosts.
Did you face this?
On Mon, 18 Aug 2008, Tom Lane wrote:
What would make more sense is to redesign the large-object stuff to be
somewhat modern and featureful, and provide stream-access APIs (think
lo_read, lo_seek, etc) that allow offsets wider than 32 bits.
A few years ago, I was working on such a project for
Hello
I thing so Agg node doesn't set width well:
postgres=# explain select a,b from twocol;
QUERY PLAN
--
Seq Scan on twocol (cost=0.00..31.40 rows=2140 width=8)
(1 row)
postgres=# explain select sum(a) from
I think I may have found another bug:
WITH RECURSIVE t(i,j) AS (
VALUES (1,2)
UNION ALL
SELECT t2.i, t.j
FROM (
SELECT 2 AS i
UNION ALL /* Wrongly getting detected, I think */
SELECT 3 AS i
) AS t2
JOIN
t
ON (t2.i
Alvaro Herrera wrote:
Tom Lane escribió:
Gregory Stark [EMAIL PROTECTED] writes:
The entire target market for such a thing is DBAs stuck on hosted databases
which don't have shell access to their machines. Perhaps the overlap between
that and the people who can write a server-side module
Josh Berkus wrote:
Andrew,
I always find these requests puzzling. Is it really useful to store the
data for a jpeg, video file or a 10GB tar ball in a database column?
Some people find it useful. Because LOs are actually easier to manage in
PG than in most other DBMSes, right now
Simon Riggs wrote:
On Mon, 2008-08-18 at 16:22 -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
What would need to happen for the next jump up from where varlena is
now, to 8 bytes?
Dealing with upwards-of-4GB blobs as single Datums isn't remotely sane,
and won't become so in
Hi
The reason that this case wasn't covered in 8.3 is that there didn't
seem to be a use-case that justified doing the extra work. I still
haven't seen one.
You just stopped reading the thread where it was discussed after your troll
remark?
Other than inline-able SQL functions there is no
Am Monday, 18. August 2008 schrieb Tom Lane:
If the type has no functions of its own, then the only way to make it
easily usable is to throw in implicit conversions *in both directions*
between it and the type it's an alias for. You're going to find that
that's a problem.
I'm not finding
On Tue, 2008-08-19 at 09:45 +0200, Pavel Stehule wrote:
postgres=# explain select sum(a) from twocol group by b;
QUERY PLAN
HashAggregate (cost=42.10..44.60 rows=200 width=8) -- wrong should be 4
Am Monday, 18. August 2008 schrieb Tom Lane:
- permissions features (more than none anyway)
- better management of orphaned objects (obsoleting vacuumlo)
- support 16TB of large objects (maybe partition pg_largeobject?)
- dump and restore probably need improvement to be practical for such
Am Monday, 18. August 2008 schrieb Josh Berkus:
Right now, if you want to survey
your databases, tables, approx disk space, query activity, etc., you can
do that all through port 5432. You can't manage most of your server
settings that way, and definitely can't manage the *persistent*
I do think you and others make it less likely every time you throw up big
insoluble problems like above though. As a consequence every proposal has
started with big overly-complex solutions trying to solve all these
incidental
issues which never go anywhere instead of simple solutions
2008/8/19 Simon Riggs [EMAIL PROTECTED]:
On Tue, 2008-08-19 at 09:45 +0200, Pavel Stehule wrote:
postgres=# explain select sum(a) from twocol group by b;
QUERY PLAN
HashAggregate (cost=42.10..44.60
Am Monday, 18. August 2008 schrieb Tom Lane:
The impression I get every time this comes up is that various people
have different problems they want to solve that (they think) require
redesign of the way GUC works. Those complicated solutions arise from
attempting to satisfy N different
I seem to recall that there was general support for installing a smaller
default postgresql.conf file with only, say, a dozen parameters mentioned for
initial tuning. The complete file can stay as a sample. Any objections to
that? (Let's not discuss quite yet exactly which parameters are the
Peter Eisentraut wrote:
I seem to recall that there was general support for installing a smaller
default postgresql.conf file with only, say, a dozen parameters mentioned for
initial tuning. The complete file can stay as a sample. Any objections to
that? (Let's not discuss quite yet exactly
On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
2008/8/18 Hannu Krosing [EMAIL PROTECTED]:
On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
2008/8/18 Dimitri Fontaine [EMAIL PROTECTED]:
Hi,
Le lundi 18 août 2008, Andrew Dunstan a écrit :
On Sat, Aug 16, 2008 at
On Mon, 2008-08-18 at 20:29 -0400, Tom Lane wrote:
Asko Oja [EMAIL PROTECTED] writes:
For users of stored procedures it is protection from downtime. For Skype it
has been around 20% of databse related downtime this year.
Perhaps Skype needs to rethink how they are modifying functions.
Why
2008/8/19 Hannu Krosing [EMAIL PROTECTED]:
On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
2008/8/18 Hannu Krosing [EMAIL PROTECTED]:
On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
2008/8/18 Dimitri Fontaine [EMAIL PROTECTED]:
Hi,
Le lundi 18 août 2008, Andrew
2008/8/19 Hannu Krosing [EMAIL PROTECTED]:
On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
2008/8/18 Hannu Krosing [EMAIL PROTECTED]:
On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
2008/8/18 Dimitri Fontaine [EMAIL PROTECTED]:
Hi,
Le lundi 18 août 2008, Andrew
On Tue, 2008-08-19 at 12:42 +0200, Pavel Stehule wrote:
2008/8/19 Hannu Krosing [EMAIL PROTECTED]:
On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
2008/8/18 Hannu Krosing [EMAIL PROTECTED]:
On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
2008/8/18 Dimitri Fontaine [EMAIL
Hannu Krosing [EMAIL PROTECTED] writes:
Maybe there should be something in postgreSQL docs that warns users against
using functions in any non-trivial circumstances, as functions are not
expected to behave like the rest of postgreSQL features and there is
not plan to fix that ?
Now who's
Hi leiyonghua,
leiyonghua wrote:
and still same status.
Uh.. do you have debugging enabled? Any logging output of the two
postmaster processes?
Regards
Markus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hi,
leiyonghua wrote:
./configure --enable-replication
make make install
You certainly also want --enable-debug and --enable-cassert, maybe also
additional flags for the C compiler, like -DRMGR_DEBUG, please check the
source code for these.
4. install the GCS ensemble, according the
Hi,
K, Niranjan (NSN - IN/Bangalore) wrote:
Thanks for the information.
For Step5 (starting ensemble daemon).-
I set the multicast address to both nodes (Node 1 Node 2 eth0: 224.0.0.9/4)
before starting the ensemble. And started the server application mtalk in
node 1 node 2 and then
* Tom Lane ([EMAIL PROTECTED]) wrote:
So ... I'm wondering if this actually touches anyone's hot-button,
or if we should just file it in the overflowing pile of Things That
Might Be Nice To Do Someday.
What bugs me the most about having IN() be faster than EXISTS() in
certain situations is
Pavel Stehule [EMAIL PROTECTED] writes:
I thing so Agg node doesn't set width well:
The planner doesn't really bother to set the width correctly for any
expression-computing node. This is partly laziness, but OTOH it is
very hard to estimate a sane width for any function returning a
Peter Eisentraut [EMAIL PROTECTED] writes:
One direction of the cast could be AS ASSIGNMENT, btw., but that is another
decision that would have to be worked out.
Making the back-cast be AS ASSIGNMENT would reduce the risks of
ambiguities, for sure.
regards, tom lane
Tom Lane [EMAIL PROTECTED] wrote:
The examples that Kevin Grittner put up awhile back included several
uses of EXISTS() in places where it couldn't be turned into a
semijoin,
eg in the query's targetlist. I was musing a bit about whether we
could
improve those scenarios. I would like to
Hannu Krosing [EMAIL PROTECTED] writes:
On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
I am sorry, but it's really new feature and not bug fix
Could you please explain why you think so ?
For the same reasons that plan invalidation itself was a new feature
and not a bug fix; notably,
Hans-Juergen Schoenig wrote:
alternatively we could use some sort of #include mechanism to split
most important and not so important.
We already have an include mechanism.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting,
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
alternatively we could use some sort of #include mechanism to split
most important and not so important.
We already have an include mechanism.
Using that to include a file that's full of comments anyway (which is
all that's left in
Tom Lane [EMAIL PROTECTED] wrote:
I was kinda wondering about something closer to the TOAST model,
where
a blob is only referenceable from a value that's in a table field;
and that value encapsulates the name of the blob in some way that
needn't even be user-visible. This'd greatly
On Tue, 19 Aug 2008 17:11:49 +0200
Magnus Hagander [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
alternatively we could use some sort of #include mechanism to
split most important and not so important.
We already have an include mechanism.
Using
Le mardi 19 août 2008, Tom Lane a écrit :
For the same reasons that plan invalidation itself was a new feature
and not a bug fix;
I'm sorry but that doesn't help me a dime to understand current situation. It
could well be just me, but... here's how I see it:
- plan invalidation is a new
On Tue, 19 Aug 2008 12:48:06 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Maybe there should be something in postgreSQL docs that warns users
against using functions in any non-trivial circumstances, as
functions are not expected to behave like the
Dimitri Fontaine [EMAIL PROTECTED] writes:
- now, we have found a bug in plan invalidation
[ shrug... ] You have not found a bug in plan invalidation. You have
found omitted functionality --- functionality that was *intentionally*
omitted from the 8.3 version.
regards,
Joshua Drake [EMAIL PROTECTED] writes:
Magnus Hagander [EMAIL PROTECTED] wrote:
Using that to include a file that's full of comments anyway (which is
all that's left in postgresql.conf at this time, I'm sure) just seems.
Well. Sub-optimal.
Yes but part of this idea is valid. The fact is the
On Tue, 19 Aug 2008 12:12:16 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua Drake [EMAIL PROTECTED] writes:
Magnus Hagander [EMAIL PROTECTED] wrote:
Yes but part of this idea is valid. The fact is the majority of the
postgresql.conf parameters don't need to be in there by default. It
Having recently updated my work machine to Fedora 9, I'm now getting
blessed with all the -Winline warnings that gcc 4.3 likes to emit.
I recall some other folk complaining of that previously. While I could
suppress the switch in a Makefile.custom, I'm wondering whether it's
really doing anything
Le mardi 19 août 2008, Tom Lane a écrit :
[ shrug... ] You have not found a bug in plan invalidation. You have
found omitted functionality --- functionality that was *intentionally*
omitted from the 8.3 version.
Thanks a lot for this clarification, now I understand you viewpoint.
So, the 8.3
Back in April we changed EXPLAIN VERBOSE to not dump the internal plan
tree anymore, on the grounds that non-hackers didn't want that info and
hackers could get it with debug_print_plan and related variables.
Well, now that I've tried to do some planner development work relying on
debug_print_plan
Joshua Drake [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
I guess it would depend on what initdb puts into it.
Per the code:
max_connections
Tom,
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
I've never thought that the current contents were especially useful
as documentation; the kindest thing you can say about 'em is that they
are duplicative of
On Tue, 19 Aug 2008 12:48:20 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua Drake [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into
it)?
I guess it
Dimitri Fontaine [EMAIL PROTECTED] writes:
Another thing I do not understand well is how people are expected to work in
8.3 with a function based API, without hitting Skype problems.
I could understand this level of complaining if this were a new problem
that'd appeared in 8.3. But *every PG
Josh Berkus [EMAIL PROTECTED] wrote:
Attached is the postgresql.conf.simple I used in my presentaiton. It
has an egregious math error in it (see if you can find it) but should
give you the general idea.
Well, this sure looks scary:
# maintenance_work_mem = 256MB #webserver with 2GB
Joshua Drake [EMAIL PROTECTED] writes:
If we move to the above route, we end up in an environment with a
single source for official documentation and we can always point to
that.
Yeah, the fundamental point here is whether or not postgresql.conf
should be trying to serve as part of our system
On Tue, Aug 19, 2008 at 1:17 PM, Kevin Grittner
[EMAIL PROTECTED] wrote:
Josh Berkus [EMAIL PROTECTED] wrote:
But I'm amazed by this, too:
# max_connections = 700 # web application database
How many CPUs and spindles are you assuming there?
My testing and experience suggest applications
On Tue, 2008-08-19 at 12:40 -0400, Tom Lane wrote:
Back in April we changed EXPLAIN VERBOSE to not dump the internal plan
tree anymore, on the grounds that non-hackers didn't want that info and
hackers could get it with debug_print_plan and related variables.
Well, now that I've tried to do
On Tue, 19 Aug 2008 13:22:34 -0400
Tom Lane [EMAIL PROTECTED] wrote:
I'm really not in favor of having comments in the conf file that try
to tell you about stuff you might want to set, much less why. That
task properly belongs to some kind of introductory chapter in the
SGML docs. Novice
On Tue, 19 Aug 2008 12:17:46 -0500
Kevin Grittner [EMAIL PROTECTED] wrote:
Well, this sure looks scary:
# maintenance_work_mem = 256MB #webserver with 2GB RAM
I would agree. 2GB isn't that much memory as it is and that is a fairly
heft amount of maintenance_work_mem. This isn't the days
Polite answers lead to polite discussions. Caling other people names lead to
flame wars.
It's perfectly ok for Skype to keep our own build of 8.3 with given patch
and make it available for whoever might want it. At least now there is
almost good enough description why the patch was needed althou
2008/8/19 Dimitri Fontaine [EMAIL PROTECTED]:
Le mardi 19 août 2008, Tom Lane a écrit :
[ shrug... ] You have not found a bug in plan invalidation. You have
found omitted functionality --- functionality that was *intentionally*
omitted from the 8.3 version.
Thanks a lot for this
Another thing I do not understand well is how people are expected to work
in
8.3 with a function based API, without hitting Skype problems.
People are expected to use same workarounds as Skype is using. For us
another unneccessary downtime week ago was what set us moving/thinking :).
When you
Magnus Hagander wrote:
Decibel! wrote:
On Aug 13, 2008, at 4:12 AM, Magnus Hagander wrote:
Tom Lane wrote:
Decibel! [EMAIL PROTECTED] writes:
I disagree. While we don't guarantee stats are absolutely up-to-date,
or atomic I don't think that gives license for them to just magically
not exist
On Tue, Aug 19, 2008 at 06:33:33PM +0100, Simon Riggs wrote:
On Tue, 2008-08-19 at 12:40 -0400, Tom Lane wrote:
Back in April we changed EXPLAIN VERBOSE to not dump the internal plan
tree anymore, on the grounds that non-hackers didn't want that info and
hackers could get it with
Joshua Drake wrote:
On Tue, 19 Aug 2008 12:48:06 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Maybe there should be something in postgreSQL docs that warns users
against using functions in any non-trivial circumstances, as
functions are not
On Tue, 19 Aug 2008 14:29:52 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Do I think it should be pushed back to 8.3.x; no. It is a feature. I
don't consider the existing behavior a bug. I consider it a
limitation and we don't back patch fixes for limitations.
The bottom line
Magnus Hagander [EMAIL PROTECTED] writes:
Actually, I think maybe not so hard. Attached is a patch that fixes
this. It's done by keeping the old filename around. When you change the
path, the stats collector will start writing the new file the next time
it writes something (which should be max
On Tue, 2008-08-19 at 12:40 -0400, Tom Lane wrote:
Back in April we changed EXPLAIN VERBOSE to not dump the internal plan
tree anymore, on the grounds that non-hackers didn't want that info and
hackers could get it with debug_print_plan and related variables.
Well, now that I've tried to do
Joshua Drake wrote:
On Tue, 19 Aug 2008 14:29:52 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Do I think it should be pushed back to 8.3.x; no. It is a feature. I
don't consider the existing behavior a bug. I consider it a
limitation and we don't back patch fixes for
Hannu Krosing [EMAIL PROTECTED] writes:
what about changing (or adding) values log and notice ?
debug_print_plan = log;
debug_print_plan = notice;
so you could set that on demand ?
Well, we could, but it would break existing habits for not much gain.
Really this proposal is to make
On Tuesday 19 August 2008 19:12:16 Tom Lane wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
Well, my original implementation of GUC had an empty default configuration
file, which was later craptaculated
Joshua Drake [EMAIL PROTECTED] wrote:
Is our backpatch policy documented? It does not appear to be in
developer FAQ.
It's mentioned here:
http://www.postgresql.org/support/versioning
PostgreSQL minor releases fix only frequently-encountered, security,
and data corruption bugs to reduce
Bruce Momjian [EMAIL PROTECTED] writes:
Joshua Drake wrote:
Is our backpatch policy documented? It does not appear to be in
developer FAQ.
Seems we need to add it.
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and how far) to backpatch has always been a
I made tests compiling both sources (from CVS repository and from HTTP), and
i got the next results:
1-) MSVS 2005
*Source from CVS repository: *fatal error U1073: Don't know how to make
'libpq-dist.rc'
*Source from http (ver. 8.3.3): **Successfully generated*
2.) Borland 5.5.1
*
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Joshua Drake wrote:
Is our backpatch policy documented? It does not appear to be in
developer FAQ.
Seems we need to add it.
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and how far) to backpatch
Asko Oja escribió:
Another thing I do not understand well is how people are expected to work
in
8.3 with a function based API, without hitting Skype problems.
People are expected to use same workarounds as Skype is using. For us
another unneccessary downtime week ago was what set us
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm really not in favor of having comments in the conf file that try to
tell you about stuff you might want to set, much less why. That task
properly belongs to some kind of introductory chapter in the SGML docs.
Novice DBAs are unlikely
Greg Sabino Mullane [EMAIL PROTECTED] writes:
I like Josh B's version a lot. It's not perfect (I'd add a URL for
each config for example), but it's a great start.
Josh B's approach is great until people start making changes that are
unrelated to (or perhaps even contradictory to) his comments.
On Tue, 19 Aug 2008 19:12:47 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Ugh, you are heading in the wrong direction. The configuration file
should be well documented: moving the documentation further away
from it is the wrong idea, especially if it means firing up a web
browser to do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 19 août 08 à 19:06, Tom Lane a écrit :
Dimitri Fontaine [EMAIL PROTECTED] writes:
Another thing I do not understand well is how people are expected
to work in
8.3 with a function based API, without hitting Skype problems.
What we've got
Le 19 août 08 à 20:47, Tom Lane a écrit :
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and how far) to backpatch has always been a best-judgment
call
in the past, and we've gotten along fine with that. I think having a
formal policy is just likely to lead to
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
moving the documentation further away from it is the wrong idea,
especially if it means firing up a web browser to do so.
I can see that argument, but I think we can quite simply solve it if we
provide a plain-text version of the
I'm really not in favor of having comments in the conf file that try to
tell you about stuff you might want to set, much less why. That task
properly belongs to some kind of introductory chapter in the SGML docs.
Novice DBAs are unlikely even to *find* the config file, let alone look
inside
On Tue, 19 Aug 2008 14:47:13 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Joshua Drake wrote:
Is our backpatch policy documented? It does not appear to be in
developer FAQ.
Seems we need to add it.
I'm not sure that I *want* a formal written-down
Peter Eisentraut wrote:
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
moving the documentation further away from it is the wrong idea,
especially if it means firing up a web browser to do so.
I can see that argument, but I think we can quite simply solve it if we
provide
On Tue, Aug 19, 2008 at 02:47:13PM -0400, Tom Lane wrote:
Whether (and how far) to backpatch has always been a best-judgment call
in the past, and we've gotten along fine with that. I think having a
formal policy is just likely to lead to even more complaints:
I completely agree with this.
On Tue, 19 Aug 2008 15:43:11 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Peter Eisentraut wrote:
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
moving the documentation further away from it is the wrong idea,
especially if it means firing up a web browser to do so.
Another thing I do not understand well is how people are expected to work in
8.3 with a function based API, without hitting Skype problems. I'm having a
All database-driven applications have this problem. Any time you have
a database on the backend and interface code on the front-end, you
need
Peter Eisentraut wrote:
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
Text space is cheap,
I'd offer the alternative theory that anything that is longer than one screen
is overwhelming and unwieldy.
One more benefit of a small file is that it makes it easier to ask someone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 19 août 08 à 22:03, Robert Haas a écrit :
All database-driven applications have this problem. Any time you have
a database on the backend and interface code on the front-end, you
need to keep in mind that it won't necessarily be possible to
On Tue, Aug 19, 2008 at 12:42:29PM -0700, Joshua Drake wrote:
Generally speaking we adhere to the following guideline for patches.
* Security fixes are applied to all applicable branches.
* Bugfixes are applied to all applicable branches
* Note: A patch that addresses a known
On Tue, 2008-08-19 at 21:26 +0200, Dimitri Fontaine wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 19 août 08 à 19:06, Tom Lane a écrit :
Dimitri Fontaine [EMAIL PROTECTED] writes:
Another thing I do not understand well is how people are expected
to work in
8.3 with
On Tue, 19 Aug 2008 16:22:43 -0400
Andrew Sullivan [EMAIL PROTECTED] wrote:
A formal policy that's any more detailed than what's in the FAQ today
is a solution in search of a problem.
Odd that the problem continues to rear its head though isn't it? This
certainly isn't the first time it has
Dimitri Fontaine escribió:
The problem here (at least for me) was to understand why this (yet to be
reviewed) patch is about implementing a new feature and not about
bugfixing an existing one. So we're exactly in the fog around the
informal backpatch policy, and as long as we're able to
Alvaro Herrera [EMAIL PROTECTED] writes:
The actual criterion is not really new user-visible feature versus
bug fix. It's more an attempt at measuring how large a potential
impact the change has. The patch I saw was introducing a whole new
message type to go through the shared invalidation
On Tue, 2008-08-19 at 16:03 -0400, Robert Haas wrote:
Another thing I do not understand well is how people are expected to work in
8.3 with a function based API, without hitting Skype problems. I'm having a
All database-driven applications have this problem. Any time you have
a database
Alvaro Herrera [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I can see that argument, but I think we can quite simply solve it if we
provide a plain-text version of the configuration chapter of the
documentation.
Hmm, let me suggest providing it as a manpage for postgresql.conf, i.e.,
On Tue, 19 Aug 2008 17:03:48 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I can see that argument, but I think we can quite simply solve it
if we provide a plain-text version of the configuration chapter of
the documentation.
On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The actual criterion is not really new user-visible feature versus
bug fix. It's more an attempt at measuring how large a potential
impact the change has. The patch I saw was introducing a whole
On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The actual criterion is not really new user-visible feature versus
bug fix. It's more an attempt at measuring how large a potential
impact the change has. The patch I saw was introducing a whole
On Tue, Aug 19, 2008 at 10:03 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I can see that argument, but I think we can quite simply solve it if we
provide a plain-text version of the configuration chapter of the
documentation.
Hmm,
On Tue, 19 Aug 2008, Josh Berkus wrote:
Well, that doesn't help unless we either provide a .conf generation tool
(something I favor) or docs somewhere which explain which are the variables
to be the most concerned with instead of making users read through all 218 of
them.
The design for a
Dave Page wrote:
On Tue, Aug 19, 2008 at 10:03 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, let me suggest providing it as a manpage for postgresql.conf, i.e.,
you run man postgresql.conf and it gives you this manpage documenting
every option.
you have functions
A) caller1() to callerN() which includes call to called1()
B) one of these functions, say callerM() needs one more field returned
from called1(), so you either write a completely new function
called1_v2() with one more field and then update callerM() to call
On Tue, Aug 19, 2008 at 07:12:47PM -, Greg Sabino Mullane wrote:
I'm really not in favor of having comments in the conf file that
try to tell you about stuff you might want to set, much less why.
That task properly belongs to some kind of introductory chapter in
the SGML docs. Novice
Hi.
I made tests compiling both sources (from CVS repository and from HTTP), and
i got the next results:
1-) MSVS 2005
*Source from CVS repository: *fatal error U1073: Don't know how to make
'libpq-dist.rc'
*Source from http (ver. 8.3.3): **Successfully generated*
It can be made from
1 - 100 of 130 matches
Mail list logo
