On Mon, Jul 07, 2008 at 12:06:08PM -0700, David E. Wheeler wrote:
> I guess that'd be the reason to keep it on pgFoundry, but I have two
> comments:
>
> * 2-3 years is a *long* time in Internet time.
There have been patches over the years, but they tend not to get looked
at. Recently someone pu
On Thu, 2008-07-03 at 16:36 +0200, Bernd Helmle wrote:
> --On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian <[EMAIL PROTECTED]>
> wrote:
>
> >>
> >> I'd like to implement them if we agree on them
> >
> > Bernd, have you made any progress on this?
>
> Here's a patch for this. I'll add it to
On Tue, Jul 08, 2008 at 07:28:36AM +0200, Hans-Juergen Schoenig wrote:
> good morning everybody,
>
> i know that this is really a hot potato on the mailing list but i
> think it is useful to discuss this issue. in the past few months
> we have been working with a customer to improve evgen's CONN
On Mon, 2008-07-07 at 16:26 -0700, David Fetter wrote:
> On Mon, Jul 07, 2008 at 06:46:29PM -0400, Andrew Dunstan wrote:
> > >
> > For the record, I agree with Jan's suggestion of passing a pointer
> > to the parse tree, and offline gave David a suggestion verbally as
> > to how this could be hand
good morning everybody,
i know that this is really a hot potato on the mailing list but i think
it is useful to discuss this issue.
in the past few months we have been working with a customer to improve
evgen's CONNECT BY patch.
as we have a nice and promising WITH RECURSIVE patch the original
Thanks for your reviewing.
Peter Eisentraut wrote:
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 l
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
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,
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
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 ac
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 src/tool
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
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
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 th
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
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 u
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 lat
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 comparis
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 i
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.
>
>
> --
> Al
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 *it
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 f
"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
> ca
"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
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:
> 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 pgs
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.
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 follow
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
"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 resul
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
On Jul 7, 2008, at 16:24, David E. Wheeler wrote:
On Jul 7, 2008, at 08:01, Andrew Dunstan wrote:
What does still bot
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. M
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 cite
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 wo
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, but
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 ch
>
> 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 -hac
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
>> appr
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 industrial-stren
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.
Thi
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
relevant
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 (
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 fa
"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 ex
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
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
"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 intentionall
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 me
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
>
-
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:
http://www.postgresql.org/mailpr
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:
>
> * Doe
"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: attemp
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 que
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:
http://www.postgresql.org/mai
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 ci
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
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
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 so
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 strncmp()
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 bec
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
>> wonderin
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 Marti
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 chara
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
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 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
>>
"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
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
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 t
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 mov
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 looking
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-she
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 go
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 beg
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 re
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 e
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
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 relat
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 t
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 ot
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
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
=?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 a
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 throug
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, ag
--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
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 m
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
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
Postgre
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 do
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
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 worka
--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
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 uint
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 lik
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-#
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 ber
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 storag
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
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 [-t ].
I found it a common use case to restore this dump into a different schema
by simply changing the s
1 - 100 of 106 matches
Mail list logo
