Thanks, Andrew. I'll check my environment one more time.
You wrote:
AD On 12/23/2010 07:11 AM, Pavel Golub wrote:
Hello, Pgsql-bugs.
Tried to use MinGw under windows to build client libraries at least.
However failed on ./configure --withou-zlib stage.
Please find attached log file,
2010/12/24 Florian Pflug f...@phlo.org:
On Dec23, 2010, at 20:39 , Tomas Vondra wrote:
I guess we could use the highest possible value (equal to the number
of tuples) - according to wiki you need about 10 bits per element
with 1% error, i.e. about 10MB of memory for each million of
On Tue, 21 Dec 2010 19:33:04 +
Simon Riggs si...@2ndquadrant.com wrote:
1. The docs don't actually say what a foreign table is. Is it a local
representation of foreign data? Or a local copy of foreign data? Or is
it a table created on a remote node?
Foreign table is an database object
-tts_values and slot-tts_isnull for NextCopyFrom() directly?
Virtual tuple would be enough to carry column data, but virtual tuple
doesn't have system attributes including tableoid...
Regards,
--
Shigeru Hanada
20101224-switch_in_next.patch
Description: Binary data
--
Sent via pgsql-hackers mailing
On Dec24, 2010, at 05:00 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
The problem here is that you suggest NOLOGIN should mean Not allowed
to issue SQL commands, which really isn't what the name NOLOGIN
conveys.
No, it means not allowed to connect.
Exactly. Which proves my point,
Thank you for those replies, I understand things much better now.
I have two remaining concerns...
On Fri, 2010-12-24 at 19:51 +0900, Shigeru HANADA wrote:
15. In terms of planning queries, do we have a concept of additional
cost per row on a foreign server? How does the planner decide how
2010/12/24 Florian Pflug f...@phlo.org:
On Dec23, 2010, at 20:39 , Tomas Vondra wrote:
I guess we could use the highest possible value (equal to the number
of tuples) - according to wiki you need about 10 bits per element
with 1% error, i.e. about 10MB of memory for each million of
On Dec24, 2010, at 11:23 , Nicolas Barbier wrote:
2010/12/24 Florian Pflug f...@phlo.org:
On Dec23, 2010, at 20:39 , Tomas Vondra wrote:
I guess we could use the highest possible value (equal to the number
of tuples) - according to wiki you need about 10 bits per element
with 1%
On Fri, 24 Dec 2010 11:34:59 +
Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-12-24 at 19:51 +0900, Shigeru HANADA wrote:
15. In terms of planning queries, do we have a concept of additional
cost per row on a foreign server? How does the planner decide how
costly
retrieving
On Fri, Dec 24, 2010 at 7:13 AM, Peter Eisentraut pete...@gmx.net wrote:
Move the documentation of --no-security-label to a more sensible place
The order on the pg_dump/pg_dumpall man pages is not very strict, but
surely putting it under connection options was wrong.
I can't understand why
Dne 24.12.2010 13:15, t...@fuzzy.cz napsal(a):
2010/12/24 Florian Pflug f...@phlo.org:
On Dec23, 2010, at 20:39 , Tomas Vondra wrote:
I guess we could use the highest possible value (equal to the number
of tuples) - according to wiki you need about 10 bits per element
with 1% error,
Dne 24.12.2010 13:37, Florian Pflug napsal(a):
On Dec24, 2010, at 11:23 , Nicolas Barbier wrote:
2010/12/24 Florian Pflug f...@phlo.org:
On Dec23, 2010, at 20:39 , Tomas Vondra wrote:
I guess we could use the highest possible value (equal to the number
of tuples) - according to wiki
On Fri, Dec 24, 2010 at 20:04, Shigeru HANADA han...@metrosystems.co.jp wrote:
Iterate is called in query context,
Is it an unavoidable requirement? If possible, I'd like to use per-tuple memory
context as the default. We use per-tuple context in FunctionScan for SETOF
functions. I hope we could
Dne 24.12.2010 04:41, Florian Pflug napsal(a):
The filter size could be derived from the table's statistics target, or
be otherwise user-definable. We could also auto-resize once it gets too
full. But still, that all seems awfully complex :-(
Using a statistics target is a good idea I think. I
On fre, 2010-12-24 at 08:02 -0500, Robert Haas wrote:
On Fri, Dec 24, 2010 at 7:13 AM, Peter Eisentraut pete...@gmx.net wrote:
Move the documentation of --no-security-label to a more sensible place
The order on the pg_dump/pg_dumpall man pages is not very strict, but
surely putting it
Robert Haas wrote:
The existing comment says that -X is deprecated, but that doesn't
make it entirely 100% clear that the code isn't intended to be
further updated
Yeah, Dan recently implemented the DEFERRABLE transaction behavior
which was discussed on the list, so I added a
On Fri, Dec 24, 2010 at 9:01 AM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2010-12-24 at 08:02 -0500, Robert Haas wrote:
On Fri, Dec 24, 2010 at 7:13 AM, Peter Eisentraut pete...@gmx.net wrote:
Move the documentation of --no-security-label to a more sensible place
The order on the
Bruce Momjian wrote:
Tom Lane wrote:
Actually, if we're going to do this at all, we should do
pid
datadir
port
socketdir
... here be dragons ...
so that pg_ctl doesn't have to assume the server is running with a
default value of unix_socket_dir. Not sure
While I am working on pg_ctl, I saw this TODO item:
Have the postmaster write a random number to a file on startup that
pg_ctl checks against the contents of a pg_ping response on its initial
connection (without login)
This will protect against
Robert Haas wrote:
I actually think that the phrase this has been discussed before and
rejected should be permanently removed from our list of excuses for
rejecting a patch. Or if we must use that excuse, then I think a link
to the relevant discussion is a must, and the relevant discussion
flyusa2010 fly wrote:
Thanks for your reply.
Yes, i mean disk may lie to os.
Our documentation covers this extensively:
http://www.postgresql.org/docs/9.0/static/wal-reliability.html
---
On Fri, Dec 3, 2010
anwhile is X.
Agreed. Perhaps we need an anti-TODO that lists things we don't want in
more detail. The TODO has that for a few items, but scaling things up
there will be cumbersome.
Well there is a problem with this too. A good example is hints. A lot of
the community wants hints. A lot
On Dec 23, 2010, at 3:38 AM, Jan Urbański wrote:
Oh, didn't know that. I see that it does some more fancy things, like
defining a inheritance hierarchy for these exceptions and adding some
more into the mix.
Right, there were some cases that appeared to benefit from larger
buckets than what
On Fri, Dec 24, 2010 at 2:48 PM, Joshua D. Drake j...@commandprompt.com wrote:
I would have to agree here. The idea that we have to search email is bad
enough (issue/bug/feature tracker anyone?) but to have someone say,
search the archives? That is just plain rude and anti-community.
Saying
On 12/24/2010 06:26 PM, Aidan Van Dyk wrote:
On Fri, Dec 24, 2010 at 2:48 PM, Joshua D. Drakej...@commandprompt.com wrote:
I would have to agree here. The idea that we have to search email is bad
enough (issue/bug/feature tracker anyone?) but to have someone say,
search the archives? That
On Fri, 2010-12-24 at 18:26 -0500, Aidan Van Dyk wrote:
On Fri, Dec 24, 2010 at 2:48 PM, Joshua D. Drake j...@commandprompt.com
wrote:
I would have to agree here. The idea that we have to search email is bad
enough (issue/bug/feature tracker anyone?) but to have someone say,
search the
On Dec 24, 2010, at 10:52 AM, Bruce Momjian br...@momjian.us wrote:
Agreed. Perhaps we need an anti-TODO that lists things we don't want in
more detail. The TODO has that for a few items, but scaling things up
there will be cumbersome.
I don't really think that'd be much better. What might
27 matches
Mail list logo
