On Dec 24, 2010, at 10:52 AM, Bruce Momjian 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 be of some val
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
> 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 12/24/2010 06:26 PM, Aidan Van Dyk wrote:
On Fri, Dec 24, 2010 at 2:48 PM, Joshua D. Drake 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 a
On Fri, Dec 24, 2010 at 2:48 PM, Joshua D. Drake 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 "search the bugtracke
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
> 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.
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,
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 discussi
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 connecti
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_s
On Fri, Dec 24, 2010 at 9:01 AM, Peter Eisentraut wrote:
> On fre, 2010-12-24 at 08:02 -0500, Robert Haas wrote:
>> On Fri, Dec 24, 2010 at 7:13 AM, Peter Eisentraut wrote:
>> > Move the documentation of --no-security-label to a more sensible place
>> >
>> > The order on the pg_dump/pg_dumpall ma
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
--serializa
On fre, 2010-12-24 at 08:02 -0500, Robert Haas wrote:
> On Fri, Dec 24, 2010 at 7:13 AM, Peter Eisentraut 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 conn
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.
On Fri, Dec 24, 2010 at 20:04, Shigeru HANADA 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 have little difference b
Dne 24.12.2010 13:37, Florian Pflug napsal(a):
> On Dec24, 2010, at 11:23 , Nicolas Barbier wrote:
>
>> 2010/12/24 Florian Pflug :
>>
>>> 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
Dne 24.12.2010 13:15, t...@fuzzy.cz napsal(a):
>> 2010/12/24 Florian Pflug :
>>
>>> 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, Dec 24, 2010 at 7:13 AM, Peter Eisentraut 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 this new locat
On Fri, 24 Dec 2010 11:34:59 +
Simon Riggs 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 data is fr
On Dec24, 2010, at 11:23 , Nicolas Barbier wrote:
> 2010/12/24 Florian Pflug :
>
>> 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% e
> 2010/12/24 Florian Pflug :
>
>> 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
>
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 ho
On Dec24, 2010, at 05:00 , Tom Lane wrote:
> Florian Pflug 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,
cStoreTuple() for the purpose. Could you try
> to use slot->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-swi
On Tue, 21 Dec 2010 19:33:04 +
Simon Riggs 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 which represents the
2010/12/24 Florian Pflug :
> 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
>> elem
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
27 matches
Mail list logo
