On 6/5/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Simon Riggs wrote:
> > Assuming, that is, that you think this point is important enough to
> > drive the whole design; which I find rather questionable in view of the
> > fact that the submitted patch contained no mention whatever of any such
>
Hello
I'm one of the Google SoC's students for PostgreSQL. While reading sql92
standard, I found something like this:
11.36
General Rules
3) For every identified privilege descriptor whose action is
SELECT, INSERT, UPDATE, or REFERENCES without a column name,
Simon Riggs wrote:
> > Assuming, that is, that you think this point is important enough to
> > drive the whole design; which I find rather questionable in view of the
> > fact that the submitted patch contained no mention whatever of any such
> > consideration. Or is this just another way in which
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Fri, Jun 01, 2007 at 01:50:12PM -0400, Bruce Momjian wrote:
>> The big question is do we want to drop the target tuple size down to
>> 512, and increase the chunk size to 8k for 8.3?
> If we do that people could see their disk space usage increase by
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> we should do is make oper() specifically test for the case of operator
>> 349 with UNKNOWN left input, or operator 374 with UNKNOWN right input,
>> and throw a custom error message hinting that the other operand
>
It's always seemed a little odd to me that Postgres should install a
command called "createuser" or "createlang", because it's entirely
non-obvious on first examination that these commands (which often live
in /usr/bin) have any connections with PostgreSQL. Shouldn't there be
at least be a "pg" in
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I tried to repeat the DBT-2 runs with the "oldestxmin refresh" patch,
> but to my surprise the baseline run with CVS head, without the patch,
> behaved very differently than it did back in March.
> I rerun the a shorter 1h test with CVS head from
I wrote:
> It looks to me like we have a very narrow problem and
> we should tailor a very narrow solution. What I am currently thinking
> we should do is make oper() specifically test for the case of operator
> 349 with UNKNOWN left input, or operator 374 with UNKNOWN right input,
> and throw a c
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
+1 on that. The problem of ensuring atomic output remains though
(see nearby complaints from George Pavlov and others).
Is that the one you suggested trying to fix by calling write() instead
of fp
On Fri, Jun 01, 2007 at 01:50:12PM -0400, Bruce Momjian wrote:
> I think the long-term solution is to go to a 2k/8k fragment/block model,
> but that isn't going to happen for 8.3.
There might well have been lessons learned since UFS (anyone know what
ZFS does in this regard?), but I agree that we
"Tom Lane" <[EMAIL PROTECTED]> writes:
> So after reflecting on all that, it doesn't seem like a good idea to
> hack the type-coercion code to discriminate against matching unknown
> to anyarray. It looks to me like we have a very narrow problem and
> we should tailor a very narrow solution. Wha
I tried to repeat the DBT-2 runs with the "oldestxmin refresh" patch,
but to my surprise the baseline run with CVS head, without the patch,
behaved very differently than it did back in March.
I rerun the a shorter 1h test with CVS head from May 20th, and March 6th
(which is when I ran the earl
Awhile back, I wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> I've looked into cutting back on the implicit casts to text, which
>> exposed the following little gem.
>> The expressions
>> 'abc' || 34
>> 34 || 'abc'
>> would no longer work, with the following error message:
>> ERROR: 22
On Mon, 2007-06-04 at 15:34 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Mon, 2007-06-04 at 14:41 -0400, Tom Lane wrote:
> >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>> The original ideal implementation was to use round-robin/cyclic
> >>> selection, which allows mu
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Mon, 2007-06-04 at 14:41 -0400, Tom Lane wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>> The original ideal implementation was to use round-robin/cyclic
>>> selection, which allows much better usage in the above case.
>>
>> Really? What if mu
On Mon, 2007-06-04 at 14:41 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > One of the main reasons for the implementation was to allow larger
> > queries to work faster by utilising multiple temp tablespaces for the
> > same query.
>
> > The original ideal implementation wa
On Mon, 2007-06-04 at 18:26 +0200, Florian G. Pflug wrote:
> The function recoveryStopsHere in xlog.c checks if we should
> stop recovery due to the values of recovery_target_xid and
> recovery_target_time. For recovery_target_xid, we stop if
> we see a commit or abort record for the given xid.
>
Basically, better support for binary formats which includes, but not limited
to:
1) functions for converting to and from various datatypes
2) reducing the need to convert to and from network byte order
3) better documentation
My suggestion on using ASN.1 was merely a naive suggestion on how in ca
On Mon, 4 Jun 2007, Andrew Dunstan wrote:
turnip_moth is also a Solaris 9 box and doesn't seem have the same issue.
Kris, is there anything unusual installed on the box that would make it
behave like this?
Not sure what's going on here. I did a manual run of the ecpg tests and
it compl
Hi
I'm currently working on splitting StartupXLog into smaller
parts, because I need to reuse some of the parts for concurrent
wal recovery (for my GSoC project)
The function recoveryStopsHere in xlog.c checks if we should
stop recovery due to the values of recovery_target_xid and
recovery_targe
Wilhansen Li wrote:
First of all, apologies if this was not meant to be a feedback/wishlist
mailing list.
Binary formats in libpq has been (probably) a long
issue (refer to the listings below) and I want to express my hope that the
next revision of PostgreSQL would have better support for binary
First of all, apologies if this was not meant to be a feedback/wishlist
mailing list.
Binary formats in libpq has been (probably) a long
issue (refer to the listings below) and I want to express my hope that the
next revision of PostgreSQL would have better support for binary data types
in libpq.
Michael Meskes wrote:
On Mon, Jun 04, 2007 at 03:30:07AM -0400, Tom Lane wrote:
AFAICS, Peter's recent incomplete updating of error message wording
should have broken every last man jack of 'em. And yet there's still
some green to be seen. I think we are looking at problems in the ecpg
te
Peter Eisentraut wrote:
What happened to the idea to run all tests (including PL, ECPG, contrib(?)) by
default, that is, by the top-level check/installcheck targets. Those who
want to run individual tests could still do so in the respective
subdirectories. What requirements does the buildfa
Peter Eisentraut wrote:
> I notice that in 8.3, when I kill the postmaster process with SIGKILL or
> SIGSEGV, the child processes writer and stats collector go away
> immediately, but the autovacuum launcher hangs around for up to a
> minute. (I suppose this has to do with the periodic wakeups?
On Mon, Jun 04, 2007 at 03:30:07AM -0400, Tom Lane wrote:
> AFAICS, Peter's recent incomplete updating of error message wording
> should have broken every last man jack of 'em. And yet there's still
> some green to be seen. I think we are looking at problems in the ecpg
> test scaffolding. For i
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this a TODO?
>
> I don't think so; there is no demand from anybody but Zdenek to remove
> those programs. Has it ever even come up before?
No. Agreed.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
Enterp
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this a TODO?
I don't think so; there is no demand from anybody but Zdenek to remove
those programs. Has it ever even come up before?
regards, tom lane
---(end of broadcast)---
Tom Lane wrote:
AFAICS, Peter's recent incomplete updating of error message wording
should have broken every last man jack of 'em. And yet there's still
some green to be seen. I think we are looking at problems in the ecpg
test scaffolding.
Yes. The buildfarm script uses the same logic as
Is this a TODO?
---
Zdenek Kotala wrote:
> Tom Lane napsal(a):
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >> Zdenek Kotala wrote:
> > And what about replace all "scripts" by one command e.g pg_cmd with
> > fol
>but I'll bet
>a nickel your CREATE TYPE says something else --- probably varlena
You win, how can I pay this bet? :)
Very very thanks, I was looking for the error in the wrong place! It was
so simple and works!
But still have another problem, may be related with my output
functions!?!?
This makes no difference in terms of the ease of tracking their changes,
of course, but it just feels better to me to be distributing "real"
source code and not derived files.
Hmm.
1 Compiling from .sbl by original Snowball's makefile requires Perl and doesn't
work cleanly:
% gmake
cc -o
> >> Assume the following:
> >> index on: (id, adate)
> >> constraint CHECK(adate > '01-01-2007' AND adate < '04-01-2007');
> >
Um, the subject is CE, but the question is about an index ? Those are
separate issues.
> >> The planner will not use the index listed above.
> > For what?
>
> select
Tom Lane napsal(a):
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Zdenek Kotala wrote:
And what about replace all "scripts" by one command e.g pg_cmd with
following interface:
Well, I don't think rolling up the miscellaneous commands into a single
binary with behaviour dependent on arg[0] is a
FYI, I am attending events in Italy, California, Pennsylvania, Finland,
and Russia in the next few months:
http://momjian.us/main/events.html
Site of russian conference: http://www.highload.ru (sorry, but only russian info
yet)
Bruce's announcement: http://www.highload.ru/news/2824.ht
> > > Given this, I propose we simply #ifdef out the SO_REUSEADDR on
win32.
I agree, that this is what we should do.
> > > (A fairly good reference to read up on the options is at
> > > http://msdn2.microsoft.com/en-us/library/ms740621.aspx
> >
> > Hmm ... if accurate, that page says in words
On Sun, Jun 03, 2007 at 10:44:13PM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32.
> >> Anybody see a problem with this?
>
> > Is that true even if the backend crashes?
>
> It
What happened to the idea to run all tests (including PL, ECPG, contrib(?)) by
default, that is, by the top-level check/installcheck targets. Those who
want to run individual tests could still do so in the respective
subdirectories. What requirements does the buildfarm have?
--
Peter Eisentr
On Sun, Jun 03, 2007 at 11:29:33PM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32.
> > Anybody see a problem with this?
>
> > (A fairly good reference to read up on the options is at
> > http://msdn2.mic
AFAICS, Peter's recent incomplete updating of error message wording
should have broken every last man jack of 'em. And yet there's still
some green to be seen. I think we are looking at problems in the ecpg
test scaffolding. For instance, dragonfly claims a green build, but
http://www.pgbuildfar
40 matches
Mail list logo
