On Mon, 2008-07-07 at 11:03 +0900, ITAGAKI Takahiro wrote:
Simon Riggs [EMAIL PROTECTED] wrote:
The attached patch (executor_hook.patch) modifies HEAD as follows.
- Add tag field (uint32) into PlannedStmt.
- Add executor_hook to replace ExecutePlan().
- Move ExecutePlan() to a
Hi,
From: Hans-Juergen Schoenig [EMAIL PROTECTED]
Subject: Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
Date: Sat, 5 Jul 2008 10:43:57 +0200
i did some quick testing with this wonderful patch.
it seems there are some flaws in there still:
test=# explain select count(*)
test-#
David E. Wheeler napsal(a):
Replying to myself, but I've made some local changes (see other
messages) and just wanted to follow up on some of my own comments.
On Jul 2, 2008, at 21:38, David E. Wheeler wrote:
4) Operator = citext_eq is not correct. See comment
[EMAIL PROTECTED] wrote:
Hello guys,
This is my first post to this list..
I'm using PostgreSQL8.3.3 and I moved postgresql.conf to the
outside of DATA direcotory, and invoked postgres via pg_ctl
as following.
pg_ctl -w -D /data -o '--config-file=/home/hirano/postgresql.conf' start
This
I'm about to add/cleanup some missing descriptions for aggregates and
functions (such as corr(), enum_first()) and discovered that stddev(),
min() and others doesn't have a pg_description entry, too. Is there a
reason for that? Maybe keep off redundant information from pg_description?
--
Teodor Sigaev wrote:
Sync with current CVS HEAD and post in hackers- too because patches-
close to the closing.
http://www.sigaev.ru/misc/multicolumn_gin-0.3.gz
I looked this over and it looks good in general. I was only wondering
about for single-column indexes -- we're storing attribute
There's a behavior in pg_dump that annoyed me a little bit, the last few
times i had to deal with it:
Consider you have to dump a specific namespace only, you are going to use
pg_dump -n your_schema [-t tables].
I found it a common use case to restore this dump into a different schema
by
I looked this over and it looks good in general. I was only wondering
about for single-column indexes -- we're storing attribute numbers too,
right?
No, GinState-oneCol field signals to GinFormTuple and
gin_index_getattr/gintuple_get_attrnum about actual storage.
Single column index is binary
Teodor Sigaev wrote:
I looked this over and it looks good in general. I was only wondering
about for single-column indexes -- we're storing attribute numbers too,
right?
No, GinState-oneCol field signals to GinFormTuple and
gin_index_getattr/gintuple_get_attrnum about actual storage.
Bernd Helmle [EMAIL PROTECTED] writes:
I found it a common use case to restore this dump into a different schema
by simply changing the search_path. With included ownerships this doesn't
work, since pg_dump always outputs the necessary DDL as follows:
ALTER TABLE bernd.foo OWNER TO bernd;
On Mon, Jul 07, 2008 at 04:22:21PM +0900, Yoshiyuki Asaba wrote:
Hi,
test=# explain select count(*)
test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL
SELECT DISTINCT n+1 FROM t )
test(# SELECT * FROM t WHERE n 50) as t
test-# WHERE n
David E. Wheeler napsal(a):
On Jun 27, 2008, at 18:22, David E. Wheeler wrote:
Please find attached a patch adding a locale-aware, case-insensitive
text type, called citext, as a contrib module.
Here is a new version of the patch, with the following changes:
* Fixed formatting to be more
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-07-07 at 11:03 +0900, ITAGAKI Takahiro wrote:
One issue is tag field. The type is now uint32. It's enough in my plugin,
but if some people need to add more complex structures in PlannedStmt,
Node type would be better rather than uint32. Which
--On Montag, Juli 07, 2008 10:33:35 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
It seems like quite a useless change, since in general there will be
other qualified references in the dump that can't safely be removed.
IOW what you intend to do doesn't work anyway.
Hmm, If i want to restore just
Zdenek Kotala wrote:
2) contrib vs. pgFoundry
There is unresolved answer if we want to have this in contrib or not.
Good to mention that citext type will be obsoleted with full collation
implementation in a future. I personally prefer to keep it on
pgFoundry because it is temporally
Why is deadlock_timeout set at SIGHUP?
If it effects statement behaviour it ought to be a USERSET. Using CPU
time isn't a problem we protect against anywhere else.
I'd like to be able to set deadlock-prone transactions lower, yet keep a
fairly high setting for others.
--
Simon Riggs
Bernd Helmle [EMAIL PROTECTED] writes:
--On Montag, Juli 07, 2008 10:33:35 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
It seems like quite a useless change, since in general there will be
other qualified references in the dump that can't safely be removed.
IOW what you intend to do doesn't work
I notice log_temp_files is a PGC_USERSET parameter, which is out of step
with our current thinking on who is allowed to initiate logging.
Is there a rationale for this? Or should we set this to PGC_SUSET like
all the other logging functions?
--
Simon Riggs www.2ndQuadrant.com
Bernd Helmle wrote:
--On Montag, Juli 07, 2008 10:33:35 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
It seems like quite a useless change, since in general there will be
other qualified references in the dump that can't safely be removed.
IOW what you intend to do doesn't work anyway.
Hmm, If
Simon Riggs [EMAIL PROTECTED] writes:
Why is deadlock_timeout set at SIGHUP?
Because it's not clear what the behavior would be like if different
backends had different settings ... except that it'd probably be
surprising.
regards, tom lane
--
Sent via pgsql-hackers
--On Montag, Juli 07, 2008 11:09:56 -0400 Andrew Dunstan
[EMAIL PROTECTED] wrote:
I don't think in general we need to provide pg_dump with every possible
permutation of uses that can achieved with the construction of simple
tool chains.
I always feel the same. However, i thought it would be
On Mon, 2008-07-07 at 11:16 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Why is deadlock_timeout set at SIGHUP?
Because it's not clear what the behavior would be like if different
backends had different settings ... except that it'd probably be
surprising.
Yeh, agreed. I
Am Donnerstag, 26. Juni 2008 schrieb KaiGai Kohei:
The following patch set (r926) are updated one toward the latest CVS head,
and contains some fixes in security policy and documentation.
OK, I have quickly read through these patches. They look very nice, so I am
optimistic we can get through
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
Once again: the whole algorithm is a ripoff from analyze.c, with the
dllist instead of an array because you don't know how big tracking list
will you need and with a hashtable, because the tracking list will
probably be large and
From: Andrew Dunstan [EMAIL PROTECTED]
Subject: Re: [HACKERS] pg_ctl -w with postgresql.conf in non-default path
Date: Mon, 07 Jul 2008 09:07:14 -0400
Try setting the port for pg_ctl: PGPORT=nnn pg_ctl -D datadir -w start
Thank you, andrew, I understand what I did was not right way to specify
Tom, et al,
Looks like Andrew's GSoC student has gotten busy at his new job, so I'm
back on to this and hope to have a new patch ready to go for the Sept.
commitfest. If anyone's interested in helping out, feel free to drop me
a line.
* Tom Lane ([EMAIL PROTECTED]) wrote:
It occurs to me that
On Sun, 2008-07-06 at 17:58 +, Dean Rasheed wrote:
OK, this one should work against CVS HEAD.
OK, still getting some offsets, but it applies.
The patch now outputs things in a useful way to avoid a flood of
information, that's good.
The code seems fine, but it doesn't link up with the
On Jul 7, 2008, at 00:46, Zdenek Kotala wrote:
You have to use varstr_cmp in citextcmp. Your code is correct,
because for
= = operators you need collation sensible function.
You need to change only citext_cmp function to use strncmp() or call
texteq function.
I'm confused. What's the
On Jul 7, 2008, at 07:41, Zdenek Kotala wrote:
However, It seems to me that code is ok now (exclude citex_eq). I
think there two open problems/questions:
1) regression test -
a) I think that regresion is not correct. It depends on en_US
locale, but it uses characters which is not in
On Jul 7, 2008, at 08:01, Andrew Dunstan wrote:
What does still bother me is its performance. I'd like to know if
any measurement has been done of using citext vs. a functional index
on lower(foo).
That's a good question. I can whip up a quick test by populating a
column full of data and
Peter,
Are there any comments yet from the (Trusted)Solaris people that wanted to
evaluate this approach for compatibility with their approach?
In case they're not paying attention, a month ago the Trusted Solaris
folks said the general approach was fine, but that they would likely
want to
Brendan, all:
I mentioned to Alvaro over IM that I was thinking about adding a
navigation bar at the bottom of each commitfest. This would show,
e.g., for the current July commitfest:
Hmmm. I thought that commitfest-by-wiki was something that we were only
doing until we had the technical
Dave Page wrote:
it concerns me that despite it being day 3 of the July commit fest,
people are still being advised to add new items to the wiki page.
To make the idea work, we need to stick to the rules we defined when
we came up with the concept - specifically, no new patches once the
fest
On Tue, Jul 8, 2008 at 3:33 AM, Josh Berkus [EMAIL PROTECTED] wrote:
Hmmm. I thought that commitfest-by-wiki was something that we were only
doing until we had the technical requirements for tracking commitfests
nailed down, and then we were going to write a PHP app. No?
That sounds good to
On Mon, Jun 30, 2008 at 05:30:19PM +0200, Magnus Hagander wrote:
David Fetter wrote:
On Mon, Jun 30, 2008 at 01:50:26PM +0200, Magnus Hagander wrote:
David Fetter wrote:
[gitosis]
I'm not sure I agree that this is a big problem, but sure, we
should at least consider git-shell.
Brendan,
What I'm saying is, I've got the opportunity and the inclination to
make the wiki more usable. If you guys want better navigation,
there's a suggestion on the table to improve that. I'm not too
worried about the wiki eventually being ditched for something better
-- in fact I'm
Hackers,
I've gone through the first round of round robin reviewer assignments.
Each of you who volunteered and doesn't already have a patch should
now have a personal e-mail from me.
I'm taking the approach of assigning each reviewer one patch, with the
idea of getting it done before
I have developed the first part on my patch to get postgres running
natively on 64-bit Windows. It makes no changes to the postgres code
besides adding some win64 specific header files to the port directory.
The rest of it is modifications to the Perl scripts in src/tools/msvc
to get everything
On 7/5/08, Robert Treat [EMAIL PROTECTED] wrote:
I think people are still working there way through the process, but it's
starting to sound like submitting a patch involves two steps from now on;
email to the list, and add your patch to the next commitfest page. Does that
sound right?
Jaime Casanova [EMAIL PROTECTED] writes:
On 7/5/08, Robert Treat [EMAIL PROTECTED] wrote:
I think people are still working there way through the process, but it's
starting to sound like submitting a patch involves two steps from now on;
email to the list, and add your patch to the next
David E. Wheeler wrote:
On Jul 7, 2008, at 00:46, Zdenek Kotala wrote:
You have to use varstr_cmp in citextcmp. Your code is correct,
because for
= = operators you need collation sensible function.
You need to change only citext_cmp function to use strncmp() or call
texteq function.
On Jul 7, 2008, at 11:44, Alvaro Herrera wrote:
I'm confused. What's the difference between strncmp() and
varstr_cmp()?
And why would I use one in one place and the other elsewhere?
Shouldn't
they be used consistently?
Not necessarily -- see texteq. I think the point is that varstr_cmp()
David E. Wheeler wrote:
On Jul 7, 2008, at 11:44, Alvaro Herrera wrote:
I'm confused. What's the difference between strncmp() and
varstr_cmp()?
And why would I use one in one place and the other elsewhere?
Shouldn't
they be used consistently?
Not necessarily -- see texteq. I think
David E. Wheeler napsal(a):
On Jul 7, 2008, at 07:41, Zdenek Kotala wrote:
However, It seems to me that code is ok now (exclude citex_eq). I
think there two open problems/questions:
1) regression test -
a) I think that regresion is not correct. It depends on en_US locale,
but it uses
Hi all,
I'm looking for materials explaining GEQO module. I've found
something related in
http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg40584.html
and PostgreSQL's documentation.
Nevertheless, is there some other cientific publication about it?
I've tried also send email to
On Thu, Jul 3, 2008 at 10:57 PM, Andrew Hammond
[EMAIL PROTECTED] wrote:
On Thu, Jul 3, 2008 at 3:47 PM, Tom Lane [EMAIL PROTECTED] wrote:
Have you looked into the machine's kernel log to see if there is any
evidence of low-level distress (hardware or filesystem level)? I'm
wondering if
Andrew Dunstan napsal(a):
Zdenek Kotala wrote:
2) contrib vs. pgFoundry
There is unresolved answer if we want to have this in contrib or not.
Good to mention that citext type will be obsoleted with full collation
implementation in a future. I personally prefer to keep it on
pgFoundry
On Jul 7, 2008, at 11:54, Alvaro Herrera wrote:
Then why shouldn't I use strncmp() for all comparisons?
I have no idea :-) -- because it's not locale-aware perhaps.
Could someone who does have an idea answer these questions:
* Does it need to be locale-aware or not?
* Should I use
On Jul 7, 2008, at 11:54, Zdenek Kotala wrote:
Hmm, it is complex area and I'm not sure if anybody on planet know
correct answer :-). I think that best approach is to keep it as is
and when a problem occur then it will be fixed.
Regression tests are really important, though.
b) pgTap is
2008/7/7 Zdenek Kotala [EMAIL PROTECTED]:
David E. Wheeler napsal(a):
On Jul 7, 2008, at 07:41, Zdenek Kotala wrote:
However, It seems to me that code is ok now (exclude citex_eq). I think
there two open problems/questions:
1) regression test -
a) I think that regresion is not correct.
David E. Wheeler napsal(a):
On Jul 7, 2008, at 11:54, Alvaro Herrera wrote:
Then why shouldn't I use strncmp() for all comparisons?
I have no idea :-) -- because it's not locale-aware perhaps.
Could someone who does have an idea answer these questions:
* Does it need to be locale-aware or
On Jul 7, 2008, at 12:13, Zdenek Kotala wrote:
I'm sorry. I meant bttext()
http://doxygen.postgresql.org/varlena_8c-source.html#l01270
bttext should use in citextcmp function. It uses strcol function.
I've no idea what bttext has to do with anything. Sorry if I'm being
slow here.
And
On Jul 7, 2008, at 12:10, Pavel Stehule wrote:
Maybe we can have some locale test outside our regress tests -
I think that would be useful.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Jul 7, 2008, at 12:21, David E. Wheeler wrote:
My question is: why? Shouldn't they all use the same function for
comparison? I'm happy to dupe this implementation for citext, but I
don't understand it. Should not all comparisons be executed
consistently?
Let me try to answer my own
Andrew Hammond [EMAIL PROTECTED] writes:
On Thu, Jul 3, 2008 at 3:47 PM, Tom Lane [EMAIL PROTECTED] wrote:
Have you looked into the machine's kernel log to see if there is any
evidence of low-level distress (hardware or filesystem level)?
Jun 19 03:06:14 db1 kernel: mpt1: attempting to abort
2008/7/7 David E. Wheeler [EMAIL PROTECTED]:
On Jul 7, 2008, at 11:54, Alvaro Herrera wrote:
Then why shouldn't I use strncmp() for all comparisons?
I have no idea :-) -- because it's not locale-aware perhaps.
Could someone who does have an idea answer these questions:
* Does it need to
On Jul 7, 2008, at 12:36, Pavel Stehule wrote:
* Does it need to be locale-aware or not?
yes!
texteq() in varlena.c does not seem to be.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
2008/7/7 David E. Wheeler [EMAIL PROTECTED]:
On Jul 7, 2008, at 12:36, Pavel Stehule wrote:
* Does it need to be locale-aware or not?
yes!
texteq() in varlena.c does not seem to be.
it's case sensitive and it's +/- binary compare
Regards
Pavel Stehule
Best,
David
--
Sent via
David E. Wheeler napsal(a):
On Jul 7, 2008, at 12:21, David E. Wheeler wrote:
My question is: why? Shouldn't they all use the same function for
comparison? I'm happy to dupe this implementation for citext, but I
don't understand it. Should not all comparisons be executed consistently?
Let
David E. Wheeler [EMAIL PROTECTED] writes:
So, the upshot is that the = and operators are not locale-aware,
yes? They just do byte comparisons. Is that really the way it should
be? I mean, could there not be strings that are equivalent but have
different bytes?
We intentionally force
On Jul 7, 2008, at 13:10, Tom Lane wrote:
We intentionally force such strings to be considered non-equal.
See varstr_cmp, and if you like see the archives from back when
that was put in.
The = and operators are in fact consistent with the behavior of
varstr_cmp (and had better be!); they're
On Jul 7, 2008, at 12:46, Zdenek Kotala wrote:
So, the upshot is that the = and operators are not locale-aware,
yes? They just do byte comparisons. Is that really the way it
should be? I mean, could there not be strings that are equivalent
but have different bytes?
Correct. The problem
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 7, 2008, at 12:21, David E. Wheeler wrote:
My question is: why? Shouldn't they all use the same function for
comparison? I'm happy to dupe this implementation for citext, but I don't
understand it. Should not all comparisons be executed
On Jul 7, 2008, at 13:59, Gregory Stark wrote:
Of course the obvious case of two equivalent strings with different
bytes
would be two strings which differ only in case in a collation which
doesn't
distinguish based on case. So you obviously can't take this route
for citext.
Well, to be
On Mon, Jul 7, 2008 at 12:33 PM, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Hammond [EMAIL PROTECTED] writes:
On Thu, Jul 3, 2008 at 3:47 PM, Tom Lane [EMAIL PROTECTED] wrote:
Have you looked into the machine's kernel log to see if there is any
evidence of low-level distress (hardware or
Hi,
We've detected what I think is some sort of index corruption in 8.1.
The server is running 8.1.11, so AFAICT the problem with truncated pages
in vacuum is already patched and accounted for (i.e. we reindexed, and a
bit later the problem presented itself again). There haven't been any
On Mon, 2008-05-05 at 12:01 -0700, David Fetter wrote:
Please find attached the patch, and thanks to Neil Conway and Korry
Douglas for the code, and to Jan Wieck for helping me hammer out the
scheme above. Mistakes are all mine ;)
I see no negative comments to this patch on -hackers.
This
Tom Lane wrote:
target would typically be around 10 or so. It really wasn't designed to
be industrial-strength code. (It was still a big improvement over what
we'd had before :-(.) So I'm not very comfortable with taking it as the
design base for something that does need to be
On Mon, Jul 7, 2008 at 2:08 PM, Andrew Hammond
[EMAIL PROTECTED] wrote:
On Mon, Jul 7, 2008 at 12:33 PM, Tom Lane [EMAIL PROTECTED] wrote:
Also, I suggest filing a bug with your kernel distributor --- ENOSPC was
a totally misleading error code here. Seems like EIO would be more
appropriate.
On Mon, 2008-05-05 at 12:01 -0700, David Fetter wrote:
Please find attached the patch, and thanks to Neil Conway and Korry
Douglas for the code, and to Jan Wieck for helping me hammer out the
scheme above. Mistakes are all mine ;)
I see no negative comments to this patch on -hackers.
Howdy,
I find that, in psql, if I set
\SET QUIET 1
Then, even with \timing toggled on, no timing info is output.
Relatedly, this doesn't seem to turn off quiet mode:
\SET QUIET 0
Are these bugs?
Thanks,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Jul 7, 2008, at 16:07, David E. Wheeler wrote:
Howdy,
I find that, in psql, if I set
\SET QUIET 1
Then, even with \timing toggled on, no timing info is output.
Relatedly, this doesn't seem to turn off quiet mode:
\SET QUIET 0
Are these bugs?
I found that \set QUIET (on|off) works,
On Jul 7, 2008, at 08:01, Andrew Dunstan wrote:
What does still bother me is its performance. I'd like to know if
any measurement has been done of using citext vs. a functional index
on lower(foo).
Okay, here's a start. The attached script inserts random strings of
1-10 space-delimited
And here is the script. D'oh!
Thanks,
David
try.sql
Description: Binary data
On Jul 7, 2008, at 16:24, David E. Wheeler wrote:
On Jul 7, 2008, at 08:01, Andrew Dunstan wrote:
What does still bother me is its performance. I'd like to know if
any measurement has been done of using
On Mon, Jul 07, 2008 at 06:46:29PM -0400, Andrew Dunstan wrote:
On Mon, 2008-05-05 at 12:01 -0700, David Fetter wrote:
Please find attached the patch, and thanks to Neil Conway and
Korry Douglas for the code, and to Jan Wieck for helping me
hammer out the scheme above. Mistakes are
No, *really*
Sheesh, sorry.
David
try.sql
Description: Binary data
On Jul 7, 2008, at 16:26, David E. Wheeler wrote:
And here is the script. D'oh!
Thanks,
David
try.sql
On Jul 7, 2008, at 16:24, David E. Wheeler wrote:
On Jul 7, 2008, at 08:01, Andrew Dunstan wrote:
What does
David E. Wheeler [EMAIL PROTECTED] writes:
Hrm. So in your opinion, strncmp() could be used for all comparisons
by citext, rather than varstr_cmp()?
I thought the charter of this type was to work like lower(textcol).
If that's so, you certainly can't use strncmp, because that would result
in
On Jul 7, 2008, at 16:58, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Hrm. So in your opinion, strncmp() could be used for all comparisons
by citext, rather than varstr_cmp()?
I thought the charter of this type was to work like lower(textcol).
Correct.
If that's so, you
I'm in the process of finishing a native Protocol 3 PostgreSQL driver
written in Pike.
And while trying to make it make intelligent decisions regarding binary
or text encoding of different columns and parameters, I run into the
OIDs of types.
In looking through the specs, I decided that the
On Jul 7, 2008, at 17:14, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Relatedly, this doesn't seem to turn off quiet mode:
\SET QUIET 0
In current releases any value other than off (case insensitive)
is taken as true. IIRC this was improved recently.
Cute. Thanks.
David
David E. Wheeler [EMAIL PROTECTED] writes:
Relatedly, this doesn't seem to turn off quiet mode:
\SET QUIET 0
In current releases any value other than off (case insensitive)
is taken as true. IIRC this was improved recently.
regards, tom lane
--
Sent via
Stephen R. van den Berg wrote:
How large is the probability of these numbers ever changing?
Really small. I'd just hardcode them.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 7, 2008, at 16:58, Tom Lane wrote:
If that's so, you certainly can't use strncmp, because that would
result
in sort orderings totally different from lower()'s result. Even
without
that argument, for most multibyte cases you'd get a
Stephen R. van den Berg [EMAIL PROTECTED] writes:
case 16: // _bool
case 17: // _bytea
case 18: // _char
case 20: // _int8
case 21: // _int2
case 23: // _int4
case 25: // _text
case 142: // _xml
case 829: // _macaddr
case 869: //
On Jul 7, 2008, at 17:18, Tom Lane wrote:
No, but you were: you proposed using strncmp for everything.
Yes, that's right. I was trying to understand why I wouldn't use just
one or the other. And the answer turned out to be, you wouldn't,
except that strncmp() is an desirable optimization
Thanks to help from RhodiumToad on IRC, I got some things improved here:
On Jul 7, 2008, at 16:24, David E. Wheeler wrote:
So for some reason, after adding the indexes, the queries against
the CITEXT column aren't using them. Furthermore, the `lower(text)
LIKE lower(?)` query isn't using
I'd include catalog/pg_type.h and use the #DEFINE for that.
--Imad
On Tue, Jul 8, 2008 at 10:16 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Stephen R. van den Berg wrote:
How large is the probability of these numbers ever changing?
Really small. I'd just hardcode them.
--
Alvaro
Alvaro Herrera [EMAIL PROTECTED] writes:
We've detected what I think is some sort of index corruption in 8.1.
The server is running 8.1.11, so AFAICT the problem with truncated pages
in vacuum is already patched and accounted for (i.e. we reindexed, and a
bit later the problem presented itself
Attached is a new version of a patch to add a CITEXT contrib module.
Changes since v2:
* Optimized citext_eq() and citext_ne() (the = and operators,
respectively) by having them use strncmp() instead of varstr_cmp().
Per discussion.
* Added `RESTRICT` and `JOIN` clauses to the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
We've detected what I think is some sort of index corruption in 8.1.
The server is running 8.1.11, so AFAICT the problem with truncated pages
in vacuum is already patched and accounted for (i.e. we reindexed, and a
bit later the
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Another point to keep in mind, if you are trying to analyze files
belonging to a live database, is that what you can see in the filesystem
may not be the current contents of every page. For typical access
patterns it'd be unsurprising
Tom Lane [EMAIL PROTECTED] wrote:
I don't want the tag there at all, much less converted to a pointer.
What would the semantics be of copying the node, and why?
Please justify why you must have this and can't do what you want some
other way.
In my pg_stat_statements plugin, the tag is
Brendan Jurd wrote:
On Sun, Jul 6, 2008 at 11:44 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Just a personal request, but I would like a permanent URL that points to
the in-progress commit page and is only changed when the commit fest of
_over_.
Well, most of the time there isn't any
Bernd Helmle wrote:
I'm about to add/cleanup some missing descriptions for aggregates and
functions (such as corr(), enum_first()) and discovered that stddev(),
min() and others doesn't have a pg_description entry, too. Is there a
reason for that? Maybe keep off redundant information
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Why is deadlock_timeout set at SIGHUP?
Because it's not clear what the behavior would be like if different
backends had different settings ... except that it'd probably be
surprising.
I have added a code comment explaining this.
--
Ken Camann wrote:
I have developed the first part on my patch to get postgres running
natively on 64-bit Windows. It makes no changes to the postgres code
besides adding some win64 specific header files to the port directory.
The rest of it is modifications to the Perl scripts in
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Another point to keep in mind, if you are trying to analyze files
belonging to a live database, is that what you can see in the filesystem
may not be the current contents of every page. For typical access
patterns
These are my review comments on Mark Woodward's SSL configure patch:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
(The patch is whitespace-damaged and the one fe-secure.c hunk doesn't
apply cleanly to the latest source, but I'm ignoring both problems for
the moment.)
1. To begin
At 2008-07-08 08:27:29 +0530, [EMAIL PROTECTED] wrote:
(The patch is whitespace-damaged and the one fe-secure.c hunk doesn't
apply cleanly to the latest source, but I'm ignoring both problems for
the moment.)
It wasn't hard to fix those, so I've attached an updated patch here.
Finally, I
At 2008-07-03 16:36:02 +0200, [EMAIL PROTECTED] wrote:
Here's a patch for this.
I reviewed the patch, it basically looks fine. A few quibbles with the
provided documentation:
+ Reports the number of pages which can be stored within a file
segment.
+ The total physical
1 - 100 of 103 matches
Mail list logo
