On Fri, Feb/ 2/07 11:20:07PM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> writes:
> > On Fri, Feb/ 2/07 10:52:28PM -0500, Tom Lane wrote:
> >> I wouldn't really have expected that to happen on any *BSD, but you
> >> could look into the generated Makefile.global to find out.
>
> > I don't se
Kate F <[EMAIL PROTECTED]> writes:
> On Fri, Feb/ 2/07 10:52:28PM -0500, Tom Lane wrote:
>> I wouldn't really have expected that to happen on any *BSD, but you
>> could look into the generated Makefile.global to find out.
> I don't see anything that looks relevant for my Makefile.global; I
> would
On Fri, Feb/ 2/07 10:52:28PM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> writes:
> > ... does PostgreSQL replace my system's snprintf() prototype with
> > its own implementation's?
>
> We do on some platforms where configure decides the system version
> is deficient ... I don't recall the
Kate F <[EMAIL PROTECTED]> writes:
> ... does PostgreSQL replace my system's snprintf() prototype with
> its own implementation's?
We do on some platforms where configure decides the system version
is deficient ... I don't recall the exact conditions at the moment.
I wouldn't really have expected
Hello,
I've been implementing a type I needed, and happened to be using
snprintf(), since I have C99 available.
ereport(NOTICE,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("%d", snprintf(NULL, 0, "abc";
For me, this reports "0". I beieve it sh
Clarification, this is the email used to make the patch that was
backpatched.
---
Albe Laurenz wrote:
> >>> I have tried --with-thread-safety and configure fails on ldap check
> >>> because for some reason CTHREAD_FLAGS (-Kp
Is this a TODO item?
---
ITAGAKI Takahiro wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> wrote:
>
> > I think what you are saying is: VACUUM places blocks so that they are
> > immediately reused. This stops shared_buffers from
On Fri, Feb 02, 2007 at 08:56:31PM -0500, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > I want to ask, should I break with following substring's
> > precedent, and put the pattern first (as most people probably
> > would expect), or should I break with perl's precedent and put the
Jeremy Drake <[EMAIL PROTECTED]> writes:
> I want to ask, should I break with following substring's precedent, and
> put the pattern first (as most people probably would expect), or should I
> break with perl's precedent and put the pattern second (to behave like
> substring)?
All of SQL's pattern
Simon Riggs wrote:
My earlier thinking was that Oracle appears to be able to avoid locking
and my thought was that this was simply a rather dodgy interpretation of
the SQL Standard. Anyway, I'm not happy with simply forgetting the SHARE
lock; that clearly leads to invalid states in some cases, ev
On Fri, 2 Feb 2007, Jeremy Drake wrote:
> I just coded up for this:
>
> CREATE FUNCTION regexp_matches(IN str text, IN pattern text) RETURNS
> text[]
> AS 'MODULE_PATHNAME', 'regexp_matches'
> LANGUAGE C IMMUTABLE STRICT;
>
> CREATE FUNCTION regexp_matches(
> IN str text, IN patter
Thread added to TODO for item:
* Allow sequential scans to take advantage of other concurrent
sequential scans, also called "Synchronised Scanning"
---
Jeff Davis wrote:
> I have updated my Synchronized Scan patch and ha
Thread added to TODO list:
* Reduce checkpoint performance degredation by forcing data to disk
more evenly
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00337.php
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00079.php
-
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2007-02-02 at 15:57 -0500, Tom Lane wrote:
>> , and it doesn't scale to
>> more than two holders, and I don't think it works for combinations of
>> share and exclusive lock. Also, what happened to the third type of lock?
> Well, we just need to
"Ioseph Kim" <[EMAIL PROTECTED]> writes:
> when @-@ operator used at path type,
> below query maybe returns 1.
> because this path is just line.
No, because it's a closed path, so it's a loop from (0,0) to (1,0)
and back again. If you don't want to count the return segment,
use an open path.
I misunderstood. :)
path '((0,0),(1,0))' is 'closed' path.
in this case, it's maybe operator calculated return length too.
- Original Message -
From: "Ioseph Kim" <[EMAIL PROTECTED]>
To:
Sent: Saturday, February 03, 2007 6:00 AM
Subject: Re: [HACKERS] problem of geometric operator in
On Fri, 2007-02-02 at 15:57 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Thus we have three types of write lock:
> > 1. full row write lock
> > as well as two mutually exclusive groups of columns:
> > 2.a) PK cols
> > 2.b) all columns apart from the PK cols
>
> This appea
imad <[EMAIL PROTECTED]> writes:
> So, should we still consider it a ToDo?
Whatever you think about the rename-in-same-block-as-declared case,
it's still broken, as per my example showing that the effects are not
limited to the containing block. However, considering that no one
has taken an inter
when @-@ operator used at path type,
below query maybe returns 1.
because this path is just line.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Ioseph Kim" <[EMAIL PROTECTED]>
Cc:
Sent: Saturday, February 03, 2007 5:36 AM
Subject: Re: [HACKERS] problem of geometric op
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Thus we have three types of write lock:
> 1. full row write lock
> as well as two mutually exclusive groups of columns:
> 2.a) PK cols
> 2.b) all columns apart from the PK cols
This appears to require that we add enough fields to row headers to
represent
"Ioseph Kim" <[EMAIL PROTECTED]> writes:
> => select @-@ lseg '((0,0),(1,0))';
> ?column?
> --
> 1
> (1 row)
> => select @-@ path '((0,0),(1,0))';
> ?column?
> --
> 2
> (1 row)
> It's maybe bug in v8.2.1
What do you think is wrong with those answers?
On Fri, 2007-02-02 at 10:35 -0800, Stephan Szabo wrote:
> On Fri, 2 Feb 2007, Simon Riggs wrote:
>
> > It sounds like if we don't put a SHARE lock on the referenced table then
> > we can end the transaction in an inconsistent state if the referenced
> > table has concurrent UPDATEs or DELETEs. BUT
I've been looking into Pavan Deolasee's recent discovery that when
storing a maximum-length toast tuple, heap_insert uselessly recurses
to toast_insert_or_update, wasting a nontrivial number of cycles.
It turns out there are several interrelated mistakes here, which are
wasting space as well as cyc
On Thu, 2007-02-01 at 23:57 -0600, Jim Nasby wrote:
> Has anyone actually measured the performance overhead of storing
> visibility info in indexes? I know the space overhead sounds
> daunting, but even if it doubled the size of the index in many cases
> that'd still be a huge win over having
On Fri, 2007-02-02 at 12:01 +0100, Csaba Nagy wrote:
> > You say below the cut that you're not updating keys, so presumably it's
> > other columns. Which leads me to something I've wondered for a while -
> > why do we lock the whole row? Is it just a matter of "not optimised that
> > yet" or is
=> select @-@ lseg '((0,0),(1,0))';
?column?
--
1
(1 row)
=> select @-@ path '((0,0),(1,0))';
?column?
--
2
(1 row)
--
It's maybe bug in v8.2.1
---(end of broadcast)---
TIP 4: Have you searched our list arc
>> If we did what you suggest, then --enable-debug would cause performance
>> degradation, which would cause people to not use it, which would result
>> in most binaries being completely undebuggable rather than only partially.
>> Doesn't sound like a good tradeoff to me.
>>
>> Personally, in my de
On 2/2/07, Jim Nasby <[EMAIL PROTECTED]> wrote:
On Feb 1, 2007, at 5:08 AM, Pavel Stehule wrote:
> std. use rename only for triggers and variables new and old. It has
> sense. I don't see sense for rename in clasic plpgsql functions.
> There was one reason, rename unnamed $params. But currently p
On Fri, 2 Feb 2007, Simon Riggs wrote:
> It sounds like if we don't put a SHARE lock on the referenced table then
> we can end the transaction in an inconsistent state if the referenced
> table has concurrent UPDATEs or DELETEs. BUT those operations do impose
> locking rules back onto the referenc
On Fri, Feb/ 2/07 11:37:13AM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> writes:
> > So, to conclude, we still have a valid use-case (which you explained a
> > little more explicitly than I did). Shall I attempt to implement it?
> > (that is, type_name_of() which returns TEXT)
>
> I think
On Fri, Feb 02, 2007 at 12:54:30AM -0800, Jeremy Drake wrote:
> On Fri, 2 Feb 2007, Jeremy Drake wrote:
>
> > jeremyd=# select * from regexp_matches('foobarbequebaz',
> > $re$(bar)(beque)$re$, false);
> > prematch | fullmatch | matches | postmatch
> > --+---+-+
But I think a way to get around that would be to RENAME the arguments in
the DECLARE section, so user_id could become p_user_id under the covers.
It's one case. But I don't belive so result will be more readable. Better
solution is using names qualificated by function name. I am not sure
From: Tom Lane <[EMAIL PROTECTED]>
To: "Pavel Stehule" <[EMAIL PROTECTED]>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] proposal: only superuser can change
customized_options Date: Fri, 02 Feb 2007 11:40:10 -0500
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I want to use custmiz
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database configurable tslog_priority is given, the
timestamp will be truncated to milliseconds and the increment logic
is done on milliseconds. The priority is added to the timestamp.
This guarantees that no two timestamps for commits wi
On Tue, Jan 30, 2007 at 12:39:26PM -0500, Bruce Momjian wrote:
> I would like to clean up our documentation to consistently use these
> words. Objections?
None here, but if you're going to go to the trouble, you might want
to have a look at how others have faced this problem too.
In my line of w
On Feb 1, 2007, at 5:08 AM, Pavel Stehule wrote:
std. use rename only for triggers and variables new and old. It has
sense. I don't see sense for rename in clasic plpgsql functions.
There was one reason, rename unnamed $params. But currently plpgsql
support named params and this reason is ob
Would it be safe/appropriate to do a "What's new in 8.3" talk? (Went
to OSCON last year, but didn't make it to any talks).
On Jan 30, 2007, at 4:22 PM, Josh Berkus wrote:
All,
We only have five days left to submit talks for OSCON (Portland,
last week
of July): http://conferences.oreillyne
On Jan 30, 2007, at 1:17 PM, Simon Riggs wrote:
It would be even better if there was some way of not executing the
trigger at all if we knew that the UPDATE statement doesn't SET the FK
columns.
Other databases allow you to put a WHERE or CHECK clause on triggers,
so that they will only fire
On Feb 1, 2007, at 10:57 AM, Tom Lane wrote:
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
I'm thinking to add "the number of vacuumed tuples" to the message
from
vacuum. The stats collector will subtract the value from
n_dead_tuples
instead of setting it to zero. This is also needed if we wa
On Jan 30, 2007, at 6:32 PM, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
I'm thinking to write an INFO message, so that people can choose
to log
this and/or the SQL statement if they choose.
e.g. INFO: lock wait time of XXX secs has been exceeded
The available timer resources a
I thought the drive behind full_page_writes = off was to reduce the
amount of data being written to pg_xlog, not to shrink the size of a
PITR log archive.
ISTM that if you want to shrink a PITR log archive you'd be able to
get good results by (b|g)zip'ing the WAL files in the archive. I
q
Has anyone actually measured the performance overhead of storing
visibility info in indexes? I know the space overhead sounds
daunting, but even if it doubled the size of the index in many cases
that'd still be a huge win over having to scan the heap as well as
the index (esp. for things li
On Jan 29, 2007, at 11:28 PM, Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
I don't actually see that it buys you a darn thing ... you still
won't
be able to delete dead updated tuples because of the possibility of
the LRT deciding to chase
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I want to use custmized option for security configuration one contrib
> library. Currently customized options are usable only for default
> configuration, because everybody can change it. It is substitution of global
> variables.
> Decision if option
Kate F <[EMAIL PROTECTED]> writes:
> So, to conclude, we still have a valid use-case (which you explained a
> little more explicitly than I did). Shall I attempt to implement it?
> (that is, type_name_of() which returns TEXT)
I think I'd suggest pg_type_name ... or maybe pg_type_name_of ...
also,
Hello
I want to use custmized option for security configuration one contrib
library. Currently customized options are usable only for default
configuration, because everybody can change it. It is substitution of global
variables.
Decision if option is protected or not can be based on name of
On Fri, Feb/ 2/07 11:17:46AM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> writes:
> > (And whatever the decision regarding ANYELEMENT of, I believe this
> > should behave the same as IS OF)
>
> In the light of morning I think it may be a non-problem. The way that a
> plpgsql function with
Kate F <[EMAIL PROTECTED]> writes:
> (And whatever the decision regarding ANYELEMENT of, I believe this
> should behave the same as IS OF)
In the light of morning I think it may be a non-problem. The way that a
plpgsql function with an ANYELEMENT parameter really works is that on
first invocation
Tom Lane wrote:
> NikhilS <[EMAIL PROTECTED]> writes:
> > True, this is how I myself circumvent this problem too. But IMHO,
> > explicitly passing CFLAGS when we are invoking --enable-debug (which does
> > add -g, but leaves some optimization flag around which deters debugging)
> > does not seem co
On Fri, Feb/ 2/07 09:52:08AM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> writes:
> > In my case, I am constructing a query (to be exexecuted dynamically)
> > wherein I pass along some of the arguments I am given. This query calls
> > a function specified by an argument passed to me. If that
On Fri, Feb/ 2/07 10:09:24AM +, Richard Huxton wrote:
> Kate F wrote:
> >I see my misunderstanding: '2' IS OF (INTEGER) yields false: fine.
> >However I was expecting that pg_type_of('2') would return 'INTEGER': it
> >wouldn't, of course. So, I understand you here: there would be no
> >differen
NikhilS <[EMAIL PROTECTED]> writes:
> True, this is how I myself circumvent this problem too. But IMHO,
> explicitly passing CFLAGS when we are invoking --enable-debug (which does
> add -g, but leaves some optimization flag around which deters debugging)
> does not seem correct?
If we did what you
Kate F <[EMAIL PROTECTED]> writes:
> In my case, I am constructing a query (to be exexecuted dynamically)
> wherein I pass along some of the arguments I am given. This query calls
> a function specified by an argument passed to me. If that function is
> overloaded, I need to be able to cast its arg
Jochem van Dieten wrote:
On 2/1/07, Chris Dunlop wrote:
In maillist.postgres.dev, you wrote:
Rather than writing in-place, perhaps the SET ARCHIVE would
create a on-disk copy of the table.
Just like CLUSTER does now: create an on-disk copy first and swap the
relfilenodes of the files and flush
On Thu, 1 Feb 2007, Bruce Momjian wrote:
>
> Where are we on this patch? Does it have performance tests to show
> where it is beneificial? Is it ready to be reviewed?
Here's an updated patch:
http://www.alcove.com.au/~swm/bitmap-2007-02-02.patch
In this patch, I rewrote the index build system
Csaba Nagy wrote:
The reason of the occasional orphan rows is not completely clear to me,
but it must be some kind of race condition while
inserting/deleting/?updating concurrently the parent/child tables.
I guess the following sequence would generate a orphaned row.
A: executes "insert into ta
> You say below the cut that you're not updating keys, so presumably it's
> other columns. Which leads me to something I've wondered for a while -
> why do we lock the whole row? Is it just a matter of "not optimised that
> yet" or is there a good reason why locking just some columns isn't
> pr
Ühel kenal päeval, N, 2007-02-01 kell 12:31, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > A more radical variation of the "restricted-use archive table" approach
> > is storing all tuple visibility info in a separate file.
> > At first it seems to just add overhead, but for lo
Csaba Nagy wrote:
On Fri, 2007-02-02 at 10:51, Simon Riggs wrote:
[snip]
Why do we need a SHARE lock at all, on the **referenc(ed)** table?
Well, here we do have a patch (deployed on production servers) which
does not put the shared lock on the referenced table, and it lets in
occasionally ro
On Fri, 2007-02-02 at 10:51, Simon Riggs wrote:
[snip]
> Why do we need a SHARE lock at all, on the **referenc(ed)** table?
>
> It sounds like if we don't put a SHARE lock on the referenced table then
> we can end the transaction in an inconsistent state if the referenced
> table has concurrent UP
Kate F wrote:
I see my misunderstanding: '2' IS OF (INTEGER) yields false: fine.
However I was expecting that pg_type_of('2') would return 'INTEGER': it
wouldn't, of course. So, I understand you here: there would be no
difference between this and IS OF in the way I had imagined.
It's not even p
I'm reading the SQL Standard and I can't find anywhere that says that we
need to place SHARE locks on rows in the referenced table.
RI_FKey_check() clearly does that.
What I do see is this:
"4. For each row of the referenced table, its matching rows, unique
matching rows, and non-unique matching r
On Wed, Jan 31, 2007 at 03:24:24PM -0800, elein wrote:
> Pretty darn vanilla, except for source packages from postgres.
Which Debian version?
I take it you got this message on a full rebuild from clean sources,
right?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Mes
Hi,
On 2/2/07, Gavin Sherry <[EMAIL PROTECTED]> wrote:
On Fri, 2 Feb 2007, NikhilS wrote:
> Hi,
>
> Indeed it does, apologies for not doing the entire groundwork. But what
it
> also does is that it adds -O2 by default for gcc even when
--enable-debug is
> specified. gdb is not able to navigate
On Fri, 2 Feb 2007, NikhilS wrote:
> Hi,
>
> Indeed it does, apologies for not doing the entire groundwork. But what it
> also does is that it adds -O2 by default for gcc even when --enable-debug is
> specified. gdb is not able to navigate the stack traces properly with this
> optimization in plac
On Thu, Feb 01, 2007 at 06:25:50PM +0100, Stefan Kaltenbrunner wrote:
> >BTW, this is a perfect example of why it's not a good idea to allow
> >minor regression failures to go unfixed --- people become desensitized.
> >I know I've been completely ignoring ECPG-Check buildfarm results
> >for awhile
On Fri, 2 Feb 2007, Jeremy Drake wrote:
> jeremyd=# select * from regexp_matches('foobarbequebaz',
> $re$(bar)(beque)$re$, false);
> prematch | fullmatch | matches | postmatch
> --+---+-+---
> \N | \N| {bar,beque} | \N
> (1 row)
I just chang
Hi,
Indeed it does, apologies for not doing the entire groundwork. But what it
also does is that it adds -O2 by default for gcc even when --enable-debug is
specified. gdb is not able to navigate the stack traces properly with this
optimization in place. Especially tracing of static functions beco
On Fri, Feb/ 2/07 03:06:19AM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> writes:
> > The difference between OF and this function is that this function is
> > pulling the type from the datum, rather than explicitly testing it
> > against types the user suggests. If I wanted to find the type
On Fri, 2 Feb 2007, NikhilS wrote:
> Hi,
>
> configure with --enable-debug does not seem to add "-g" to CFLAGS while
> compiling with gcc. Guess we will need to change configure.in as below:
Erm... works for me and everyone else... AFAIK.
Thanks,
Gavin
---(end of broadc
Hi,
configure with --enable-debug does not seem to add "-g" to CFLAGS while
compiling with gcc. Guess we will need to change configure.in as below:
***
# supply -g if --enable-debug
! if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then
CFLAGS="$CFLAGS -g"
fi
--
On Thu, 1 Feb 2007, David Fetter wrote:
> Yes, although it might have the same name, as in regex_match(pattern
> TEXT, string TEXT, return_pre_and_post BOOL).
>
> The data structure could be something like
>
> TYPE matches (
> prematch TEXT,
> matchTEXT[],
> postmatch TEXT
> )
I
Kate F <[EMAIL PROTECTED]> writes:
> The difference between OF and this function is that this function is
> pulling the type from the datum, rather than explicitly testing it
> against types the user suggests. If I wanted to find the type of x
> using OF, I would have to check it for all types whic
73 matches
Mail list logo
