On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote:
* [PATCHES] HOT Patch - Ready for review /Pavan Deolasee/
This needs a *lot* of review. Can we break it down into more manageable
chunks? I'm not sure that anyone's got a full grasp of the implications
of this patch, and that's a scary thought.
On Tue, 1 May 2007, Tom Lane wrote:
* [HACKERS] tsearch_core patch for inclusion
/Teodor Sigaev/
Have we resolved whether the API and the dump/restore strategy are
acceptable? The code needs review too, but not till we've settled
on the basic question whether we like the feature set.
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.
Just to add more confusion :-), how about pginspect ?
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
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 a
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'
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
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
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 to
* [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
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
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 version
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
no hope of
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 shows :-)
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 many
years. Actually,
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 can't
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 lots
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 patches, and
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?
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 out which patch
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.
Just to add more
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
---(end
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 win
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 ones.
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 not. So
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 something
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
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 into
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
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
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_TRY
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 have
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.
Hallelujah
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_TRY
[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 be
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 code path
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
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/
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 :-(
I'm
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 called
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
'.
Program
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 [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
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
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
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 of reviewing them 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
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.
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 someone
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?
stderr is
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 in
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
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 a
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
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 patch
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 know
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)
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
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 we know in advance of reviewing them
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
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 need to know
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
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 the latter it
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 negligible. To
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 because
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 instead
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 negligible.
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 really
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
not open
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 exclude temp
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
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
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 semantics
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?
I guess the
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
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 ...
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
78 matches
Mail list logo
