Hi,
Currently we have enable_sig_alarm() which provides millisecond level
granularity in specifying delay. I tried using it by just specifying
nonzero value for the timeval.it_value.tv_usec field before calling
setitimer, but didn't seem to work well.
Do we have any function in the postgres cod
> > At least according to [1], kernel AIO on Linux still doesn't work
for
> > buffered (i.e. non-O_DIRECT) files. There have been patches
available
> > for quite some time that implement this, but I'm not sure when they
> > are likely to get into the mainline kernel.
> >
> > -Neil
> >
> > [1]
Am Freitag, 20. Oktober 2006 00:32 schrieb Tom Lane:
> So I'm inclined to leave the behavior as-is. The documentation for
> log_statement already says
>
> Note: Statements that generate syntax errors are not logged. Set
> log_min_error_statement to error to log such statements.
Oh, I
Neil Conway wrote:
> Why does adminpack install functions into pg_catalog? This is
> inconsistent with the rest of the contrib/ packages, not to mention the
> definition of pg_catalog itself (which ought to hold builtin object
> definitions). And as AndrewSN pointed out on IRC, it also breaks
> pg_
Hi, Mark,
Mark Woodward wrote:
>>> My question, is it a syntactic technicality that PostgreSQL asks for a
>>> "group by," or a bug in the parser?
>> I think that it's a lack of special-casing the = operator. Imagine
>> "where ycis_id>15" or "where ycis_id @|< $RECTANGLE" or other (probably
>> use
Am Freitag, 20. Oktober 2006 09:13 schrieb Adrian Maier:
> It would have been much more convenient to see the bad queries in
> the logs ...
I think you are missing the point of this discussion. All the erroneous
queries are logged. The question is merely under what configuration.
--
Peter Eis
Zeugswetter Andreas ADI SD wrote:
> > An improvement is going into 2.6.19 to handle asynchronous
> > vector reads and writes. This was covered by Linux Weekly
> > News a couple of weeks ago:
> > http://lwn.net/Articles/201682/
>
> That is orthogonal. We don't really need vector io so much, sinc
Hi, Martijn,
Martijn van Oosterhout wrote:
> On Wed, Oct 18, 2006 at 11:36:44AM -0700, Jeff Davis wrote:
>>> What's being suggested simply violates common sense. Basically:
>>>
>>> if (a = b) then (a||c = b||c)
>>>
>> If a is 'x' and b is 'x' and c is NULL, the above statement doesn't hold
>> in P
On 10/19/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> When setting log_statement = 'all', statements that fail parsing are not
> logged.
> Is that intentional?
The 'mod' and 'ddl' settings obviously can't be handled until after
basic parsing. We could c
Hi, Devrim,
Devrim GUNDUZ wrote:
> I have almost finished working on multiple rpm + postmaster issue today.
> The spec file and patches in pgsqlrpms cvs work almost as expected and
> does some preliminary work about multiple postmaster installation issue
> (we can build the rpms and they are inst
Am Freitag, 20. Oktober 2006 15:19 schrieb Markus Schaber:
> Devrim GUNDUZ wrote:
> > I have almost finished working on multiple rpm + postmaster issue today.
> > The spec file and patches in pgsqlrpms cvs work almost as expected and
> > does some preliminary work about multiple postmaster installa
Hi Markus,
On Fri, 2006-10-20 at 15:19 +0200, Markus Schaber wrote:
> Did you look at how the debian guys handle this?
No, but I believe what Peter wrote two days before was a solution of
Debian guys.
Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replica
Hi Peter,
On Fri, 2006-10-20 at 15:37 +0200, Peter Eisentraut wrote:
> > Did you look at how the debian guys handle this?
>
> [EMAIL PROTECTED]:~$ ls -1 /usr/share/locale/de/LC_MESSAGES/p*
Quick question: Could you please point me a way to change the names
of .mo files and make each PostgreSQ
On 10/20/06, Jeremy Drake <[EMAIL PROTECTED]> wrote:
I noticed something odd when trying to use the row-wise comparison
mentioned in the release notes for 8.2 and in the docs
http://developer.postgresql.org/pgdocs/postgres/functions-comparisons.html#ROW-WISE-COMPARISON
This sets up a suitable te
Devrim GUNDUZ wrote:
> Hi Peter,
>
> On Fri, 2006-10-20 at 15:37 +0200, Peter Eisentraut wrote:
> > > Did you look at how the debian guys handle this?
> >
> > [EMAIL PROTECTED]:~$ ls -1 /usr/share/locale/de/LC_MESSAGES/p*
>
>
> Quick question: Could you please point me a way to change the nam
Jeremy Drake <[EMAIL PROTECTED]> writes:
> select rowval from myrowtypetable ORDER BY ROW((rowval).*) USING <;
> ERROR: operator does not exist: record < record
This isn't required by the spec, and it's not implemented. I don't
see that it'd give any new functionality anyway, since you can alway
Hi Alvaro,
On Fri, 2006-10-20 at 10:53 -0300, Alvaro Herrera wrote:
>
> The package files are here:
>
> http://packages.debian.org/unstable/misc/postgresql-8.1
>
> you can find the patch Debian applies following a link below (the
> diff.gz), on which you see the method for doing this.
Thanks.
NikhilS <[EMAIL PROTECTED]> writes:
> Do we have any function in the postgres codebase which provides microseconds
> level of delay coupled with SIGALRM support?
On most Unixen the resolution of SIGALRM is millisecond(s), so you'd be
living in a dream world if you assumed it would work.
On Fri, Oct 20, 2006 at 11:13:33AM +0530, NikhilS wrote:
> >Good idea, but async i/o is generally poorly supported.
> Async i/o is stably supported on most *nix (apart from Linux 2.6.*) plus
> Windows.
> Guess it would be still worth it, since one fine day 2.6.* will start
> supporting it properly
Am Freitag, 20. Oktober 2006 15:53 schrieb Alvaro Herrera:
> ISTM these parts of that patch should be applied to our code:
>
> +--- postgresql-8.1beta3-old/src/bin/pg_controldata/pg_controldata.c
> 2005-10-03 02:28:41.0 +0200
> postgresql-8.1beta3/src/bin/pg_controldata/pg_controlda
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> ISTM these parts of that patch should be applied to our code:
> +--- postgresql-8.1beta3-old/src/bin/pg_controldata/pg_controldata.c
> 2005-10-03 02:28:41.0 +0200
> postgresql-8.1beta3/src/bin/pg_controldata/pg_controldata.c
> 2005-
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > ISTM these parts of that patch should be applied to our code:
>
> > +--- postgresql-8.1beta3-old/src/bin/pg_controldata/pg_controldata.c
> > 2005-10-03 02:28:41.0 +0200
> > postgresql-8.1beta3/src/bin/pg_controldata/
I have a setup in which a table has been partitioned into 30 partitions on
type (1 -30), however no matter what I do i can't make the planner try to use
constraint exclusion on it. As you can see by the plan, it figures that there
is at least 1 rows in each partition (Which there is not). Also
> db=# \d s_ps.tbl_ps_type_1
> Table "s_ps.tbl_ps_type_1"
...
> Check constraints:
> "tbl_ps_typ_1_type_check" CHECK (type = 1)
> Inherits: tbl_ps
...
> myyearbook=# EXPLAIN ANALYZE SELECT uid FROM tbl_ps WHERE
> type = 1 and
> normalized_text='bush';
>
>
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> I have a setup in which a table has been partitioned into 30 partitions on
> type (1 -30), however no matter what I do i can't make the planner try to use
> constraint exclusion on it.
Do you have constraint_exclusion turned on? What are the check
> > >Good idea, but async i/o is generally poorly supported.
> Only if it can be shown that async I/O actually results in an
> improvement.
sure.
> fix it. So, what is the bottleneck? Is PostgreSQL unable to
> max out the I/O bandwidth? Where? Why?
Yup, that would be the scenario where it he
On Friday 20 October 2006 08:26, Tom Lane wrote:
> Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > I have a setup in which a table has been partitioned into 30 partitions
> > on type (1 -30), however no matter what I do i can't make the planner try
> > to use constraint exclusion on it.
>
> Do yo
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> Yes CE is on (you can see it in the session paste). The other child tables
> have simular CHECK's of type=2, type=3, type=4 and so on.. 1 for each of the
> 30 tables.
[ looks again... ] Oh, here's your problem:
type | smallint
On Friday 20 October 2006 09:27, Tom Lane wrote:
> Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > Yes CE is on (you can see it in the session paste). The other child
> > tables have simular CHECK's of type=2, type=3, type=4 and so on.. 1 for
> > each of the 30 tables.
>
> [ looks again... ] Oh,
On Fri, Oct 20, 2006 at 05:37:48PM +0200, Zeugswetter Andreas ADI SD wrote:
> Yup, that would be the scenario where it helps (provided that you have
> a smart disk or a disk array and an intelligent OS aio implementation).
> It would be used to fetch the data pages pointed at from an index leaf,
>
Not sure who cares, so xzilla indicated I should drop a note here. I
just made the xlogdump stuff work for 8.1 (trivial) and fixed a few
other small issues that caused it to not work right both generally
and in our environment.
http://pgfoundry.org/tracker/index.php?
func=detail&aid=10007
On Fri, Oct 20, 2006 at 10:05:01AM -0400, [EMAIL PROTECTED] wrote:
> Only if it can be shown that async I/O actually results in an improvement.
>
> Currently, it's speculation, with the one trial implementation showing
> little to no improvement. Support is a big word in the face of this
> initial
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> Is it possible to create tables in fashion that will not write info
> to the WAL log -- knowingly and intentionally making them
> unrecoverable?
Use temp tables?
Also, it's likely that much of the WAL volume is full-page images.
While you can't
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> + #ifdef WIN32
> + #define _WIN32_WINNT 0x0400
> + #endif
Hmm ... in pg_ctl.c I see
#define _WIN32_WINNT 0x0500
Is there a reason for these to be different? Are there other places
that will need this (ie, maybe it should be in c.h instead?)
On Oct 20, 2006, at 1:58 PM, Tom Lane wrote:
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
Is it possible to create tables in fashion that will not write info
to the WAL log -- knowingly and intentionally making them
unrecoverable?
Use temp tables?
temp tables won't work too well -- unless
> > + #ifdef WIN32
> > + #define _WIN32_WINNT 0x0400
> > + #endif
>
> Hmm ... in pg_ctl.c I see
>
> #define _WIN32_WINNT 0x0500
>
> Is there a reason for these to be different? Are there other
> places that will need this (ie, maybe it should be in c.h instead?)
Not really. The default appear
> On Fri, Oct 20, 2006 at 10:05:01AM -0400, [EMAIL PROTECTED] wrote:
>> One would need to consider the PostgreSQL architecture, determine where
>> the bottleneck actually is, and understand why it is a bottleneck fully,
>> before one could decide how to fix it. So, what is the bottleneck?
I think
On 10/20/06, Tom Lane <[EMAIL PROTECTED]> wrote:
So far I've seen no evidence that async I/O would help us, only a lot
of wishful thinking.
is this thread moot? while researching this thread I came across this
article: http://kerneltrap.org/node/6642 describing claims of 30%
performance boost
On Fri, Oct 20, 2006 at 03:04:55PM -0400, Merlin Moncure wrote:
> On 10/20/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >So far I've seen no evidence that async I/O would help us, only a lot
> >of wishful thinking.
>
> is this thread moot? while researching this thread I came across this
> article:
Holger Schoenen writes:
> ERROR: invalid byte sequence for encoding "UTF8": 0xe46973
> Command was: --
[...]
> -- Started on 2006-09-15 14:56:51 Westeuropäische Normalzeit
The same problem was recently reported on the pgsql-de-allgemein list.
Would just avoiding %Z in Win32's strftime be an
On Fri, 2006-10-20 at 12:27 -0400, Tom Lane wrote:
> > This was a direct port from a big fat table. I agree, I'm not
> convinced that
> > the partial indexes will buy me much, but this box is so IO bound
> that the
> > planner overhead my just offset the needing to IO bigger indexes.
>
> Well,
Hi,
On Fri, 2006-10-20 at 10:25 -0400, Tom Lane wrote:
>
> Egad. What an ugly, unmaintainable crock.
I want to second this. I would not make this in RPM spec file.
What about changing
localedir='${prefix}/share/locale'
line (in configure) to
localedir='${prefix}/share/locale/pgsql/$PGMAJOR
Tom Lane wrote:
> Egad. What an ugly, unmaintainable crock.
There is one major PostgreSQL release per year, so even the time
thinking about an alternative solution is longer than just taking the
existing solution.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
-
On Fri, 2006-10-20 at 11:50 +0200, Andreas Pflug wrote:
> Having pg_dump not saving the function definitions is an intended
> behaviour.
The manual defines the pg_catalog schema as containing "the system
tables and all the built-in data types, functions, and
operators" (section 5.7.5). adminpack i
On Fri, 2006-10-20 at 05:52 +0100, Dave Page wrote:
> The adminpack was originally written and intended to become builtin
> functions
This is not unique to adminpack: several contrib modules might
eventually become (or have already become) builtins, but adminpack is
the only module that defines ob
Devrim GUNDUZ wrote:
> localedir='${prefix}/share/locale/pgsql/$PGMAJORVERSION'
It's probably better not to create nonstandard directories
below /usr/share/locale, because that's not your directory. If you
want to go with nonstandard paths, create one
in /usr/share/postgresql/.
--
Peter Eise
On Fri, 2006-10-20 at 13:18 -0400, Theo Schlossnagle wrote:
> Not sure who cares, so xzilla indicated I should drop a note here. I
> just made the xlogdump stuff work for 8.1 (trivial) and fixed a few
> other small issues that caused it to not work right both generally
> and in our environme
Neil Conway wrote:
> Why does adminpack install functions into pg_catalog? This is
> inconsistent with the rest of the contrib/ packages, not to mention
> the definition of pg_catalog itself (which ought to hold builtin
> object definitions).
Nothing except initdb should add objects in pg_catalog.
On Oct 20, 2006, at 4:24 PM, Simon Riggs wrote:
On Fri, 2006-10-20 at 13:18 -0400, Theo Schlossnagle wrote:
Not sure who cares, so xzilla indicated I should drop a note here. I
just made the xlogdump stuff work for 8.1 (trivial) and fixed a few
other small issues that caused it to not work ri
Neil Conway wrote:
> On Fri, 2006-10-20 at 05:52 +0100, Dave Page wrote:
>
>> The adminpack was originally written and intended to become builtin
>> functions
>>
>
> This is not unique to adminpack: several contrib modules might
> eventually become (or have already become) builtins, but adm
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Where are we on releasing beta2 or perhaps going right to an RC1
> > release? Seems it is time for one of them.
>
> I think we need a beta2 now, and perhaps RC1 in a week. We've done
> enough portability hacking recently that some m
On Fri, 20 Oct 2006, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > select rowval from myrowtypetable ORDER BY ROW((rowval).*) USING <;
> > ERROR: operator does not exist: record < record
>
> This isn't required by the spec, and it's not implemented. I don't
> see that it'd give
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think we need a beta2 now, and perhaps RC1 in a week. We've done
>> enough portability hacking recently that some more beta seems indicated.
> OK, what steps do we need to do to get beta2 out?
I think all we really gotta do is upda
Jeremy Drake <[EMAIL PROTECTED]> writes:
> I just think it is quite unexpected that the operator < is defined in some
> places and not in others.
Row-wise comparison isn't an operator, it's a syntactic construct.
Consider
(now(), 'foo', 42) < (SELECT timestampcol, textcol, intcol FROM sometable W
Hi everybody,I have started to work on a project that will be implemented on top of Postgresql. Therefore, I have to warm up with postgresql's internals. I downloaded the source code and currently looking at it. But I have some questions?1. How can I prepare my own query plan? (I will need this bec
Hi .*Is there any chance to see the quota implementation described in this post in any next releases?http://archives.postgresql.org/pgsql-hackers/2004-07/msg00392.php
Thanks you!Nick
On 10/21/06, Martijn van Oosterhout wrote:
On Fri, Oct 20, 2006 at 03:04:55PM -0400, Merlin Moncure wrote:
> On 10/20/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >So far I've seen no evidence that async I/O would help us, only a lot
> >of wishful thinking.
>
> is this thread moot? while researchi
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
> Nothing except initdb should add objects in pg_catalog. AFAICS,
> adminpack doesn't have any special requirements, so it should behave
> like all other contrib modules.
Okay. Are there any opinions on whether we should make this chang
On Fri, 2006-10-20 at 16:05 -0700, dakotali kasap wrote:
> 1. How can I prepare my own query plan?
You can't: there is currently no public API for constructing plans by
hand. You could kludge something up by hand, but it would be pretty
fragile (internal planner data structures may well change bet
from my understanding, postgres first needs to partition the tables.
ExecHashTableCreate() is the function that partitions the tables right?
Martijn van Oosterhout wrote:
On Sun, Oct 15, 2006 at 11:08:18PM -0400, HS wrote:
Hello there
I am trying to play around with the hashjoin algorithm in
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> + #ifdef WIN32
>>> + #define _WIN32_WINNT 0x0400
>>> + #endif
>>
>> Hmm ... in pg_ctl.c I see
>>
>> #define _WIN32_WINNT 0x0500
>>
>> Is there a reason for these to be different? Are there other
>> places that will need this (ie, maybe it shoul
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
>> Nothing except initdb should add objects in pg_catalog. AFAICS,
>> adminpack doesn't have any special requirements, so it should behave
>> like all other contrib modules.
> Okay. Are there an
> >>> + #ifdef WIN32
> >>> + #define _WIN32_WINNT 0x0400
> >>> + #endif
> >>
> >> Hmm ... in pg_ctl.c I see
> >>
> >> #define _WIN32_WINNT 0x0500
> >>
> >> Is there a reason for these to be different? Are there
> other places
> >> that will need this (ie, maybe it should be in c.h instead?)
>
63 matches
Mail list logo