On Thu, Apr 28, 2011 at 4:21 PM, Vaibhav Kaushal <
vaibhavkaushal...@gmail.com> wrote:
> Thanks a lot. I was browsing the code and was thinking this would be the
> most probable scenario.
>
> But, the point is that even after removing the args initialization part in
> the ExecInitExpr for AggrefSt
28.04.2011 21:36, David Fetter пишет:
On Thu, Apr 28, 2011 at 12:07:34PM +0900, Vlad Arkhipov wrote:
27.04.2011 18:38, Heikki Linnakangas пишет:
On 27.04.2011 12:24, Vlad Arkhipov wrote:
27.04.2011 17:45, Nicolas Barbier:
2011/4/27 Vlad Arkhipov:
I'm
On Apr 28, 2011, at 3:40 PM, Andrew Dunstan wrote:
> It's been pointed out before that plugins (like FDWs) can invent their own
> explain nodes, so we'll never have a canonical list of such nodes.
Oh, interesting. Stil, a list of core nodes is a good 90% solution, IMHO.
Best,
David
--
Sent
On 04/28/2011 06:07 PM, David E. Wheeler wrote:
On Apr 28, 2011, at 3:02 PM, Peter Geoghegan wrote:
The code for all nodes is in src/backend/executor.
I think that you will find it useful to look at the big switch
statements in ExecInitNode() and friends in execProcnode.c .
Yep, same as wha
On Apr 28, 2011, at 3:02 PM, Peter Geoghegan wrote:
> The code for all nodes is in src/backend/executor.
>
> I think that you will find it useful to look at the big switch
> statements in ExecInitNode() and friends in execProcnode.c .
Yep, same as what I found in src/backend/commands/explain.c.
The code for all nodes is in src/backend/executor.
I think that you will find it useful to look at the big switch
statements in ExecInitNode() and friends in execProcnode.c .
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sen
Joel,
On Mon, Apr 25, 2011 at 07:45:13PM +0200, Joel Jacobson wrote:
> (1) Make the detailed error message available in SPs and not only the short
> error message (SQLERRM)
Agreed. Really, all the information available via PQresultErrorField should
also be exposed in PL error handling facilities
Hackers,
For my [explanation extension](http://pgxn.org/extension/explanation) I wanted
to put together a list of node types, since I'm always having to figure them
out to decide which nodes I'm interested in. Reading
src/backend/commands/explain.c I assembled this list:
+ Aggregate
+
On Fri, Apr 29, 2011 at 1:27 AM, Tom Lane wrote:
> I seem to recall some discussion recently about documenting where you
> should cut over to using "gist__intbig_ops" --- IIRC, it wasn't all that
> "big" by modern standards. But it doesn't look like any such change made
> it into the docs. Shou
Alexander Korotkov writes:
> What opclass is used for GiST index: gist__int_ops or gist__intbig_ops?
> Do you take into account that gist__int_ops is very inefficient for large
> datasets?
I seem to recall some discussion recently about documenting where you
should cut over to using "gist__intbig
On Thu, Apr 28, 2011 at 11:11 PM, Josh Berkus wrote:
> I'm currently looking at a database which has some extreme bloating of
> intarray GiST indexes. As in 1000% bloating in only a few months. This
> is not a particularly high-transaction-rate database, so the bloating is
> a little surprising
On Apr 28, 2011, at 7:04 AM, Tom Lane wrote:
> I think what we're discussing here is bug-fix revisions that don't
> affect the SQL declarations for the extension. Presumably, that means a
> change in the C code, so the shared library is the right place to keep
> the revision number. A version nu
Josh Berkus writes:
>> 1. What PG version?
> 8.4.4, so it has the broken picksplit.
> ...
> Yeah, I'll test updating to 8.4.8.
Uh, no, the picksplit bugs we fixed were in cube and seg --- there's
no reason to think that updating will help this. But 8.4's pgstattuple
does appear to support gist
> 1. What PG version?
8.4.4, so it has the broken picksplit.
> 2. If new enough to have contrib/pgstattuple, what does pgstattuple()
>have to say about the index?
Will check.
> I'm suspicious that this might be bloat caused by a bad picksplit function,
> not from having a lot of dead entri
Josh Berkus writes:
> I'm currently looking at a database which has some extreme bloating of
> intarray GiST indexes. As in 1000% bloating in only a few months. This
> is not a particularly high-transaction-rate database, so the bloating is
> a little surprising; I can only explain it if vacuum
As originally noted here:
http://archives.postgresql.org/message-id/20110329215043.ga11...@tornado.gateway.2wire.net
Previous version of patch proposed here:
http://archives.postgresql.org/message-id/20110418235041.gb2...@tornado.leadboat.com
This was a side issue to that thread, and its primary
> I'll make that change if Michael's happy.
Sure, go ahead.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
--
Sent via pgsql-hackers mailing list
Hackers,
I'm currently looking at a database which has some extreme bloating of
intarray GiST indexes. As in 1000% bloating in only a few months. This
is not a particularly high-transaction-rate database, so the bloating is
a little surprising; I can only explain it if vacuum wasn't cleaning the
Excellent Notice
Success for All
Kind Best Regard
Ernesto Lozano
Director General
Hia Technology de Venezuela
ISV/ de EnterpriseDB for Venezuela , Colombia
Member Community Postgresql Venezuela and Latin America
www.hiatechnology.com.ve
eloz...@hiatechnology.com.ve
v...@postgresql.org
Twitter: e
On 04/28/2011 12:41 PM, Tom Lane wrote:
c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c:505:6:
warning: unknown conversion type character 'G' in format
c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql
On 04/27/2011 05:30 PM, Noah Misch wrote:
I'm not sure what to do about the back branches and cases where data is
already in databases. This is fairly ugly. Suggestions welcome.
We could provide a script in (or linked from) the release notes for testing the
data in all your xml columns.
H
On Apr 28, 2011, at 6:29 PM, "Kevin Grittner"
wrote:
> Robert Haas wrote:
>> On Apr 28, 2011, at 9:55 AM, Dan Ports wrote:
>
>>> The memory barrier when acquiring the buffer page lwlock acts as
>>> the synchronization point we need. When we see that no
>>> serializable transactions are running
Andrew Dunstan writes:
> Done with that name. FYI, here is the complete set of warnings now
> generated on pitta:
The "unused variable" is flex's fault, not much we can do about that.
Seems like most of the others could be removed with some explicit casting.
>
> c:/mingw/msys/1.0/home/pgru
Robert Haas wrote:
> On Apr 28, 2011, at 9:55 AM, Dan Ports wrote:
>> The memory barrier when acquiring the buffer page lwlock acts as
>> the synchronization point we need. When we see that no
>> serializable transactions are running, that could have been
>> reordered, but that read still had t
On Apr 28, 2011, at 9:55 AM, Dan Ports wrote:
> On Thu, Apr 28, 2011 at 08:43:30AM +0100, Simon Riggs wrote:
>>> We added a quick return which didn't need to check any locks at the
>>> front of this routine which is taken if there are no active
>>> serializable transactions on the cluster at the m
On 04/28/2011 12:30 AM, Tom Lane wrote:
Andrew Dunstan writes:
What I'm thinking of doing is to set up something like:
#define PG_PRINTF_CHECK __printf__
and on Windows redefine it to __gnu_printf__, and then set all the
formats to use PG_PRINTF_CHECK.
Sound OK?
+1 ... those __attribut
On Wed, Apr 27, 2011 at 2:48 PM, Dave Page wrote:
> I'm pleased to announce that effective immediately, Magnus Hagander
> will be joining the PostgreSQL Core Team.
Well deserved. Congratulations!
Roberto
Alvaro Herrera writes:
> Excerpts from Boszormenyi Zoltan's message of jue abr 28 11:03:56 -0300 2011:
>> ERROR: could not determine which collation to use for string comparison
>> HINT: Use the COLLATE clause to set the collation explicitly.
> Maybe the pg_node_tree problem is a bug with the c
Excerpts from Boszormenyi Zoltan's message of jue abr 28 11:03:56 -0300 2011:
> My question is that why pg_node_tree is unusable as
> syscache attribute? I attempted to alias it as text in the patch
> but I get the following error if I try to use it by setting
> USE_SYSCACHE_FOR_SEARCH to 1 in sel
Excerpts from Boszormenyi Zoltan's message of jue abr 28 11:03:56 -0300 2011:
> Hi,
>
> attached is the WIP patch for cross-column statistics and
> extra expression statistics.
>
> My question is that why pg_node_tree is unusable as
> syscache attribute? I attempted to alias it as text in the pat
Boszormenyi Zoltan writes:
> My question is that why pg_node_tree is unusable as
> syscache attribute? I attempted to alias it as text in the patch
> but I get the following error if I try to use it by setting
> USE_SYSCACHE_FOR_SEARCH to 1 in selfuncs.c.
> Directly using the underlying pg_statist
On Thu, Apr 28, 2011 at 3:04 PM, Tom Lane wrote:
> Daniele Varrazzo writes:
>> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen wrote:
>>> How about each .so containing a version callback?
>>>
>>> Thus you can show what is the version of underlying implementation
>>> without needing to mess with cat
Andrew Dunstan writes:
> Yeah, I think that the underscore variants got added because of cases
> like ours where printf is sometimes defined as a macro. I'll just need
> to make sure that this gets set before there's any possibility of that
> happening.
The existing code would already be broke
Daniele Varrazzo writes:
> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen wrote:
>> How about each .so containing a version callback?
>>
>> Thus you can show what is the version of underlying implementation
>> without needing to mess with catalogs just to keep track of patchlevel
>> of C code.
>
On 04/28/2011 12:44 AM, Tom Lane wrote:
Andrew Dunstan writes:
What I'm thinking of doing is to set up something like:
#define PG_PRINTF_CHECK __printf__
BTW, gcc 2.95.3 documents "printf", and not "__printf__".
Suggest not including the underscores, since that's apparently a
johnny-com
Simon Riggs wrote:
> On Wed, Apr 27, 2011 at 8:59 PM, Kevin Grittner
> wrote:
>
>> For correct serializable behavior in the face of concurrent DDL
>> execution, I think that a request for a heavyweight ACCESS
>> EXCLUSIVE lock might need to block until all SIREAD locks on the
>> relation have be
That's some great starting advice there. I have a couple of final exams in
the next 36 hours. Will get to work almost immediately after that.
I will definitely take small steps before going for some of the tougher
tasks. I would of-course like this conversation to go on, so I can see a
more compreh
On Thu, Apr 28, 2011 at 4:40 PM, Daniele Varrazzo
wrote:
> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen wrote:
>> On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
>> wrote:
>>> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
>>> wrote:
Tom Lane writes:
> If you didn't change the in
On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen wrote:
> On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
> wrote:
>> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
>> wrote:
>>> Tom Lane writes:
If you didn't change the install script then it's not necessary to
execute ALTER EXTENSI
>
> On Apr 27, 2011 1:49 PM, "Dave Page" wrote:
>>
>> I'm pleased to announce that effective immediately, Magnus Hagander
>> will be joining the PostgreSQL Core Team.
>>
>> Magnus has been a contributor to PostgreSQL for over 12 years, and
>> played a major part in the development and ongoing main
HSIEN-WEN CHU writes:
> When database files are on a VxFS filesystem, performance can be
> significantly improved by setting the VX_CONCURRENT cache advisory on
> the file according to vxfs document,
Presumably, if whatever behavior this invokes were an unalloyed good,
they'd have just made it th
On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
wrote:
> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
> wrote:
>> Tom Lane writes:
>>> If you didn't change the install script then it's not necessary to
>>> execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the
>>> pg_exten
On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> If you didn't change the install script then it's not necessary to
>> execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the
>> pg_extensions catalog has to reflect the bug fix level of an extension,
>>
On Apr 27, 2011 1:49 PM, "Dave Page" wrote:
>
> I'm pleased to announce that effective immediately, Magnus Hagander
> will be joining the PostgreSQL Core Team.
>
> Magnus has been a contributor to PostgreSQL for over 12 years, and
> played a major part in the development and ongoing maintenance of
On Thu, Apr 28, 2011 at 12:07:34PM +0900, Vlad Arkhipov wrote:
> 27.04.2011 18:38, Heikki Linnakangas пишет:
> >On 27.04.2011 12:24, Vlad Arkhipov wrote:
> >>27.04.2011 17:45, Nicolas Barbier:
> >>>2011/4/27 Vlad Arkhipov:
> >>>
> I'm currently need predicate locking in the project, so there ar
Am 28.04.2011 05:52, schrieb Tom Lane:
> =?ISO-8859-15?Q?Yves_Wei=DFig?=
> writes:
>> Am 27.04.2011 16:11, schrieb Heikki Linnakangas:
>>> What kind of a Datum do you want it to be? What data type? See
>>> CStringGetDatum, or perhaps CStringGetTextDatum(). Or perhaps you want
>>> to call the inpu
Hi list,
currently I am obtaining a new block at the end of an index with:
buf = ReadBuffer(rel, P_NEW);
but it throws:
ERROR: unexpected data beyond EOF in block 0 of relation base/11874/156053
HINT: This has been seen to occur with buggy kernels; consider updating
your system.
system is up
Thanks a lot. I was browsing the code and was thinking this would be the
most probable scenario.
But, the point is that even after removing the args initialization part in
the ExecInitExpr for AggrefState, the sum() function is working. I believe
that is also a aggregate function! If yes, then how
Tom Lane writes:
> If you didn't change the install script then it's not necessary to
> execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the
> pg_extensions catalog has to reflect the bug fix level of an extension,
> but that is *not* the intention. If it did reflect that, you'd
The args in AggrefExprState, are used in the functions ExecAgg, ExecInitAgg
and their minions to evaluate the aggregates. The ExecEvalAggref() merely
retrieves the results of aggregation calculated during ExecAgg.
On Tue, Apr 26, 2011 at 12:04 PM, Vaibhav Kaushal <
vaibhavkaushal...@gmail.com> wro
Auguri!
On Wed, Apr 27, 2011 at 8:48 PM, Dave Page wrote:
> I'm pleased to announce that effective immediately, Magnus Hagander
> will be joining the PostgreSQL Core Team.
>
> Magnus has been a contributor to PostgreSQL for over 12 years, and
> played a major part in the development and ongoing m
On Thu, Apr 28, 2011 at 08:43:30AM +0100, Simon Riggs wrote:
> > We added a quick return which didn't need to check any locks at the
> > front of this routine which is taken if there are no active
> > serializable transactions on the cluster at the moment of update.
>
> Surprised to hear nobody me
On Wed, Apr 27, 2011 at 8:59 PM, Kevin Grittner
wrote:
> For correct serializable behavior in the face of concurrent DDL
> execution, I think that a request for a heavyweight ACCESS EXCLUSIVE
> lock might need to block until all SIREAD locks on the relation have
> been released. Picture, for exa
On Wed, Apr 27, 2011 at 7:15 PM, Kevin Grittner
wrote:
> (1) If a tuple which is predicate locked, or sits on a predicate-
> locked page, is updated, the predicate lock is duplicated for the
> new tuple. We have found patterns of updates involving four or more
> transactions where a non-serializ
On Wed, Apr 27, 2011 at 7:15 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>
>> Reading the code, IIUC, we check for RW conflicts after each write
>> but only if the writer is running a serializable transaction.
>
> Correct as far as that statement goes.
Thanks.
I'm surprised by that though, i
55 matches
Mail list logo
