Josh Berkus wrote:
Agreed. Simon has finished the pending items he had four weeks ago,
but the code clearly isn't ready for commit yet as new issues are
cropping up. And I think the way subtransactions are handled, which
has been a difficult part of the patch all along, still needs more
thinki
On Wed, 2009-02-25 at 22:11 -0800, Josh Berkus wrote:
> Heikki,
>
> > Agreed. Simon has finished the pending items he had four weeks ago, but
> > the code clearly isn't ready for commit yet as new issues are cropping
> > up. And I think the way subtransactions are handled, which has been a
> >
On Thu, Feb 26, 2009 at 1:46 AM, KaiGai Kohei wrote:
> KaiGai Kohei wrote:
>>
>> Jaime Casanova wrote:
- List of updates:
* It is rebased to the latest CVS HEAD.
>>>
>>> actually i see fails when trying to apply
>>> sepgsql-core-8.4devel-r1627.patch to head (in pg_proc.h)...
>>> ""
KaiGai Kohei wrote:
Jaime Casanova wrote:
- List of updates:
* It is rebased to the latest CVS HEAD.
actually i see fails when trying to apply
sepgsql-core-8.4devel-r1627.patch to head (in pg_proc.h)...
"""
Hunk #4 FAILED at 113.
1 out of 4 hunks FAILED -- saving rejects to file
src/include/c
Jaime Casanova wrote:
On Wed, Feb 25, 2009 at 11:04 PM, KaiGai Kohei wrote:
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1627.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1627.patch
[3/5]
On Wed, Feb 25, 2009 at 11:04 PM, KaiGai Kohei wrote:
> The series of SE-PostgreSQL patches for v8.4 were updated:
>
> [1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1627.patch
> [2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1627.patch
> [3/5]
> http://sepgsql
Heikki,
Agreed. Simon has finished the pending items he had four weeks ago, but
the code clearly isn't ready for commit yet as new issues are cropping
up. And I think the way subtransactions are handled, which has been a
difficult part of the patch all along, still needs more thinking.
Are t
Robert Haas wrote:
On Tue, Jan 27, 2009 at 11:23 AM, Tom Lane wrote:
As for when it *will* be committable --- Heikki is saying two weeks
if no new problems crop up, but given the rate at which new problems
have been found so far, what are the odds of that? We've seen this
movie before.
Since
On Thu, 2009-02-26 at 14:43 +0900, KaiGai Kohei wrote:
> Joshua D. Drake wrote:
> > Tom originally stated (as I recall, no flames please) that we would wait
> > for 2 weeks for the hot standby stuff. It has now been four. That is
> > what I and I believe Robert Haas are talking about.
>
> Thanks,
Joshua D. Drake wrote:
> On Thu, 2009-02-26 at 14:17 +0900, KaiGai Kohei wrote:
>> Joshua D. Drake wrote:
>>> On Wed, 2009-02-25 at 22:56 -0500, Robert Haas wrote:
>>>
> Since it's going to take us two weeks to clean up the other loose ends
> anyway, there's no harm in letting Simon and Hei
On Thu, 2009-02-26 at 14:17 +0900, KaiGai Kohei wrote:
> Joshua D. Drake wrote:
> > On Wed, 2009-02-25 at 22:56 -0500, Robert Haas wrote:
> >
> >>> Since it's going to take us two weeks to clean up the other loose ends
> >>> anyway, there's no harm in letting Simon and Heikki try to complete the
>
Andrew Dunstan writes:
> For fear of passing an ill formed fragment of xml to the processor, we
> strip the xml declaration if any and surround what's left with '" and
> '' and prepend '/x' to the supposed xpath. This is just horrible.
I seem to recall having complained about that at the time,
Joshua D. Drake wrote:
> On Wed, 2009-02-25 at 22:56 -0500, Robert Haas wrote:
>
>>> Since it's going to take us two weeks to clean up the other loose ends
>>> anyway, there's no harm in letting Simon and Heikki try to complete the
>>> patch by then. But I'll happily lay a side bet with you about
On Wed, 2009-02-25 at 22:56 -0500, Robert Haas wrote:
> > Since it's going to take us two weeks to clean up the other loose ends
> > anyway, there's no harm in letting Simon and Heikki try to complete the
> > patch by then. But I'll happily lay a side bet with you about what the
> > situation wil
Andrew Gierth was just pointing out to me how badly broken our XPath
processing is.
For fear of passing an ill formed fragment of xml to the processor, we
strip the xml declaration if any and surround what's left with '" and
'' and prepend '/x' to the supposed xpath. This is just horrible. I
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1627.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1627.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1627.patch
[4/5] h
On Tue, Jan 27, 2009 at 11:23 AM, Tom Lane wrote:
> Dave Page writes:
>> On Tue, Jan 27, 2009 at 3:40 PM, Tom Lane wrote:
>>> I already pointed out some pretty serious problems with the updatable
>>> views patch. Are you claiming they are trivial to fix?
>
>> Not at all. I think the deferral of
On Wed, Feb 25, 2009 at 12:38 AM, Lawrence, Ramon wrote:
>> -Original Message-
>> From: Robert Haas
>> Sadly, there seem to be a number of cases in the Z7 database where the
>> optimization makes things significantly worse (specifically, queries
>> 2, 3, and 7, but especially query 3). Ha
On Wed, 2009-02-25 at 17:04 -0800, Josh Berkus wrote:
> Joshua D. Drake wrote:
> > On Wed, 2009-02-25 at 17:21 -0600, Kevin Grittner wrote:
> >> Should we log a warning at startup when effective_cache_size is less
> >> than shared_buffers?
> >
> > I would say no. Although I could see an argument f
Joshua D. Drake wrote:
On Wed, 2009-02-25 at 17:21 -0600, Kevin Grittner wrote:
Should we log a warning at startup when effective_cache_size is less
than shared_buffers?
I would say no. Although I could see an argument for the default
effective_cache_size always being the same size as shared_b
David Fetter writes:
> Should the patch (and the feature) use WITH RECURSIVE in order to get
> the entire tree?
See the note at the top of that file that all queries are expected to
work with server versions back to 7.4.
regards, tom lane
--
Sent via pgsql-hackers maili
On Thu, Feb 26, 2009 at 12:25:08AM +0100, damien clochard wrote:
> Hello,
>
> Last week, i took some time to check if i was still able to write
> some basic C code. So i looked into the TODO list and picked some
> trivial items.
>
> This one is very basic, it just shows the child tables of a spe
On Wed, 2009-02-25 at 17:21 -0600, Kevin Grittner wrote:
> Should we log a warning at startup when effective_cache_size is less
> than shared_buffers?
I would say no. Although I could see an argument for the default
effective_cache_size always being the same size as shared_buffers.
Joshua D. Drak
Hello,
Last week, i took some time to check if i was still able to write some
basic C code. So i looked into the TODO list and picked some trivial items.
This one is very basic, it just shows the child tables of a specific
table when you type \d in psql :
# create table mother(id SERIAL);
# cr
Should we log a warning at startup when effective_cache_size is less
than shared_buffers?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
I have two questions about the stats collector during recovery.
1)
Why does the stats collector need to wait for consistent recovery
mode? The activity statistics which bgwriter may send before
reaching the mode should be ignored?
2)
Why doesn't ServerLoop() try to restart the stats collecto
Simon Riggs wrote:
>
> On Thu, 2009-02-26 at 06:15 +0900, Fujii Masao wrote:
> > Hi,
> >
> > On Thu, Feb 26, 2009 at 6:03 AM, Simon Riggs wrote:
> > > That is exactly what I am against. Note the words "get rid of".
> > >
> > > This prevents parallel data transfer, use of split mirrors and variou
On Wed, 2009-02-25 at 13:33 -0800, Josh Berkus wrote:
> > You raised that as an annoyance previously because it means that
> > connection in hot standby mode may be delayed in cases of heavy,
> > repeated use of significant numbers of subtransactions.
>
> While most users still don't use explici
You raised that as an annoyance previously because it means that
connection in hot standby mode may be delayed in cases of heavy,
repeated use of significant numbers of subtransactions.
While most users still don't use explicit subtransactions at all,
wouldn't this also affect users who use
On Wed, 2009-02-25 at 23:08 +0200, Heikki Linnakangas wrote:
> >
> > That is exactly the reason why we don't treat an overflowed snapshot as
> > a valid starting point.
>
> We don't? I don't see anything stopping it.
In GetRunningTransactionData() we explicitly set latestRunningXid to
InvalidTr
On Wed, Feb 25, 2009 at 3:45 PM, Heikki Linnakangas
wrote:
> I believe so, see second bullet point in:
>
> http://archives.postgresql.org/message-id/3f0b79eb0902240751t13231593g17fbef70664d4...@mail.gmail.com
Cool.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Wed, 2009-02-25 at 16:11 -0500, Andrew Dunstan wrote:
> OK, so let's assume that we'll provide an extra facility that doesn't
> take anything away but which provides for close to zero config setup for
> the simple case. Frankly, that's what the vast majority of people want,
> in my experien
On Thu, 2009-02-26 at 06:15 +0900, Fujii Masao wrote:
> Hi,
>
> On Thu, Feb 26, 2009 at 6:03 AM, Simon Riggs wrote:
> > That is exactly what I am against. Note the words "get rid of".
> >
> > This prevents parallel data transfer, use of split mirrors and various
> > other techniques. It sounds n
Hi,
On Thu, Feb 26, 2009 at 6:03 AM, Simon Riggs wrote:
> That is exactly what I am against. Note the words "get rid of".
>
> This prevents parallel data transfer, use of split mirrors and various
> other techniques. It sounds neater, but it implies removal of useful
> features.
OK, ISTM that my
Simon Riggs wrote:
On Wed, 2009-02-25 at 22:45 +0200, Heikki Linnakangas wrote:
Robert Haas wrote:
I think the more relevant question right now is whether the work Fujii
Masao is planning to do for 8.5 is reponsive to the following comment
from Heikki:
# IMHO, the synchronous replica
Simon Riggs wrote:
On Wed, 2009-02-25 at 22:39 +0200, Heikki Linnakangas wrote:
When we take the snapshot of running transactions in the master, in
GetRunningTransactionData(), it only includes top-level xids and those
subxids that are in the subxid caches. Overflowed subxids are not
included
On Tue, 2009-02-24 at 23:41 +, Simon Riggs wrote:
> On Tue, 2009-02-24 at 22:29 +0200, Heikki Linnakangas wrote:
> > overwrites subxids array, and will resurrect any already aborted
> > subtransaction.
> >
> > Isn't XLByteLT(proc->lsn, lsn) always true, because 'lsn' is the lsn of
> > the
On Wed, 2009-02-25 at 22:39 +0200, Heikki Linnakangas wrote:
> When we take the snapshot of running transactions in the master, in
> GetRunningTransactionData(), it only includes top-level xids and those
> subxids that are in the subxid caches. Overflowed subxids are not
> included. Isn't that
On Wed, 2009-02-25 at 22:45 +0200, Heikki Linnakangas wrote:
> Robert Haas wrote:
> > I think the more relevant question right now is whether the work Fujii
> > Masao is planning to do for 8.5 is reponsive to the following comment
> > from Heikki:
> >
> > # IMHO, the synchronous replication isn't
Robert Haas wrote:
I think the more relevant question right now is whether the work Fujii
Masao is planning to do for 8.5 is reponsive to the following comment
from Heikki:
# IMHO, the synchronous replication isn't in such good shape, I'm
afraid. I've said
# this before, but I'm not happy with t
When we take the snapshot of running transactions in the master, in
GetRunningTransactionData(), it only includes top-level xids and those
subxids that are in the subxid caches. Overflowed subxids are not
included. Isn't that a problem? When the standby initializes the
recovery procs using the
On Tue, Feb 24, 2009 at 5:58 PM, Simon Riggs wrote:
> On Tue, 2009-02-24 at 16:52 -0500, Robert Haas wrote:
>
>> I didn't think I had proposed any such thing, although maybe I'm just
>> not remembering. I'm pretty confused as to what the current thread is
>> all about.
>
> http://archives.postgre
Hi,
My reply to Gregory's comment didn't have any objections. I believe,
as I posted to Wiki page, latest posted patch is okay and waiting for
review.
2009/2/24 Robert Haas :
> On Sun, Jan 25, 2009 at 7:15 AM, Gregory Stark wrote:
>> Koichi Suzuki writes:
>>
>>> Please find enclosed 2nd patch
pg_mb2wchar_with_len() converts server encoded strings to pg_wchar
strings. But pg_wchar is typedef'd as unsigned int which is not the
same as wchar_t at least on Windows (unsigned short).
Oops. The problem is here. TParserInit allocates twice less memory than needed.
And it happens if sizeof(wch
On Fri, Feb 13, 2009 at 9:49 PM, Tom Lane wrote:
>
> The only other corruption mechanism I can think of is that pg_clog might
> contain commit bits for some logically inconsistent set of transaction
> numbers, due to some pages of pg_clog having made it to disk and others
> not. That could result
Tom Lane wrote:
> Magnus Hagander writes:
>> Since we removed it from the general Makefiles, I suggest we actually
>> remove it from the Mkvcbuild.pm file as well. it's still there in the
>> history - just like the general Makefiles.
>
> +1. Comments are not a substitute for having CVS history .
Magnus Hagander writes:
> Since we removed it from the general Makefiles, I suggest we actually
> remove it from the Mkvcbuild.pm file as well. it's still there in the
> history - just like the general Makefiles.
+1. Comments are not a substitute for having CVS history ...
Dave Page wrote:
> On Wed, Feb 25, 2009 at 4:40 PM, Tom Lane wrote:
>> ... and the build logs don't show any particular reason for it.
>> What is wrong, and why isn't the buildfarm script capturing a
>> useful error message?
>
> Looks like this:
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/sr
On Wed, Feb 25, 2009 at 4:40 PM, Tom Lane wrote:
> ... and the build logs don't show any particular reason for it.
> What is wrong, and why isn't the buildfarm script capturing a
> useful error message?
Looks like this:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/foreign/Makefile?r
Tom Lane wrote:
> ... and the build logs don't show any particular reason for it.
> What is wrong, and why isn't the buildfarm script capturing a
> useful error message?
It's the format change in the makefile for foreign stuff. The line:
Could not match in foreign makefile
I don't know why it e
... and the build logs don't show any particular reason for it.
What is wrong, and why isn't the buildfarm script capturing a
useful error message?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Alan Li writes:
> Running the following against HEAD and REL8_3_6:
> create table foo (a varchar(500));
> create view bar as select case foo.a when '1' then 'foo' else 'bar' end as
> fa from foo;
> \d bar
> Causes as assertion in the backend:
Thanks for the report. Looks like I forgot to conside
Frank Featherlight wrote:
> 1) Uninstalled the following programs+program files folder:
>
> File Shredder
> Holdem Manager (this is the program I need postgresql for)
> mIRC
> Proxifier
This one sounds like a potential culprit.
> GetDataBack for FAT and NTFS
This could be, but probably shouldn'
On Wed, Feb 25, 2009 at 1:43 PM, Magnus Hagander wrote:
>
> The thing is we're doing some fairly complex things as we start up. And
> since we don't know exactly what the problem is, we don't know what to
> look for. We'd have to run the whole thing over again... And still not
> be able to point o
Alan Li wrote:
Running the following against HEAD and REL8_3_6:
Same problem exists in 8.2 and 8.1 as well. The code in ruleutils.c is
similar in 8.0 as well, except that the Assertion isn't there.
create table foo (a varchar(500));
create view bar as select case foo.a when '1' then 'foo' e
Richard Huxton wrote:
> Magnus Hagander wrote:
>> Heikki Linnakangas wrote:
>>> Of course, none of this helps if the culprit is a DLL or a 3rd party
>>> program that allocates the adress space immediately at CreateProcess.
>> AFAIK all the cases where we *have* identified the culprit (which has
>>
Frank Featherlight wrote:
It's Microsoft Windows XP Home Edition Version 2002 with Service Pack 3.
XP-HE is at best a very poor platform for postgres. You might have more
success on XP-Pro. I am not clear if this is what is causing your
problems, however.
cheers
andrew
--
Sent via p
On Wed, Feb 25, 2009 at 12:41 PM, Frank Featherlight
wrote:
> I have attached the sysinfo, please don't abuse it in any way possible, I
> trust you guys with that.
>
:-) Thanks!
> As far as I can remember, no OEM versions of anti-virus were installed.
> Like I said before, did have these installe
Magnus Hagander wrote:
> Heikki Linnakangas wrote:
>>
>> Of course, none of this helps if the culprit is a DLL or a 3rd party
>> program that allocates the adress space immediately at CreateProcess.
>
> AFAIK all the cases where we *have* identified the culprit (which has
> been antivirus or firew
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Frank Featherlight writes:
>>> while reading your thread two things come to mind, I have installed:
>>> Registry Mechanic ( http://www.pctools.com/registry-mechanic )
>>> Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
>>> Any o
Attached is a patch that modifies psql \dX commands to treat objects
in information_schema as "system objects". This prevents them from
showing up in \dX *.* and polluting the user objects list. This is
especially annoying if user objects are in multiple schemas, and
one wants to get a quick overvi
On Wed, Feb 25, 2009 at 4:51 AM, Tom Lane wrote:
> Frank Featherlight writes:
>> while reading your thread two things come to mind, I have installed:
>> Registry Mechanic ( http://www.pctools.com/registry-mechanic )
>> Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
>> Any
Running the following against HEAD and REL8_3_6:
create table foo (a varchar(500));
create view bar as select case foo.a when '1' then 'foo' else 'bar' end as
fa from foo;
\d bar
Causes as assertion in the backend:
TRAP: FailedAssertion("!(Node*)(((list_head(((OpExpr *)
w)->args))->data.ptr_
Tom Lane wrote:
Frank Featherlight writes:
while reading your thread two things come to mind, I have installed:
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
Any of these two might cause the problem aswell i
64 matches
Mail list logo
