As I promised last week, SE-PostgreSQL patches are revised here:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1704.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1704.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1704.patch
[4
On Sun, Mar 8, 2009 at 4:36 PM, Tom Lane wrote:
> Ryan Bradetich writes:
>> This is one of the things I wanted to start looking at for 8.5.
>> My idea was to optionally use : or @ (not sure which is more popular) to
>> specify this token is only a variable.
>
> This whole line of thought is reall
Hello,
I think we need two types of profilers: SQL-based and resource-based.
We have some SQL-based profilers like slow-query logs
(log_min_duration_statement) and contrib/pg_stat_statements in 8.4.
For resource-based profilers, we have DTrace probes[1] and continue to
extend them[2], but unfortun
Tom Lane wrote:
> Worst case, we could say that parallel restore isn't supported on
> mingw. I'm not entirely sure why we bother with that platform at all...
I think you're confusing it with cygwin ...
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQ
Andrew Dunstan writes:
> Alvaro Herrera wrote:
>> Could you use a different static PQExpBuffer on each thread?
>> pthread_getspecific sort of thing, only to be used on Windows.
> For MSVC we could declare it with "_declspec(thread)" and it would be
> allocated in thread-local storage, but it loo
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I have found the source of the problem I saw. dumputils.c:fmtId() uses a
static PQExpBuffer which it initialises the first time it's called. This
gets clobbered by simultaneous calls by Windows threads.
I could just make it auto and set it u
Andrew Dunstan wrote:
> I have found the source of the problem I saw. dumputils.c:fmtId() uses a
> static PQExpBuffer which it initialises the first time it's called. This
> gets clobbered by simultaneous calls by Windows threads.
>
> I could just make it auto and set it up on each call, but t
Andrew Dunstan writes:
> I have found the source of the problem I saw. dumputils.c:fmtId() uses a
> static PQExpBuffer which it initialises the first time it's called. This
> gets clobbered by simultaneous calls by Windows threads.
Ugh. But that doesn't explain the original trouble report on U
Alvaro Herrera writes:
> Not that this has anything to do with the patch at hand, but I remember
> thinking about this sort of error message in the past. Would it be
> appropriate to move the file name and line number to an errcontext()
> field?
I think the message is fine as is. If you moved t
Tom Lane wrote:
I've seen a recent error that suggests we are clobbering memory
somewhere in the parallel code, as well as Olivier Prennant's reported
error that suggests the same thing, although I'm blessed if I can see
where it might be. Maybe some more eyeballs on the code would help.
Selena Deckelmann wrote:
> ! parse_error:
> ! if (token == GUC_EOL || token == 0)
> ! ereport(elevel,
> ! (errcode(ERRCODE_SYNTAX_ERROR),
> ! errmsg(
Ryan Bradetich writes:
> This is one of the things I wanted to start looking at for 8.5.
> My idea was to optionally use : or @ (not sure which is more popular) to
> specify this token is only a variable.
This whole line of thought is really a terrible idea IMHO. plpgsql is
supposed to follow Or
Alvaro Herrera writes:
> Wombat has dyed of internal compiler errors twice lately:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wombat&dt=2009-03-08%2004:30:01
> gistget.c: In function 'gistnext':
> gistget.c:358: internal compiler error: Segmentation fault
> Please submit a full bug
ParseConfigFile currently exits on the first parsing error. Changed
guc_file.l to report all parsing errors before exiting:
* Moved parse_error: block inside while() loop
* Removed cleanup_exit: and associated 'goto'
* Added ereport if ParseConfigFile() returns false
* changed OK to ok ;)
* Added
ITAGAKI Takahiro wrote:
This will introduce SLRU and Executor probes.
We already have Lock, LWLock, Buffer, I/O and XLogs probes.
I'd like to have the following probes, too. In my experience,
they could be bottlenecks or consume much time in some situations.
- idle in transaction
- spin
OK, I poked into this. The test case can be simplified to this:
regression=# create table t1 (f1 numeric(14,0), f2 varchar(30));
CREATE TABLE
regression=# create view vv as
select distinct f1,f2,(select f2 from t1 x where x.f1=aa.f1) as fs
from t1 aa;
CREATE VIEW
regression=# select * from
Hi,
Wombat has dyed of internal compiler errors twice lately:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wombat&dt=2009-03-08%2004:30:01
gistget.c: In function 'gistnext':
gistget.c:358: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed sou
Hello Robert,
I have been bitten by this problem many times as well.
> I wonder whether it would be possible to make PL/pgsql take :foo to
> mean the parameter named foo, and then provide an option to make that
> THE ONLY WAY to refer to the parameter foo. For
> backward-compatibility, and compa
Robert,
The original patch was submitted by Koichi Suzuki - quite a few other
people have looked at it and provided comments. Simon Riggs was
assigned as the original reviewer, but for some reason Dave Page
removed his name from the wiki a few days ago (I'm fixing this now).
Actually, this patc
Tom,
I don't think this one is that far away either. I've been holding Bryce
and Ramon's feet to the fire on the issue of possible downside, but so
far there's not really much evidence of any *actual* as opposed to
theoretical downside.
What sorts of operations would we test which could pot
Alvaro Herrera wrote:
> Tom Lane wrote:
>> alvhe...@postgresql.org (Alvaro Herrera) writes:
>>> Avoid MSVC breakage caused by my previous commit by not using a variable in
>>> the src/bin/scripts Makefile.
>> Buildfarm says it's still broken.
>
> Hmm, yeah, apparently Mkvcbuild.pm needs to be upda
Magnus Hagander wrote:
Applied.
//Magnus
Thanks.
And thanks, Tom, for pointing out my multiple attempts to free.
-selena
--
Selena Deckelmann
End Point Corporation
sel...@endpoint.com
503-282-2512
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
Zdenek Kotala wrote:
I tested your patch and it looks good. however I have several
comments/questions:
1) probes contains pointer but in probe.h it is declared as int. Is it
correct?
The probes cast the pointer to uintptr_t, so the correct type that will
work for both ILP32 and LP64 models
Josh Berkus writes:
>> I don't think this one is that far away either. I've been holding Bryce
>> and Ramon's feet to the fire on the issue of possible downside, but so
>> far there's not really much evidence of any *actual* as opposed to
>> theoretical downside.
> What sorts of operations wou
"Dickson S. Guedes" writes:
> Em Sáb, 2009-03-07 às 19:38 -0500, Tom Lane escreveu:
>> Would you put together a complete example, instead of leaving us to
>> guess what's underlying the view? And what PG version is this?
> Attached there is a dump with the tables and views related:
> vw_that_w
Em Sáb, 2009-03-07 às 19:38 -0500, Tom Lane escreveu:
> I really have a hard time believing that whether you get that error is
> contingent on whether the view returns some rows or not. That's a
> planner message and couldn't possibly have to do with what happens
> at runtime.
Well, today I have
On Sat, Mar 7, 2009 at 9:29 PM, Dimitri Fontaine wrote:
> In fact, maybe a new option to set the OUT parameters prefix to use from
> within the function body would do?
>
> Le 7 mars 09 à 19:56, Dimitri Fontaine a écrit :
>
>> CREATE OR REPLACE FUNCTION test_out
>> (
>> IN a integer,
>> IN b in
Tom Lane writes:
> Gregory Stark writes:
>> Another thought now though. What if someone updates the pg_index entry --
>> since we never reset indcheckxmin then the new tuple will have a new xmin and
>> will suddenly become invisible again for no reason.
>
> Hmm ... if updates to pg_index entries
Gregory Stark writes:
> Another thought now though. What if someone updates the pg_index entry --
> since we never reset indcheckxmin then the new tuple will have a new xmin and
> will suddenly become invisible again for no reason.
Hmm ... if updates to pg_index entries were common then I could g
Tom Lane writes:
> Gregory Stark writes:
>> So it occurs to me that freezing xmin won't actually do what we want for
>> indexcheckxmin. Namely it'll make the index *never* be used.
>
> How do you figure that? FrozenXID is certainly in the past from any
> vantage point.
Uhm, I'm not sure what I
Gregory Stark writes:
> So it occurs to me that freezing xmin won't actually do what we want for
> indexcheckxmin. Namely it'll make the index *never* be used.
How do you figure that? FrozenXID is certainly in the past from any
vantage point.
regards, tom lane
--
Sent
Hiroshi Saito wrote:
> Hi Alvaro-san.
>
> Yeah, It seems that it saves also except pl. then, It also regards me as very
> good.
> I tested just now, of course, it is very comfortable. :-)
Thanks, Hiroshi-san. I just applied that last version.
--
Alvaro Herreraht
Robert Haas escribió:
> As far as I can tell the patch author has responded to all comments
> and pretty much done everything right. I haven't even looked at it
> enough to understand what it does or why I should care, but AFAICS
> it's had more interest and more reviewing than 90% of what was
>
In answering the recent question on -general I reread README.HOT and had a
couple thoughts:
> Practically, we prevent certain transactions from using the new index by
> setting pg_index.indcheckxmin to TRUE. Transactions are allowed to use
> such an index only after pg_index.xmin is below their
34 matches
Mail list logo