When sitting inside an extension, and given an arbitrary TransactionId, how can
you determine that it aborted/crashed *and* that no other active transaction
thinks it is still running?
I've tried to answer this question myself (against the 9.3 sources), and it
seems like it's just:
{
Transa
> On Oct 22, 2017, at 1:50 PM, Peter Geoghegan wrote:
>
> On Sun, Oct 22, 2017 at 12:23 PM, Eric Ridge wrote:
>> Can anyone confirm or deny that this is correct? I feel like it is correct,
>> but I'm no expert.
>
> What are you going to use the code for? I thi
> On Oct 22, 2017, at 2:50 PM, Jaime Casanova
> wrote:
>
> so, what you want is txid_status() [1]... while this is new in v10 you
> can use the code as guide or just migrate to v10 ;)
Oh neat, thanks.
Doesn't that tell you the status relative to the transaction calling
txid_status()?
I
> On Oct 22, 2017, at 3:24 PM, Peter Geoghegan wrote:
>
> On Sun, Oct 22, 2017 at 2:19 PM, Eric Ridge wrote:
>> I'm looking for the status as any concurrent open transaction might see it.
>> For example, if any concurrent transaction might see it as "in prog
Hi all!
Does anyone know of a simple, example Custom Scan Provider implementation
for 9.6+?
I found pg_strom by searching GitHub. Its gpuscan.c looks like maybe it
implements a pattern similar to what I want to do, but there's a lot of
extraneous (to me) stuff to parse through.
I'm kinda surpri
On Tue, Mar 7, 2017 at 6:39 PM Amit Langote
wrote:
>
> Here you go: https://github.com/kaigai/ctidscan
Thanks for the link, Amit! I think that'll get me bootstrapped!
This was proposed originally [1] to go into contrib/, but that didn't
> happen somehow.
>
Too bad. :(
eric
This is about Postgres 9.6...
I have a very simple 1-arg function, in C, that I want to return the ctid
of the record passed in. Example:
CREATE OR REPLACE FUNCTION foo(record) RETURNS tid LANGUAGE c IMMUTABLE
STRICT AS 'my_extension';
Its implementation is simply:
Datum foo(PG_FUNCTION_ARGS)
>
> I suspect the tuple at (0,1) has been the subject of a failed update.
>
Yep.
> Your problem here is that you're mistaking the t_ctid field of a tuple
> header for the tuple's address. It is not that; it's really just garbage
> normally, and is only useful to link forward to the next version
On Sat, Mar 11, 2017 at 2:14 PM Andres Freund wrote:
> On 2017-03-11 04:31:16 +0000, Eric Ridge wrote:
> > Well shoot. That kinda spoils my plans.
>
> I think you should elaborate on what you're trying to achieve -
> otherwise our advice will be affected by the
Hi all!
I've been working on implementing a custom index using the Index Access Method
API and have the need for custom reloptions that are "complex" strings (ie,
also contain non-alphaumerics).
pg_get_indexdef() and pg_dump don't quote the reloption values, making a
restore (or cut-n-paste of
On Fri, Oct 31, 2014 at 6:07 PM, Tom Lane wrote:
> I don't know if/when that will happen as such, but Simon was making noises
> about writing code to treat hash indexes as unlogged automatically, which
> would more or less fix the worst risks. That's not just a special case
> for hash indexes, b
I'm doing some extension development (in C) and have a situation where I
need to examine the target list of a view, but all I have is the view's oid.
An approach that works is (pseudocode):
SPI_connect();
"SELECT ev_action FROM pg_catalog.pg_rewrite WHERE rulename = '_RETURN'
and ev_class=?o
On Wed, Dec 9, 2015 at 4:04 PM Tom Lane wrote:
> Eric Ridge writes:
> > I'm doing some extension development (in C) and have a situation where I
> > need to examine the target list of a view, but all I have is the view's
> oid.
>
> Open the relation and
On Wed, Dec 9, 2015 at 5:07 PM Tom Lane wrote:
>
> FWIW, it's exposed in 9.4 and up. But in older branches you could
> probably just copy it, it's not that big.
>
That's good to know, thanks. I did copy it and it's almost 3x faster than
going through SPI. Thanks again for the pointer.
eric
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
wrote:
> On Mon, Dec 20, 2010 at 03:08:02PM -0500, Robert Haas wrote:
>> The attached patch appears to work correctly on MacOS X. I did check,
>> BTW: getppid() in the attached process returns gdb's pid. Poor!
>
> This appears to be a BSDis
On Tue, Dec 21, 2010 at 2:33 PM, Robert Haas wrote:
> The point of the patch was to improve cases where attaching gdb
> *didn't* work well. Any cases where it was already working for you
> aren't going to be made worse by this.
Okay, great. Thanks for the clarification.
eric
--
Sent via pgsq
On Sat, Apr 16, 2016 at 12:14 PM Tom Lane wrote:
>
> Pushed. I moved the check into DefineIndex, as that's where user-facing
> complaints about indexes generally ought to be.
>
If you're planning on back-patching this, please don't. :) It'll
literally ruin my life.
I've got an extension that
On Wed, Apr 20, 2016 at 9:24 PM Tom Lane wrote:
> > SELECT FROM table WHERE my_func('table', ctid) ==> 'index condition'
>
> Um, why's the ctid important here, or perhaps more directly, what is
> it you're really trying to do?
>
This function is defined as my_func(regclass, tid) and simply
> On May 19, 2015, at 6:59 PM, Jim Nasby wrote:
>
> I find it annoying to have to specifically exclude pg_backend_pid() from
> pg_stat_activity if I'm trying to kill a bunch of backends at once, and I
> can't think of any reason why you'd ever want to call a pg_cancel_* function
> with your ow
On Fri, May 22, 2015 at 4:51 PM Jim Nasby wrote:
> Interesting idea. I suspect that would be even more invasive than
> modifying the functions though...
>
Here's the solution. I can't see how anyone could possibly disagree with
this... ;)
Change the sort order for pg_stat_activity so the curre
I've written an extension that hooks ExecutorStart_hook and
ExecutorEnd_hook. The hooks are assigned in _PG_init() (and the previous
ones saved to static vars) and reset to the previous values in _PG_fini().
Maybe also of interest is the extension library is set in postgresql.conf
as a local_prelo
On Thu, Jun 18, 2015 at 4:42 PM, Andres Freund wrote:
>
>
> How does your _PG_init() actually look like?
static ExecutorStart_hook_type prev_ExecutorStartHook = NULL;
static ExecutorEnd_hook_type prev_ExecutorEndHook = NULL;
void _PG_init(void)
{
prev_ExecutorStartHook = ExecutorStart_hook;
On Thu, Jun 18, 2015 at 5:30 PM, Tom Lane wrote:
>
> If that's broken, then so are most of our contrib modules.
> Certainly none of them have an extra check as suggested by Andres.
I'm putting it in anyways, along with a guard in the actual hook
function to ERROR if prev_hook == my_hook. At leas
On Thu, Jun 18, 2015 at 5:39 PM, Tom Lane wrote:
> BTW, if it didn't occur to you already --- next time you see this,
> you could try examining dfmgr.c's DynamicFileList data structure
> using gdb. That might help illuminate what Postgres thinks it
> loaded and why.
Hmm, okay. I'll not check fo
On Thu, Jun 18, 2015 at 6:04 PM, Tom Lane wrote:
> What we were expecting I guess is that such functions would be declared
> to reference the library underneath $libdir/plugins, not that you'd use
> a symlink.
According to pg_proc.probin, all 32 of my C language functions point
to $libdir/my_ext
On Thu, Jun 18, 2015 at 8:07 PM, Eric Ridge wrote:
>
> According to pg_proc.probin, all 32 of my C language functions point
> to $libdir/my_extension_lib,
That's a damn lie. The deployment server has a number of databases
that have this extension installed and some of them have
Would y'all accept a patch that extended the "SELECT *" syntax to let
you list fields to exclude from the A_Star?
Quite regularly I'll be testing queries via psql and want to see all
the columns from a fairly wide table except maybe a giant text or xml
column. A syntax like:
SELECT * EXCLUD
On Sat, Oct 29, 2011 at 6:35 PM, Stephen Frost wrote:
>> Maybe the SQL spec says something about this and nobody's done the work yet?
>
> I don't know of anything like this in the spec. Also, there would be
> concern about this possibly going against spec, breaking possibly valid
> queries, promo
On Sun, Oct 30, 2011 at 1:51 PM, Eric B. Ridge wrote:
> eric
>
> PROPRIETARY AND COMPANY CONFIDENTIAL COMMUNICATIONS
my bad. Switched email accounts without realizing. :(
eric
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
On Sun, Oct 30, 2011 at 2:54 PM, Robert Haas wrote:
> OTOH, I'm slightly afraid of how much work it would take to implement
> this properly.
I think first, the A_Star node struct will need to be expanded to
include a List of qualified column references to exclude. From there,
the "target_el" ru
On Sun, Oct 30, 2011 at 3:17 PM, Tom Lane wrote:
>
> It's entirely possible that it will get bounced on standards-compliance
> grounds.
And that's a perfectly valid reason to reject it.
> In particular, I don't think it's acceptable to introduce a
> new reserved keyword for this --- that would f
On Sun, Oct 30, 2011 at 3:38 PM, Mark Mielke wrote:
> Stupid question:
>
> Is this just a display thing?
Well, it's a "display thing" as much as any SELECT statement
(especially via psql) is a "display thing". It's more like "I want
all 127 columns, except the giant ::xml column, and I'm too laz
On Sun, Oct 30, 2011 at 4:03 PM, Tom Lane wrote:
> That's just a gut feeling, I've not tried it ... but the proposed
> syntax sure looks a lot like a call to a function named EXCLUDING.
I think what makes it okay is that its new use is only defined to
immediately follow an asterisk in the "target
On Sun, Oct 30, 2011 at 4:43 PM, Darren Duncan wrote:
> SELECT foo.* EXCLUDING foo.x, bar.* EXCLUDING bar.y, baz.z, (a+b) AS c FROM
> ...
> Is that where you're going with this?
Yes. It's basically a modifier to the star that immediately precedes
it. In order to support excluding multiple col
On Sun, Oct 30, 2011 at 3:17 PM, Tom Lane wrote:
> "fails to not break anything else" category.
>From what I've seen watching this list, you're usually right. :)
It looks like it's perfectly okay to write:
SELECT pg_class.* AS foo FROM pg_class;
(with or without the AS)
I don't know what
On Tue, Nov 1, 2011 at 12:03 PM, Stephen Frost wrote:
> Note- I haven't looked at the * production or tried to do anything w/ gram.y
> to
> support this yet, but it's a heck of a lot shorter..
My original thought, that I probably didn't explain too clearly, was
to make the "EXCLUDING (...)" bit
On Tue, Nov 1, 2011 at 12:24 PM, Pavel Stehule wrote:
> some other idea - but only for psql
>
> we can define a special values, that ensure a some necessary
> preexecution alchemy with entered query
>
> \pset star_exclude_names col1, col2, col3
> \pset star_exclude_types xml, bytea, text(unlimited
On Tue, Nov 1, 2011 at 1:33 PM, Pavel Stehule wrote:
>> COPY (SELECT * EXCLUDING (a, b, c) FROM ) TO 'somefile.csv' WITH
>> CSV;
>>
> sorry, I don't accept it. I am able to understand your request for
> adhoc queries. But not for COPY.
I apologize if that example was confusing. I wasn't also su
On Tue, Nov 1, 2011 at 11:47 PM, Tom Lane wrote:
> Doesn't mean anything, I think --- the SQL standard seems to exclude it.
> It's fairly hard to prevent it at the grammar level, since we regard
> "foo.*" as a type of primitive expression, but I suspect it might be a
> good idea for transformTarg
On Sep 21, 2003, at 3:11 PM, Tom Lane wrote:
Great. I was afraid it might have been new with 10.2.
Also, 7.3.4 doesn't link on the OS X 10.3 beta's. Apparently tas is
never being defined. I could never fix this. In the list archives I
found all sorts of references to tas()/TAS and older ve
On Sep 21, 2003, at 3:11 PM, Tom Lane wrote:
BTW, is anyone interested in looking into whether we can be made to
build without using either flag? I tried it and saw a number of
I did this... before I knew about -no-cpp-precomp. :( I read all
about -traditional-cpp in the gcc man page, but cou
On Sep 21, 2003, at 9:03 PM, Tom Lane wrote:
Eric Ridge <[EMAIL PROTECTED]> writes:
any ideas here? 7.3.2 and 7.4beta3 compile just fine (I noticed that
7.4 has something more cross-platform for tas). What happened in
7.3.4
that broke it?
That makes no sense at all --- AFAICT there we
I don't have the original thread in my inbox anymore, so for reference:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF
-8&selm=20129.1074484755%40sss.pgh.pa.us
Tom Lane last said:
I have committed a patch into CVS HEAD --- give it a try.
It took me awhile, but I finally got around to
create table test (stuff varchar(255), more_stuff text);
create index idxstuff on test using xapian (stuff);
create index idxmore_stuff on test using xapian (more_stuff);
insert into test (stuff, more_stuff) values ('this is stuff', 'this is
more stuff')
On Dec 26, 2003, at 3:22 PM, Tom Lane wrote:
3) How does one get the $PGDATA directory?
DataDir. Why should you care? An index AM that wants to know this is
probably broken IMHO; it's certainly trying to do something that's
outside the charter of index AMs, and is likely to cause lots of
headache
On Dec 26, 2003, at 4:04 PM, Tom Lane wrote:
Eric Ridge <[EMAIL PROTECTED]> writes:
Xapian has it's own storage subsystem, and that's what I'm using to
store the index... not using anything internal to postgres (although
this could change).
I would say you have absolutely zer
On Jan 2, 2004, at 4:54 PM, Alvaro Herrera wrote:
I think your approach is too ugly. You will have tons of problems the
minute you start thinking about concurrency (unless you want to allow
only a single user accessing the index)
It might be ugly, but it's very fast. Surprisingly fast, actually.
Thanks to everyone that provided input about this idea. After taking
everything into consideration and talking with Olly Betts from the
Xapian project, what I'm going to do is implement a btree that supports
multiple roots and an "tag" value of arbitrary length for each item in
the tree. Then
I've created a stub AM that literally does nothing. It indexes
nothing. It scans for nothing. Nadda. It does just enough work to
specify return values that prevent PG from dumping core.
What I've found is that this stub AM, compiled with the same options as
postgres itself (-O2 -fno-strict-
On Jan 17, 2004, at 10:22 PM, Tom Lane wrote:
Eric Ridge <[EMAIL PROTECTED]> writes:
I've created a stub AM that literally does nothing.
It's not possible for an index AM to "do nothing", at least not for an
indexscan. It has to return tuple pointers. What are you do
On Jan 17, 2004, at 10:22 PM, Tom Lane wrote:
Eric Ridge <[EMAIL PROTECTED]> writes:
I've created a stub AM that literally does nothing.
It's not possible for an index AM to "do nothing", at least not for an
indexscan. It has to return tuple pointers. What are you doi
On Jan 17, 2004, at 11:27 PM, Tom Lane wrote:
Eric Ridge <[EMAIL PROTECTED]> writes:
costestimate: {
PG_RETURN_VOID();
}
This at least needs to set some values into the output parameters ---
zeroes are okay, not setting them at all isn't. I'm surprised the
planner does
On Jan 17, 2004, at 11:33 PM, Tom Lane wrote:
The difference between "total runtime" and the top plan node's runtime
has to represent plan startup/shutdown time. I'm suspicious that your
stubs are somehow not initializing something, though on first glance I
do not see what.
I can't see anything ei
On Jan 18, 2004, at 1:34 AM, Christopher Kings-Lynne wrote:
Theory B would be that there's some huge overhead in calling
non-built-in
functions on your platform. We do know that looking up a "C"
function is
significantly more expensive than looking up a "builtin" function,
but
there should onl
On Jan 30, 2004, at 6:31 AM, Bruce Momjian wrote:
I like the idea of building in-memory bitmapped indexes.
Me too (FWIW)! This thread is really interesting as the whole idea
would help to solve the biggest issue with my (currently stalled)
project to integrate Xapian as a full-text search engin
55 matches
Mail list logo
