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
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
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 Herrera
Gregory Stark st...@enterprisedb.com 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.
Tom Lane t...@sss.pgh.pa.us writes:
Gregory Stark st...@enterprisedb.com 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
Gregory Stark st...@enterprisedb.com 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
Tom Lane t...@sss.pgh.pa.us writes:
Gregory Stark st...@enterprisedb.com 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
On Sat, Mar 7, 2009 at 9:29 PM, Dimitri Fontaine dfonta...@hi-media.comwrote:
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,
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
Dickson S. Guedes lis...@guedesoft.net 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
Josh Berkus j...@agliodbs.com 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
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
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
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 updated with the
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
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
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
Hi,
Wombat has dyed of internal compiler errors twice lately:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wombatdt=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
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
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
-
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 ;)
*
Alvaro Herrera alvhe...@commandprompt.com writes:
Wombat has dyed of internal compiler errors twice lately:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wombatdt=2009-03-08%2004:30:01
gistget.c: In function 'gistnext':
gistget.c:358: internal compiler error: Segmentation fault
Ryan Bradetich rbradet...@gmail.com 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
Selena Deckelmann wrote:
! parse_error:
! if (token == GUC_EOL || token == 0)
! ereport(elevel,
! (errcode(ERRCODE_SYNTAX_ERROR),
!
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.
Alvaro Herrera alvhe...@commandprompt.com 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
Andrew Dunstan and...@dunslane.net 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
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 that
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
Andrew Dunstan and...@dunslane.net 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,
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 PostgreSQL
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
32 matches
Mail list logo
