My feeling is we should have more regular sync points where the
patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that
reviewing/committing other people's patches is not fun, it's
just work :-(. So it's no surprise that it tends to
On Thu, 2007-03-29 at 01:34 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing other
Pavan Deolasee wrote:
In this specific context, this particular case is easy to handle because
we are only concerned about the serializable transactions started before
CREATE INDEX commits. If PREPARE can see the new index, it
implies that the CI transaction is committed. So the transaction
On 3/29/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Yes, but the non-index plan PREPARE generated will be used until the end
of the session, nut only until the end of the transaction.
Frankly I don't know this works, but are you sure that the plan will
be used until the end of the session
Hi, Here're some feedback to the comment:
Simon Riggs wrote:
On Wed, 2007-03-28 at 10:54 +0900, Koichi Suzuki wrote:
As written below, full page write can be
categolized as follows:
1) Needed for crash recovery: first page update after each checkpoint.
This has to be kept in WAL.
2) Needed
On Thu, 2007-03-29 at 17:50 +0900, Koichi Suzuki wrote:
Not only full-page-writes are written as WAL record. In my proposal,
both full-page-writes and logical log are written in a WAL record, which
will make WAL size slightly bigger (five percent or so). If
full_page_compress = off,
I've been working on the patch to enhance our group commit behavior. The
patch is a dirty hack at the moment, but I'm settled on the algorithm
I'm going to use and I know the issues involved.
Here's the patch as it is if you want to try it out:
I wrote:
What are the chances of getting this in 8.3, assuming that I rewrite and
submit a patch within the next week or two?
I also intend to do performance testing with different workloads to
ensure the patch doesn't introduce a performance regression under some
conditions.
--
Heikki
On Wed, 2007-03-28 at 14:08 -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I also think that we ought to add TOAST_MAX_CHUNK_SIZE to the set of
compiled-in parameters that are recorded in pg_control and checked for
compatibility at
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing other
people's patches is
Pavan Deolasee wrote:
On 3/29/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Yes, but the non-index plan PREPARE generated will be used until the end
of the session, nut only until the end of the transaction.
Frankly I don't know this works, but are you sure that the plan will
be used until
On Wed, Mar 28, 2007 at 04:56:28PM +0200, Magnus Hagander wrote:
From what I can see, the ecpg thread tests (src/interfaces/ecpg/threads)
don't ever run. They rely on ENABLE_THREAD_SAFETY to be set, but even when
I build with --enable-thread-safety, it's not set. This is because ecpg
does not
On Wed, Mar 28, 2007 at 07:30:21PM +0200, Magnus Hagander wrote:
If you want to pick one early, please look at the one about the thread
regression tests not appearing to run at all. I'd like to have that
confirmed before I try to dig into how to fix it - in case it's not
actually broken, and
Gregory Stark wrote:
Obviously a big part of that is that we just don't have enough committers. I'm
hopeful that in time that situation will improve but in the meantime we do
have a problem and the burden falls unfairly on a few.
Is there anything others can do to help? If non-committers like
Andrew Dunstan [EMAIL PROTECTED] writes:
There is plenty of scope for people to review patches if they aren't
committers. In fact, it is highly encouraged. Please review anything on
the patch list you feel able to.
Sure. Even if you miss things, every problem you do spot is one less...
and
On Thu, Mar 29, 2007 at 02:04:48PM +0200, Michael Meskes wrote:
On Wed, Mar 28, 2007 at 07:30:21PM +0200, Magnus Hagander wrote:
If you want to pick one early, please look at the one about the thread
regression tests not appearing to run at all. I'd like to have that
confirmed before I try
Florian G. Pflug [EMAIL PROTECTED] writes:
Pavan Deolasee wrote:
Frankly I don't know this works, but are you sure that the plan will
be used until the end of the session ? Even if thats the case, it can
happen even today if we create a new index, but the existing sessions
will use the stale
Simon Riggs [EMAIL PROTECTED] writes:
Well it certainly seems worth separating them. It does seem possible
that recursive toasting effected some of the earlier results we looked
at.
Would you like me to do this, or will you?
I'm willing to do the code changes to separate TOAST_THRESHOLD from
code: random backend code should not, not, not be using fopen()
directly. If you lose control to an elog, which is certainly possible
seeing that this loop calls into the utils/mb subsystem, you'll leak
the file descriptor. Use AllocateFile/FreeFile instead of fopen/fclose.
Will soon in
http://www.sigaev.ru/misc/tsearch_core-0.43.gz
Changes:
1 Ispell dictionary now supports hunspell dictionary's format which is used by
OpenOffice = 2.0.2
http://wiki.services.openoffice.org/wiki/Dictionaries
Changes in format is addressed, basically, to better support of compound words
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've been working on the patch to enhance our group commit behavior. The
patch is a dirty hack at the moment, but I'm settled on the algorithm
I'm going to use and I know the issues involved.
...
The timeout is currently hard-coded at 1 ms.
This
On 3/29/07, Tom Lane [EMAIL PROTECTED] wrote:
It will replan at the first use of the plan after seeing the relcache
inval sent by commit of the index-creating transaction. If you have
two separate transactions to create an index and then mark it valid
later, everything's fine because there
Tom Lane [EMAIL PROTECTED] writes:
However, if you design something where an index becomes usable due
to the passage of time rather than an explicit mark-valid step,
there's gonna be a problem. I'd suggest trying to stick to the
way CREATE INDEX CONCURRENTLY does it...
I'm a bit skeptical
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've been working on the patch to enhance our group commit behavior. The
patch is a dirty hack at the moment, but I'm settled on the algorithm
I'm going to use and I know the issues involved.
...
The timeout is currently hard-coded
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is where my bogometer triggered. There's way too many platforms
where 1 msec timeout is a sheer fantasy. If you cannot make it perform
well with a 10-msec timeout then I don't think it's going to be at all
portable.
The 1
Sorry to start another thread while we are still discussing CREATE
INDEX design, but I need help/suggestions to finish the patch on
time for 8.3
We earlier thought that CREATE INDEX CONCURRENTLY (CIC)
would be simpler to do because of the existing waits in CIC.
But one major problem with CIC is
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
It favours people who are short-sighted and don't see what possible
improvements their code has. No code in an ongoing project like this is
ever
completed anyways.
It favors those who do not wait until the last minute,
As was pointed out awhile ago
http://archives.postgresql.org/pgsql-general/2007-02/msg00673.php
it's insecure to run a SECURITY DEFINER function with a search_path
setting that's under the control of someone who wishes to subvert
the function. Even for non-security-definer functions, it seems
We don't want open-ended a few days before feature feeze. We want them
to be as done, at some complete stopping point, and submitted.
OK, but we don't want something that is ready to be committed, we need
it complete.
So how many more releases before you think Postgres is complete?
I am
On 3/29/07, Gregory Stark [EMAIL PROTECTED] wrote:
Besides, it seems if people are
happy to have indexes take a long time to build they could just do a
concurrent build.
I think we discussed this earlier. One of the down-side of CIC is that
it needs two complete heap scans. Apart from that
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing other
people's patches is not fun, it's just
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing
Bruce Momjian wrote:
OK, but we don't want something that is ready to be committed, we need
it complete.
So how many more releases before you think Postgres is complete?
I am getting tired of your semantic games, here, Greg. I have no idea
what you are trying to accomplish, but I have
Pavan Deolasee wrote:
Earlier we were talking about not inserting any HOT tuples until the index
became valid. The goal of having an xid on the index was so we would know
when
we could start doing HOT updates again. That seems like a much lesser cost
than not being able to use the index
On 3/29/07, Tom Lane [EMAIL PROTECTED] wrote:
As was pointed out awhile ago
http://archives.postgresql.org/pgsql-general/2007-02/msg00673.php
it's insecure to run a SECURITY DEFINER function with a search_path
setting that's under the control of someone who wishes to subvert
the function. Even
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
fwiw, I think this is a great solution...because the default behavior
is preserved you get through without any extra guc settings (although
you may want to add one anyways).
I agree that the proposed solution looks good.
maybe security definer
Bruce Momjian [EMAIL PROTECTED] writes:
The basic problem is we have a lot of complex patches coming in, and
many from people who do not have years of experience with submitting
patches to PostgreSQL. A complex patch from a novice user takes a lot
of time to review, and frankly, we don't have
On 3/29/07, Stephen Frost [EMAIL PROTECTED] wrote:
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
fwiw, I think this is a great solution...because the default behavior
is preserved you get through without any extra guc settings (although
you may want to add one anyways).
I agree that the
Stephen Frost [EMAIL PROTECTED] writes:
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
maybe security definer functions should raise a warning for implicit
PATH NONE, and possibly even deprecate that behavior and force people
to type it out in future (8.4+) releases.
While I agree that raising
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
+++
We'd love this feature as it would really help us write better test cases !
Regards
Sailesh
--
Sailesh Krishnamurthy
Amalgamated Insight
[W] (650) 242-3503
[C] (650) 804-6585
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gregory Stark
Sent:
Hello Everyone,
I very much understand why SJIS is not a server encoding. It contains
ASCII second bytes (including \ and ' both of which can be really
nasty inside a normal sql) and further, half-width katakana is
represented as one byte-characters, incidentally two of which coincide
with a
Simon,
OK, different question:
Why would anyone ever set full_page_compress = off?
The only reason I can see is if compression costs us CPU but gains RAM
I/O. I can think of a lot of applications ... benchmarks included ...
which are CPU-bound but not RAM or I/O bound. For those
Pavan Deolasee [EMAIL PROTECTED] writes:
What I am proposing is to keep index unusable for existing transactions.
The index is available for all new transactions even if there are unfinished
existing transactions.
Ah thanks, that makes a lot more sense. Sorry for the false alarm.
--
On Wed, Mar 28, 2007 at 10:44:00AM +0900, Dezso Zoltan wrote:
My question is, however: what would be the best practice if it was
imperative to use SJIS encoding for texts and no built-in conversions
are useful? To elaborate, I need to support japanese emoji characters,
which are special
Kris Jurka [EMAIL PROTECTED] writes:
Running the JDBC driver's regression test suite for the first time in a
while I got a lot of failures that I would have to guess are related to
plan invalidation work. Attached is a self contained test case and the
JDBC driver's log of what protocol
On Thu, 2007-03-29 at 22:08 +0530, Pavan Deolasee wrote:
On 3/29/07, Tom Lane [EMAIL PROTECTED] wrote:
It will replan at the first use of the plan after seeing the
relcache
inval sent by commit of the index-creating transaction. If
you have
On Thu, 2007-03-29 at 13:55 -0400, Bruce Momjian wrote:
Pavan Deolasee wrote:
Earlier we were talking about not inserting any HOT tuples until the index
became valid. The goal of having an xid on the index was so we would know
when
we could start doing HOT updates again. That seems
Hello,
I ran into an interesting problem with a customer today. They are
running Jabber XCP (not the one we use). Unfortunately, the product has
a bug that causes it to leave connections persistent in a transaction
state. This is what it does:
BEGIN; SELECT 1;
Basically it is verifying
On Thu, 2007-03-29 at 12:05 -0400, Tom Lane wrote:
I think the WAL-reduction proposal needs more time and thought than is
feasible before 8.3.
Agreed.
We really need to focus on the major features.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
On Thu, 29 Mar 2007, Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
Running the JDBC driver's regression test suite for the first time in a
while I got a lot of failures that I would have to guess are related to
plan invalidation work. Attached is a self contained test case and the
Hi, i need you help Postgres gurus...
I have been modified postgres for a while... and i need to test the
performance (for now, only time) of my modifications against the original
postgres
My first approach was to use the function clock() of the time.h C library,
in the postgres.c file
Simon Riggs [EMAIL PROTECTED] writes:
ISTM that the run-another-transaction-afterwards idea is the only one
that does everything I think we need. I really do wish we could put in a
wait, like CIC, but I just think it will break existing programs.
Actually, there's a showstopper objection to
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
ISTM that the run-another-transaction-afterwards idea is the only one
that does everything I think we need. I really do wish we could put in a
wait, like CIC, but I just think it will break existing programs.
Actually, there's a
Here is a web site showing all the uncompleted patches for 8.2 that I am
worried about:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
I can update the list as I get feedback.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB
Bruce Momjian wrote:
Here is a web site showing all the uncompleted patches for 8.2 that I am
Sorry, mean 8.3.
---
worried about:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
I can update the list as
On Thu, 2007-03-29 at 11:45 -0700, Josh Berkus wrote:
OK, different question:
Why would anyone ever set full_page_compress = off?
The only reason I can see is if compression costs us CPU but gains RAM
I/O. I can think of a lot of applications ... benchmarks included ...
which are
[ Sorry, reposted with correct subject line.]
Here is a web site showing all the uncompleted patches for 8.3 that I
am worried about:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB
On Thu, 2007-03-29 at 17:27 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
ISTM that the run-another-transaction-afterwards idea is the only one
that does everything I think we need. I really do wish we could put in a
wait, like CIC, but I just think it will break existing
Hi...
I was trying to execute \timing in a psql console but the command that i
always get is \t Is something that im missing??? or is an Error???
...My version of postgres is 8.1.4
Bye.
Simon Riggs wrote:
On Thu, 2007-03-29 at 17:27 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
ISTM that the run-another-transaction-afterwards idea is the only one
that does everything I think we need. I really do wish we could put in a
wait, like CIC, but I just think it will
Josh;
I'd like to explain what the term compression in my proposal means
again and would like to show the resource consumption comparision with
cp and gzip.
My proposal is to remove unnecessary full page writes (they are needed
in crash recovery from inconsistent or partial writes) when we
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a poorly chosen
setting could indefinitely prevent large tables from being vacuumed.
But I do not see anything in autovacuum.c that resets the variable.
Am I just being blind?
Hello Everyone,
I very much understand why SJIS is not a server encoding. It contains
ASCII second bytes (including \ and ' both of which can be really
nasty inside a normal sql) and further, half-width katakana is
represented as one byte-characters, incidentally two of which coincide
with
Hello Everyone,
I very much understand why SJIS is not a server encoding. It contains
ASCII second bytes (including \ and ' both of which can be really
nasty inside a normal sql) and further, half-width katakana is
represented as one byte-characters, incidentally two of which coincide
with
Hi,
Here's a patch reflected some of Simon's comments.
1) Removed an elog call in a critical section.
2) Changed the name of the commands, pg_complesslog and pg_decompresslog.
3) Changed diff option to make a patch.
--
Koichi Suzuki
pg_lesslog.tgz
Description: Binary data
On 3/30/07, Simon Riggs [EMAIL PROTECTED] wrote:
Pavan, ISTM you have misunderstood Tom slightly.
Oh, yes. Now that I re-read Tom's comment, his plan invalidation
design and code, I understand things better.
Having the index invisible to all current transactions is acceptable.
Ok.
67 matches
Mail list logo
