On Apr 23, 2007, at 11:38 PM, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
Attached is a very quick hack of a patch to do this.
Does anyone have any feedback on this approach? If people are
satisfied
with this solution, I can
On Apr 25, 2007, at 2:48 PM, Heikki Linnakangas wrote:
In recovery, with full_pages_writes=on, we read in each page only
to overwrite the contents with a full page image. That's a waste of
time, and can have a surprisingly large effect on recovery time.
As a quick test on my laptop, I
This was another occurance of the strange create index failure on
Narwhal - unfortunately, despite having 'keep_error_builds' = 1 in my
BF config it seems to have removed the tree so I can't get the dump that
Tom wanted.
Does anyone know why the keep_error_builds option didn't work in this
case?
On Wed, Apr 25, 2007 at 03:17:19PM -0400, Tom Lane wrote:
Why in the world is that like that? We don't have such a kluge
anyplace else we use va_list. stringinfo.c for instance has
never needed any such thing.
I don't remember the exact details but this was added a long time ago
before 8.0
On Wed, Apr 25, 2007 at 04:38:30PM -0400, Tom Lane wrote:
My recommendation is to get rid of the APREF hack, deal only in
va_list not va_list, and inline ECPGget_variable into the two
places it's used to avoid the question of passing va_lists around
after they've been modified. The routine's
Writing to a different area was considered in pg, but there were
more
negative issues than positive.
So imho pg_compresslog is the correct path forward. The current
discussion is only about whether we want a more complex
pg_compresslog
and no change to current WAL, or an increased WAL
Dave Page wrote:
This was another occurance of the strange create index failure on
Narwhal - unfortunately, despite having 'keep_error_builds' = 1 in my
BF config it seems to have removed the tree so I can't get the dump that
Tom wanted.
Does anyone know why the keep_error_builds option
ARGH!
This time with patch.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
diff -ruN --exclude CVS
Andrew Dunstan wrote:
Dave Page wrote:
This was another occurance of the strange create index failure on
Narwhal - unfortunately, despite having 'keep_error_builds' = 1 in my
BF config it seems to have removed the tree so I can't get the dump that
Tom wanted.
Does anyone know why the
Michael Meskes wrote:
Attached you'll find a patch that should inline both functions and
remove the APREF stuff. This successfully runs the regression suite on
my Linux box. Please test it on those archs that needed special
treatment before I commit.
If you commit to HEAD it will be
On Thu, Apr 26, 2007 at 06:28:29AM -0500, Andrew Dunstan wrote:
If you commit to HEAD it will be automatically tested on the buildfarm.
True. But it might also break a lot of other archs without helping on
those troubled ones. I thought this way would be better.
Michael
--
Michael Meskes
So what happens if a backend is running with full_page_writes
= off, someone edits postgresql.conf to turns it on and
forgets to reload/ restart, and then we crash? You'll come up
in recovery mode thinking that f_p_w was turned on, when in
fact it wasn't.
ISTM that we need to somehow
Jim Nasby [EMAIL PROTECTED] writes:
So what happens if a backend is running with full_page_writes = off,
someone edits postgresql.conf to turns it on and forgets to reload/
restart, and then we crash? You'll come up in recovery mode thinking
that f_p_w was turned on, when in fact it
On Tue, 2007-04-24 at 18:04 +0300, Marko Kreen wrote:
Attached patch addresses all 3 comments. As it will be
top-level command, I put code into commands/discard.c
Applied with some minor tweaks -- thanks for the patch. I didn't bother
moving the regression tests out of guc.sql, although they
Patch applied from Neil.
---
Marko Kreen wrote:
On 4/23/07, Neil Conway [EMAIL PROTECTED] wrote:
On Tue, 2007-04-17 at 16:34 +0300, Marko Kreen wrote:
Attached patch does following conversions:
ISTM it would be
On 4/26/07, Michael Meskes [EMAIL PROTECTED] wrote:
On Wed, Apr 25, 2007 at 04:38:30PM -0400, Tom Lane wrote:
My recommendation is to get rid of the APREF hack, deal only in
va_list not va_list, and inline ECPGget_variable into the two
places it's used to avoid the question of passing
Michael Meskes [EMAIL PROTECTED] writes:
Having spend countless hours debugging this stuff I fully agree with
you. It's not just ECPGget_variable though. I also had to inline
create_statement.
AFAICS you do not need to inline create_statement. The risk factor
is where you call a routine that
For a long time one of the big gripes we get is that when using psql
interactively if you turn autocommit off and you typo on the nth command
you've suddenly lost all your work. The response was always that we needed a
generic subtransaction facility to handle it.
We've had such a facility for a
Hi,
I try to update a tuple in pg_attribute table by using the function
simple_heap_update while somequery processing is going on. But when I use to
see the value of that tuple(just updated) once again by SearchSysCache
function in the same query processing, I am not able to see the updated
Hi, I wanto joinin the developer group of postgresql。
But, I just donot know how to put the first step, as I installed the
postgresql, and also get the postgresql code. after that, I also installed
the cygwin on my computer( as my os is windows xp). but now I wonder what's
my next step. as I have
-hackers probably isn't the place for such complaints.
The problem not beacuse of MSVC, but because of member misconfiguration,
by the look of it. The tar command string will need to be set in the
config file and tar installed. I found that I needed bsdtar for Windows
for this to work. See
rupesh bajaj [EMAIL PROTECTED] writes:
I try to update a tuple in pg_attribute table by using the function
simple_heap_update while somequery processing is going on. But when I use to
see the value of that tuple(just updated) once again by SearchSysCache
function in the same query processing,
On Tue, 2007-04-24 at 17:38 -0400, Neil Conway wrote:
which included other modifications to reduce the pgstat I/O volume in
8.1. I don't think this particular change was wise
I looked into this a bit further:
(1) I believe the reasoning for Tom's earlier change was not to reduce
the I/O
Neil Conway wrote:
(3) I don't like the fact that the current coding is so willing to throw
away VACUUM and ANALYZE pgstat messages. I think it is quite plausible
that the DBA might be interested in the last-VACUUM and last-ANALYZE
information for a table which hasn't had live operations
Simon Riggs wrote:
On Fri, 2007-03-09 at 11:47 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
It strikes me that allowing archive_command to be changed on the fly
might not be such a good idea though, or at least it
Where are we on this?
---
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
FWIW, is the attached patch about what you had in mind? (It probably only
covers normal types at the moment.)
Hm, I hadn't
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we on this?
Since there weren't any objections, I guess we can do it ;-)
I'll try to do something with Peter's patch plus removing the deadwood.
Would you add his patch to the queue so I don't forget?
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we on this?
Since there weren't any objections, I guess we can do it ;-)
I'll try to do something with Peter's patch plus removing the deadwood.
Would you add his patch to the queue so I don't forget?
Added.
--
Bruce
Gregory Stark [EMAIL PROTECTED] writes:
I would like to suggest that we make psql default when in interactive mode to
using AUTOCOMMIT=false and ON_ERROR_ROLLBACK=true.
That is *way* too big a behavioral change to make depend on something as
fragile as whether psql thinks it's interactive or
Where are we on this?
---
Tom Lane wrote:
In this thread:
http://archives.postgresql.org/pgsql-bugs/2007-03/msg00145.php
we eventually determined that the reported lockup had three components:
(1) something (still not
I have seen no one do peroformance testing of this, so it seems it will
have to wait for 8.4.
---
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
What I would definitely like to see for 8.3 is some performance
Josh,
Josh Berkus wrote:
Koichi, Andreas,
1) To deal with partial/inconsisitent write to the data file at crash
recovery, we need full page writes at the first modification to pages
after each checkpoint. It consumes much of WAL space.
We need to find a way around this someday. Other DBs
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
[ redirecting to -hackers for wider comment ]
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Pavan Deolasee wrote:
On 4/11/07, Tom Lane [EMAIL PROTECTED] wrote:
[ itch... ] The problem is with
Simon Riggs wrote:
That should go away entirely; to me the main point of the separate
wal-writer process is to take over responsibility for not letting too
many dirty wal buffers accumulate.
Yes
I'll make the agreed changes by next Wed/Thurs.
I have seen no patch yet with the
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Greg Smith wrote:
I'm mostly done with my review of the Automatic adjustment of
bgwriter_lru_maxpages patch. In
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.
---
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we on this?
Still trying to think of a less messy solution...
What it essentially says is that trying to clean up shared-memory
state in a PG_TRY block is unsafe: you can't be certain you'll
get to do it.
regards, tom
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we on this?
Still trying to think of a less messy solution...
OK, put in the patches hold queue for 8.4.
---
What it essentially says is that
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.
---
Is anyone working on this fix?
---
Tom Lane wrote:
Log Message:
---
Remove some of the most blatant brain-fade in the recent guc patch
(it's so nice to have a buildfarm member that actively rejects naked
uses
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.
---
Now that we are half-way though the scheduled feature freeze, I wanted
to share my thoughts about this period.
Having just pushed all open items into the patches queue or 8.4 hold
queue, I am seeing that we have many more in-process patches than we
normally do at this stage of the process. I
Bruce Momjian [EMAIL PROTECTED] writes:
Is anyone working on this fix?
I dunno, but that patch is gonna get reverted altogether if someone
doesn't fix the fact that it broke PGCLIENTENCODING ...
regards, tom lane
---(end of
Dave Page [EMAIL PROTECTED] writes:
I've been seeing this failure intermittently on Narwhal HEAD, and once
on 8.1. Other branches have been OK, as have other animals running on
the same physical box. Narwhal-HEAD is run more often than any other
builds however.
Oh, this is interesting:
On Thu, 26 Apr 2007, Zeugswetter Andreas ADI SD wrote:
I am not sure that shrinking per WAL record size (other than the full
page images), e.g. by only logging changed bytes and not whole tuples,
would have a huge impact on OLTP tx/sec, since the limiting factor is
IO's per second and not Mb
I haven't read the rest of the thread yet, but is this hunk not buggy?
yylex() is side-effecting, so the two calls to yylex() do not do what
the comment suggests.
*** 2083,2091
check_FROM = false;
}
! /* check FROM keyword after direction's specification */
!
Hello,
it's true. There is bug. I'll send actualised version tomorrow.
Regards
Pavel
I haven't read the rest of the thread yet, but is this hunk not buggy?
yylex() is side-effecting, so the two calls to yylex() do not do what
the comment suggests.
! /* check FROM or IN keyword after
48 matches
Mail list logo
