Zoltan Boszormenyi wrote:
We compiled GCC-4.1.2 on this machine, recompiled PostgreSQL
with the new GCC without --enable-integer-datetimes and it fixed
the problem we experienced. It seems that my suspicion was right:
GCC-3.4.3 on Solaris 10/Sparc is buggy.
I tried original S10 gcc (3.4.3) o
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.
> 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
> 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
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?
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
-
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
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
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.
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 ex
[ 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
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 lis
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
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 showsto
"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
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
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
J
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, 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
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 that
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. T
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 h
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 protoco
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 emo
"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.
--
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 applica
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 kanj
+++
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: Tuesd
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
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 pr
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
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.
---
Te
* 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 f
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
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 t
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
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 tha
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,
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
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
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
usef
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
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
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.
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
"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 ske
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 a
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.
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
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 tsearch
"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_THRESHO
"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 us
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
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...
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 Si
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, an
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
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
"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
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
> >> compat
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 Li
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:
http://community.enterprisedb.com/groupcommit-pghe
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 sessio
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
start
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,
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 o
> > 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 tend
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 f
68 matches
Mail list logo
