On Thu, Apr 26, 2007 at 01:35:42PM -0400, Tom Lane wrote:
> AFAICS you do not need to inline create_statement. The risk factor
> is where you call a routine that does something with a va_list, and
> then you want to do something else (other than va_end) with that va_list
> after it returns. The o
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 d
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 */
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 per
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:
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 broadcast)--
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 thin
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.
---
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
> us
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.
---
Pa
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
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.
rega
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.
---
Fl
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.
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
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 t
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:
> > To
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
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 perfo
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
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
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 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
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 ha
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
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 a
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 betwe
"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 proce
-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
http:
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
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
values
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
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 t
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 va
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
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
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
> 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 so
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
Email
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 au
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 w
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 /home/po
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 optio
> > 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 incr
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 routin
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
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?
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
but it'd make it safe to use in non-WAL contexts (I think there are
other places where we know we are going to init the page and so a
physical read is a waste of time).
Is there? I can't think of any. Extending a
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 initia
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 Thu, 2007-04-26 at 00:13 +0200, Listmail wrote:
> By the way, about indexes :
>
> When you have a small table (say, for a website, maybe a few
> tens of
> megabytes max...) reindexing it takes just a few seconds, maybe
> 10-20
> seconds.
> It could be interesting, performanc
51 matches
Mail list logo
