If you do:
# DO $do$ 1; $do$ LANGUAGE plperlu;
# DO $do$ 1; $do$ LANGUAGE plperl;
You get a segfault as we try to SvREFCNT_dec(...); for the wrong
interpreter. To fix push down the restore_context() so that we do the
above on the correct perl interpreter.
--
*** a/src/pl/plperl/plperl.c
--- b/s
Addressing TODO item "Distinguish between unique indexes and unique
constraints in \d+" for psql, and picking up from thread:
http://archives.postgresql.org/message-id/8780.1271187...@sss.pgh.pa.us
Attached is a simple patch which clarifies unique constraints with
"UNIQUE CONSTRAINT" in psql's \d+
Here's a patch to add enable_material, per previous discussion. I
still think we should add enable_joinremoval also, but there wasn't a
clear consensus for that.
I'd appreciate it if someone could check this over for sanity - like,
did I get all the places where materialize nodes can be created?
On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs wrote:
> On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote:
>
>> > I will change the error message.
>>
>> I gave a good deal of thought to trying to figure out a cleaner
>> solution to this problem than just changing the error message and
>> failed.
Simon Riggs writes:
> What I'm not clear on is why you've used a spinlock everywhere when only
> weak-memory thang CPUs are a problem. Why not have a weak-memory-protect
> macro that does does nada when the hardware already protects us? (i.e. a
> spinlock only for the hardware that needs it).
Wel
On Sat, 2010-04-17 at 16:48 -0400, Tom Lane wrote:
> > We search the array between tail and head. If the head moves by integer
> > overwrite just as already happens for xid assignment, then we would use
> > the new head for the search. The code is careful to fetch only once.
>
> ... but this will
On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote:
> > I will change the error message.
>
> I gave a good deal of thought to trying to figure out a cleaner
> solution to this problem than just changing the error message and
> failed. So let's change the error message. Of course I'm not quite
On Wed, Apr 14, 2010 at 7:52 AM, Simon Riggs wrote:
> On Wed, 2010-04-14 at 07:07 -0400, Robert Haas wrote:
>> On Wed, Apr 14, 2010 at 4:21 AM, Simon Riggs wrote:
>> > On Sat, 2010-04-10 at 09:02 -0400, Robert Haas wrote:
>> >
>> >> So this can fail in either of two ways
>> >
>> > If I understand
Simon Riggs writes:
> On Sat, 2010-04-17 at 15:45 -0400, Tom Lane wrote:
>> How do you know that just adding items at the right will produce a
>> sorted array?
> Xids don't arrive in sequence, but "known assigned xids" are added in
> sequence because we infer the existence of the intermediate xid
On Sat, 2010-04-17 at 15:45 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sat, 2010-04-17 at 11:13 -0400, Tom Lane wrote:
> >> It'd be cheaper anyway to sort and search the
> >> array using plain <, so why are you so eager to use
> >> TransactionIdFollows?
>
> > The array grows to the right
Simon Riggs writes:
> On Sat, 2010-04-17 at 11:13 -0400, Tom Lane wrote:
>> It'd be cheaper anyway to sort and search the
>> array using plain <, so why are you so eager to use
>> TransactionIdFollows?
> The array grows to the right and is laid out one xid per element,
> resulting in a sequence o
On Sat, 2010-04-17 at 11:13 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > AFAICS the example you give isn't correct.
>
> > We would lay out the values like this
>
> > W-3 W-2 W-1 W 3 4 5
>
> > where W is the wrap value
>
> Stop right there, you're already failing to think clearly. There is
Dave Page wrote:
On Sat, Apr 17, 2010 at 4:11 PM, Robert Haas wrote:
On Sat, Apr 17, 2010 at 11:01 AM, Tom Lane wrote:
somasekhar Ramadurgam writes:
I'd like to add you to my professional network on LinkedIn.
One reason I will never, ever join LinkedIn is that th
On Sat, Apr 17, 2010 at 4:11 PM, Robert Haas wrote:
> On Sat, Apr 17, 2010 at 11:01 AM, Tom Lane wrote:
>> somasekhar Ramadurgam writes:
>>> I'd like to add you to my professional network on LinkedIn.
>>
>>
>> One reason I will never, ever join LinkedIn is that they encourage
>> their members t
On Sat, Apr 17, 2010 at 11:13 AM, Tom Lane wrote:
> Simon Riggs writes:
>> AFAICS the example you give isn't correct.
>
>> We would lay out the values like this
>
>> W-3 W-2 W-1 W 3 4 5
>
>> where W is the wrap value
>
> Stop right there, you're already failing to think clearly. There is no
> un
Simon Riggs writes:
> AFAICS the example you give isn't correct.
> We would lay out the values like this
> W-3 W-2 W-1 W 3 4 5
> where W is the wrap value
Stop right there, you're already failing to think clearly. There is no
unique "wrap value", all values act the same in circular XID space.
On Sat, Apr 17, 2010 at 11:01 AM, Tom Lane wrote:
> somasekhar Ramadurgam writes:
>> I'd like to add you to my professional network on LinkedIn.
>
>
> One reason I will never, ever join LinkedIn is that they encourage
> their members to spam the world like this. If I were running this
> mailing
somasekhar Ramadurgam writes:
> I'd like to add you to my professional network on LinkedIn.
One reason I will never, ever join LinkedIn is that they encourage
their members to spam the world like this. If I were running this
mailing list, messages like this one would be sufficient grounds for
g
On Fri, 2010-04-16 at 11:10 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2010-04-16 at 10:39 -0400, Tom Lane wrote:
> >> I think you're outsmarting yourself there. A binary search will in fact
> >> *not work* with circular xid comparison (this is exactly why there's no
> >> btree opcl
Bjorn Munch wrote:
I will have a look into it.
as of right now, I suspect what I need are the following files from a
recent Solaris 64bit build...
include/server/pg_config.h
lib/64/pgxs/src/Makefile.global
there are a few more files that could be involved, but AFAIK, they are
inva
LinkedIn
I'd like to add you to my professional network on LinkedIn.
- somasekhar
somasekhar Ramadurgam
Student at Indian Institute of Technology, Bombay
Mumbai Area, India
Confirm that you know somasekhar Ramadurgam
https://www.linkedin.com/e/isd/1231429279/vRUTcgAL/
-
21 matches
Mail list logo
