> > I'm reviewing the strxfrm patch, and while comparing that code to the
> > code in varstr_cmp (which uses the same UTF8/UTF16 workaround but for
> > strcoll instead), and I noticed that in varstr_cmp we have an
> > optimization to use a stack based buffer instead of palloc if the string
> > is s
Gregory Stark <[EMAIL PROTECTED]> writes:
> Incidentally, Tom, were you consulting the dead-tree edition of the OED?
I plead guilty to having blown some dust off it before opening it ...
but when looking for an authoritative reference, I like things that
have got heft to them ...
Gregory Stark <[EMAIL PROTECTED]> writes:
> You keep saying that but I think it's wrong. There are trivial patches that
> were submitted last year that are still sitting in the queue.
Um ... which ones exactly? I don't see *anything* in the current queue
that is utterly without issues, other than
On Wed, 2007-05-02 at 23:59 +0100, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > On Wed, 2007-05-02 at 20:58 +0100, Heikki Linnakangas wrote:
> >> Jeff Davis wrote:
> >>> What should be the maximum size of this hash table?
> >> Good question. And also, how do you remove entries from it?
> >>
>
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> What we could have is the semantics of "Return a buffer, with either
> correct contents or completely zeroed out". It would act just like
> ReadBuffer if the buffer was already in memory, and zero out the page
> otherwise. That's a bit strange sem
Jeff Davis wrote:
On Wed, 2007-05-02 at 20:58 +0100, Heikki Linnakangas wrote:
Jeff Davis wrote:
What should be the maximum size of this hash table?
Good question. And also, how do you remove entries from it?
I guess the size should somehow be related to number of backends. Each
backend will
On Wed, 2007-05-02 at 20:58 +0100, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > What should be the maximum size of this hash table?
>
> Good question. And also, how do you remove entries from it?
>
> I guess the size should somehow be related to number of backends. Each
> backend will real
"dx k9" <[EMAIL PROTECTED]> writes:
> [ stuck reindex ]
> It turns out it was a temporary database and temporary table, that just
> wasn't there maybe it thought it was there from some type of snapshot then
> the next minute it was gone.
Hmm, there is not any filter in ReindexDatabase() to exclu
"Akmal Akmalhojaev" <[EMAIL PROTECTED]> writes:
> I wanted to create a new system catalog in Postgres. So I changed the source
> code. Everything seems to be OK. I compiled it, but now after initdb I
> receive:
> creating template1 database in /usr/home/postgres/post1/base/1 ... FATAL:
> could
> n
On Tue, 2007-05-01 at 22:44 -0400, Tom Lane wrote:
Nice summary Tom.
> * Re: [PATCHES] [Fwd: Deferred Transactions, Transaction Guarantee
> and COMMITwithout waiting] /Simon Riggs/
>
> Simon is on the hook to submit an updated patch. I hope this one
> makes it in, as it looks like a real
Jeff Davis wrote:
On Wed, 2007-05-02 at 20:02 +0100, Heikki Linnakangas wrote:
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Let's use a normal hash table instead, and use a lock to protect it. If we only
update it every 10 pages or so, the overhead should be negligibl
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I'm reviewing the strxfrm patch, and while comparing that code to the
> code in varstr_cmp (which uses the same UTF8/UTF16 workaround but for
> strcoll instead), and I noticed that in varstr_cmp we have an
> optimization to use a stack based buffer inst
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Please see the attached updated patch, based on Tom's comments.
> Attempt to reload index information for system indexes such as
> pg_class_oid_index can cause infinite recursion. But I realized that
> we don't need to reload system index information
On Wed, 2007-05-02 at 20:02 +0100, Heikki Linnakangas wrote:
> Gregory Stark wrote:
> > "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> >
> >> Let's use a normal hash table instead, and use a lock to protect it. If we
> >> only
> >> update it every 10 pages or so, the overhead should be neglig
Chris Browne wrote:
> [EMAIL PROTECTED] (Andrew Dunstan) writes:
>> Tom Lane wrote:
>>> So in a roundabout way we come back
>>> to the idea that we need a bug tracker (NOT a patch tracker), plus
>>> people putting in the effort to make sure it stays a valid source
>>> of up-to-date info. Without t
Joshua D. Drake wrote:
Well according to himself the last time this came up:
http://archives.postgresql.org/pgsql-hackers/2006-08/msg01253.php
No, he isn't.
The last paragraph of
http://archives.postgresql.org/pgsql-hackers/2007-04/msg01258.php is
somewhat more positive regarding a patch t
Marc Munro <[EMAIL PROTECTED]> writes:
> On Wed, 2007-02-05 at 08:27 -0400, Andrew Dunstan wrote:
>> The question was rhetorical ... there is no list of "certified sane but
>> unapplied" patches. You are proceeding on the basis of a faulty
>> understanding of how our processes work.
> Why do we ne
I'm reviewing the strxfrm patch, and while comparing that code to the
code in varstr_cmp (which uses the same UTF8/UTF16 workaround but for
strcoll instead), and I noticed that in varstr_cmp we have an
optimization to use a stack based buffer instead of palloc if the string
is short enough. Is conv
Marc Munro wrote:
> On Wed, 2007-02-05 at 08:27 -0400, Andrew Dunstan wrote:
>>
>> Naz Gassiep wrote:
>> > Andrew Dunstan wrote:
>> >
>> >> Naz Gassiep wrote:
>> >>
>> >>> I believe the suggestion was to have an automated process that only
>> ran
>> >>> on known, sane patches.
>> >>>
>> >> How do w
Jeff Davis wrote:
On Wed, 2007-05-02 at 14:26 +0100, Heikki Linnakangas wrote:
Let's use a normal hash table instead, and use a lock to protect it. If
we only update it every 10 pages or so, the overhead should be
negligible. To further reduce contention, we could modify ReadBuffer to
let the
Here's a shorter version:
On the date variant, I wasn't sure how to handle intervals with parts
smaller than days:
floor, ceiling, round or error out
To get round, the last parameters of generate_series would be
extract('epoch' FROM '1 day'::interval)::bigint * round(extract('epoch' FROM
$3) /
Here's a shorter version:
On the date variant, I wasn't sure how to handle intervals with parts
smaller than days:
floor, ceiling, round or error out
To get round, the last parameters of generate_series would be
extract('epoch' FROM '1 day'::interval)::bigint * round(extract('epoch' FROM
$3) /
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Let's use a normal hash table instead, and use a lock to protect it. If we only
update it every 10 pages or so, the overhead should be negligible. To further
reduce contention, we could modify ReadBuffer to let the caller kno
ITAGAKI Takahiro wrote:
> I wrote:
> > I found that autovacuum launcher does not launch any workers in HEAD.
>
> The attached autovacuum-fix.patch could fix the problem. I changed
> to use 'greater or equal' instead of 'greater' at the decision of
> next autovacuum target.
I have committed a patc
Josh Berkus wrote:
Bruce, all,
No, my point is that 100% information is already available by looking at
email archives. What we need is a short description of where we are on
each patch --- that is a manual process, not something that can be
automated.
Tom has posted it --- tell me how we wil
Bruce, all,
> No, my point is that 100% information is already available by looking at
> email archives. What we need is a short description of where we are on
> each patch --- that is a manual process, not something that can be
> automated.
>
> Tom has posted it --- tell me how we will get such
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Let's use a normal hash table instead, and use a lock to protect it. If we
> only
> update it every 10 pages or so, the overhead should be negligible. To further
> reduce contention, we could modify ReadBuffer to let the caller know if the
> read
On Wed, 2007-05-02 at 14:26 +0100, Heikki Linnakangas wrote:
> Hi,
>
> I'm starting to review the "synchronized scans" and "scan-resistant
> buffer cache" patches. The patches have complex interactions so I'm
> taking a holistic approach.
>
> There's four outstanding issues with the sync scans
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Nailed it -- this is the actual bug that causes the abort. But I am
>> surprised that it doesn't print the error message in Stefan machine's;
>
> Hm, maybe we need an fflush(stderr) in ExceptionalCondition?
st
On Wed, May 02, 2007 at 06:44:12AM -0400, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > As an example, how is patch information going to help us review HOT or
> > > group-item-index? There is frankly more information about these in the
> > > archives than someone could reasonable read. What
I noticed that conversion_procs is sadly single-tasked to build. I am
wondering if it would be acceptable to rework the Makefile.shlib to have
an option to allow building multiple libs, by creating a rule to collect
libraries to build, and have each conversion_proc Makefile add a target
to that.
Hi,
The recently discovered autovacuum bug made me notice something that is
possibly critical. The current autovacuum code makes an effort not to
leave workers in a "starting" state for too long, lest there be failure
to timely tend all databases needing vacuum.
This is how the launching of work
On Wed, 2007-02-05 at 08:27 -0400, Andrew Dunstan wrote:
>
> Naz Gassiep wrote:
> > Andrew Dunstan wrote:
> >
> >> Naz Gassiep wrote:
> >>
> >>> I believe the suggestion was to have an automated process that only ran
> >>> on known, sane patches.
> >>>
> >> How do we know in advance
Hello.
I wanted to create a new system catalog in Postgres. So I changed the source
code. Everything seems to be OK. I compiled it, but now after initdb I
receive:
$ initdb -D /usr/home/postgres/post1
The files belonging to this database system will be owned by user
"postgres".
This user must al
On May 2, 2007, at 3:11 AM, Magnus Hagander wrote:
As to the question of GSSAPI vs SSL, I would never argue we don't
want both.
Part of what made the GSSAPI encryption mods difficult was my intent
to insert them "above" the SSL encryption/buffering layer. That way
you could double-encrypt the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Nailed it -- this is the actual bug that causes the abort. But I am
> surprised that it doesn't print the error message in Stefan machine's;
Hm, maybe we need an fflush(stderr) in ExceptionalCondition?
regards, tom lane
--
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Stefan Kaltenbrunner wrote:
> >
> > > well - i now have a core file but it does not seem to be much worth
> > > except to prove that autovacuum seems to be the culprit:
> > >
> > > Core was generated by `postgres: autovacuum worker process
> > >
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
>
> > well - i now have a core file but it does not seem to be much worth
> > except to prove that autovacuum seems to be the culprit:
> >
> > Core was generated by `postgres: autovacuum worker process
> > '.
> > Pro
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I'm wondering if there is some code path that invokes a PG_TRY deep in
>>> the bowels of the system.
> Huh, hang on ... there is one caller, which is to set client_encoding
> (call_string_assign_hook uses a PG_TRY block), but it is
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > I agree that that would be a bug and we should fix it, but I don't think
> > > it explains the problem we're seeing because there is no PG_TRY block
> > > in the autovac startup code that I can see :-(
> >
http://www.sigaev.ru/misc/tsearch_core-0.46.gz
Patch is synced with current CVS HEAD and synced with bugfixes in
contrib/tsearch2
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
Tom Lane wrote:
* [pgsql-patches] Ctid chain following enhancement
/Pavan Deolasee/
I'm not very excited about this --- it seems to me to complicate the code
in some places that are not in fact performance-critical. While it
doesn't seem likely to break things, I'm not in favor of reduci
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I agree that that would be a bug and we should fix it, but I don't think
> > it explains the problem we're seeing because there is no PG_TRY block
> > in the autovac startup code that I can see :-(
>
> I'm wondering if there is some
[EMAIL PROTECTED] (Andrew Dunstan) writes:
> Tom Lane wrote:
>> So in a roundabout way we come back
>> to the idea that we need a bug tracker (NOT a patch tracker), plus
>> people putting in the effort to make sure it stays a valid source
>> of up-to-date info. Without the latter it won't really b
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I agree that that would be a bug and we should fix it, but I don't think
> it explains the problem we're seeing because there is no PG_TRY block
> in the autovac startup code that I can see :-(
I'm wondering if there is some code path that invokes a PG_
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> >So in a roundabout way we come back
> >to the idea that we need a bug tracker (NOT a patch tracker), plus
> >people putting in the effort to make sure it stays a valid source
> >of up-to-date info. Without the latter it won't really be useful.
>
>
Hi,
I'm starting to review the "synchronized scans" and "scan-resistant
buffer cache" patches. The patches have complex interactions so I'm
taking a holistic approach.
There's four outstanding issues with the sync scans in particular:
1. The simplistic hash approach. While it's nice to not h
Tom Lane wrote:
> I wrote:
> > Hmm ... I was about to say that the postmaster never sets
> > PG_exception_stack, but maybe an error out of a PG_TRY/PG_RE_THROW
> > could do it? Does the postmaster ever execute PG_TRY?
>
> Doh, I bet that's it, and it's not the postmaster that's at issue
> but PG_
Tom Lane wrote:
So in a roundabout way we come back
to the idea that we need a bug tracker (NOT a patch tracker), plus
people putting in the effort to make sure it stays a valid source
of up-to-date info. Without the latter it won't really be useful.
Hallelujah Brother!
BTW, a bug trac
Naz Gassiep wrote:
Andrew Dunstan wrote:
Naz Gassiep wrote:
I believe the suggestion was to have an automated process that only ran
on known, sane patches.
How do we know in advance of reviewing them that they are sane?
Same way as happens now.
The question was rhet
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
FYI, Tom, Heikki, I need one of you to post the list of patches and
where we think we are on each one, even if the list is imperfect.
This message is an attempt to sort out which patch queue entries have
no hope of getting int
Another complexity is testing cases where the table fits in shared
memory/RAM, and those that don't, and testing cases where heap fits in
RAM only because we pushed things to TOAST, and cases where we have to
do lots of TOAST access that doesn't fit in RAM. I wonder if it is even
worth testing it
Gregory Stark wrote:
>
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > We seem to handle trivial patches just fine.
>
> You keep saying that but I think it's wrong. There are trivial patches that
> were submitted last year that are still sitting in the queue.
You seem to be looking at som
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Hmm ... the Oxford English Dictionary defines "forensic" as "pertaining
> to, connected with, or used in courts of law". There are also some
> senses related to argumentation, but nothing specifically about evidence
> analysis, whether after-the-fact or n
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> We seem to handle trivial patches just fine.
You keep saying that but I think it's wrong. There are trivial patches that
were submitted last year that are still sitting in the queue.
In fact I claim we handle complex patches better than trivial on
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Then, figure out where the gains on the non-TEXT field seem to diminish
> in usefulness. Basically, with a lower TOAST value, we are going to
> spend more time accessing the TEXT field, but the speedup for the
> non-TEXT field should be large enough
Heikki Linnakangas wrote:
I'm going to go with pgdiagnostics. We could short it to just "pgdiag",
but that feels too short :). We could make it "pgdiagfuncs", but that's
not much shorter than pgdiagnostics.
pgdiagfn? It is only 8 chars length ;).
Zdenek
---(
Pavan Deolasee wrote:
> On 5/2/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > I'm going to go with pgdiagnostics. We could short it to just "pgdiag",
> > but that feels too short :). We could make it "pgdiagfuncs", but that's
> > not much shorter than pgdiagnostics.
>
>
>
> Ju
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> FYI, Tom, Heikki, I need one of you to post the list of patches and
> >> where we think we are on each one, even if the list is imperfect.
> >
> > This message is an attempt to sort o
> Expecting a Quick response.
Don't hold your breath.
Please post questions like this to the JDBC and/or the 'general' mailing
list.
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.
Josh Berkus wrote:
> Bruce,
>
> > As an example, how is patch information going to help us review HOT or
> > group-item-index? There is frankly more information about these in the
> > archives than someone could reasonable read. What someone needs is a
> > summary of where we are now on the patc
Magnus Hagander wrote:
> > As an example, how is patch information going to help us review HOT or
> > group-item-index? There is frankly more information about these in the
> > archives than someone could reasonable read. What someone needs is a
> > summary of where we are now on the patches, and
On Tue, May 01, 2007 at 10:44:38PM -0400, Tom Lane wrote:
> * [PATCHES] Preliminary GSSAPI Patches /Henry B. Hotz/
>
> Magnus is reviewing this one.
Check.
> * [PATCHES] Clear up strxfrm() in UTF-8 with locale on Windows
>/ITAGAKI Takahiro/
>
> Someone else needs to look at this; I ca
On Tue, May 01, 2007 at 04:26:13PM -0700, Henry B. Hotz wrote:
>
> On May 1, 2007, at 3:11 PM, Magnus Hagander wrote:
>
> Also, last I checked OpenSSL didn't ship with Windows and Kerberos
> encryption did.
> >>>How long ago did you check? I've been using OpenSSL on windows
> >>>for man
> > Any suggestions? pgdiagnostics?
>
> Yes, I like "diagnostics", or "internals". I just think
> forensics isn't going to be understood by the average native
> English speaker, let alone non-English speakers.
I think forensics is ok. The world is currently beeing swamped with
related tv show
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> FYI, Tom, Heikki, I need one of you to post the list of patches and
>> where we think we are on each one, even if the list is imperfect.
>
> This message is an attempt to sort out which patch queue entries have
>
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 5/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>>
>> This needs a *lot* of review. Can we break it down into more manageable
>> chunks?
>
> Sure, we can do that. I actually did that when I posted the
> incremental versions of the HOT-patch, each ve
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
Actually, that can happen with the current system. The real blocker there is
that some people, particularly Tom, work so fast that there's no chance for a
new reviewer to tackle the easy stuff. Maybe the real solution is to
encourage some
* [PATCHES] Updateable cursors patch /FAST PostgreSQL/
This is incomplete, and I fear at this point has to be held over to 8.4.
It is true that my original patch post said that I need to modify the
patch to work with tidscan. Since then I have realized that this
modification is not needed a
friend 4ever wrote:
Hi,
I am getting the parse error while i try to execute a simple sql query in postgres.
java.sql.SQLException: ERROR: parser: parse error at or near "and" at character 58
The Query has been changed and it is very much like the below one
Oh, and the quickest way t
friend 4ever wrote:
Hi,
I am getting the parse error while i try to execute a simple sql query in postgres.
This isn't a question for the hackers list.
Try the general, or jdbc lists.
--
Richard Huxton
Archonet Ltd
---(end of broadcast)-
Magnus Hagander wrote:
Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.
How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.
I didn't say *
Hi,
I am getting the parse error while i try to execute a simple sql query in
postgres.
java.sql.SQLException: ERROR: parser: parse error at or near "and" at
character 58
The Query has been changed and it is very much like the below one
select * from emp where empName like 'X'
On Tue, May 01, 2007 at 07:09:24PM -0400, Bruce Momjian wrote:
> > The current patch-queue process is failing to scale with the project: every
> > release it gets to be more work for you & Tom to integrate the patches. We
> > need to think of new approaches to make the review process scale. As
Hello Tom,
All what you wrote is true. plpgpsm copies-and-pastes about 30% of code and
It is terrible for long run. But when I can change it? Writing differnt
runtime is nonsense, better way is refactoring plpgsql and then sharing code
with its. It's not propable in 8.4 .. there will by lot o
75 matches
Mail list logo
