Simon Riggs wrote:
Recovery does *not* take the same locks as the original statements on
the master took. For example, the WAL record for an INSERT just makes
its changes without acquiring locks. This is OK as long as we only allow
read-only users to acquire AccessShareLocks. If we allowed
Simon Riggs wrote:
Recovery does *not* take the same locks as the original statements on
the master took. For example, the WAL record for an INSERT just makes
its changes without acquiring locks. This is OK as long as we only allow
read-only users to acquire AccessShareLocks. If we
Here's the rest of the review, as far as I've taken it given the
problems with the code.
The patch applied cleanly and includes regression tests but not docs.
Small nitpicks: there are some comments not updated (e.g. the
big one at the start of eval_windowaggregates). A couple of lines are
Tatsuo Ishii wrote:
Sorry for confusion. My example is under normal PostgreSQL, not under
HS enabled.
You get the same result in standby:
postgres=# begin;
BEGIN
postgres=# prepare a(int) as insert into foo values($1);
PREPARE
postgres=# SELECT * FROM pg_locks;
locktype │ database │
On ons, 2009-11-18 at 09:48 -0800, Joshua D. Drake wrote:
Although I wonder if longer
term (2.x is going to be support a long time) we will end up with
frustration within the single source file trying to keep things
straight.
There are five million Python modules with C code out there with
On ons, 2009-11-18 at 08:43 -0800, Nathan Boley wrote:
Again, I'm only one user. But so far I haven't seen anyone else speak
up here, and clearly accepting this for inclusion will need nontrivial
convincing.
Well, FWIW, I am excited about better type integration.
Let's clarify, as there
On ons, 2009-11-18 at 11:32 -0800, Nathan Boley wrote:
I took a cursory look at this patch and, while the logic seems sound
and roughly in line with the suggested python porting procedure, I'm
not quite certain what this implies for potential future patches.
For instance, if I wanted to
ts_headline calls ts_lexize equivalent to break the text. Off course
there is algorithm to process the tokens and generate the headline. I
would be really surprised if the algorithm to generate the headline is
somehow dependent on language (as it only processes the tokens). So Oleg
is right
On Wed, 18 Nov 2009 22:12:18 -0500 Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
(4) drop *old* notifications if the queue is full.
Since everyone has made the point that LISTEN is not meant to be a full
queueing system, I have no problem dropping notifications LRU-style.
NO,
On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
There will now be a nonzero chance
of transactions failing at commit because of queue full. If the
chance is large this will be an issue. (Is it sane to wait for
the queue to be drained?)
Exactly. The whole idea of putting
On Thu, Nov 19, 2009 at 1:51 PM, Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
And in addition i don't like the idea of having the sender sitting
around until there's room for more messages in the queue, because some
very old backends didn't remove the stuff from the same.
The only
Hi,
my question is that what platform were these
functions developed and tested?
We have come across a value that fails a NOT NULL
constraint upon INSERT under HP-UX/IA64, but not
under x86-64 Linux. The value in question is
1.9998 assigned to a double variable.
Under HP-UX/IA64,
2009/11/19 Andrew Gierth and...@tao11.riddles.org.uk:
Here's the rest of the review, as far as I've taken it given the
problems with the code.
The patch applied cleanly and includes regression tests but not docs.
Small nitpicks: there are some comments not updated (e.g. the
big one at the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
(4) drop *old* notifications if the queue is full.
Since everyone has made the point that LISTEN is not meant
On Wed, Nov 18, 2009 at 11:18 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Kevin == Kevin Grittner kevin.gritt...@wicourts.gov writes:
If he meant (A), then you store the event as:
(ts,tz) = (timestamp '2010-07-27 10:30:00',
'Chile/Santiago')
If he meant (B), then you store
Scott Bailey wrote:
I agree that the syntax of XMLTABLE is odd. But not demonstrably worse
than xpathtable.
That's not saying much. I dislike both. Why the SQL committee feels the
need to invent arcane special case grammar rules is beyond me. I
understand why the author of xpathtable
Joachim Wieland wrote:
On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, did we discuss the issue of 2PC transactions versus notify?
The current behavior of 2PC with notify is pretty cheesy and will
become more so if we make this change --- you aren't really
guaranteed
Heikki Linnakangas wrote:
Joachim Wieland wrote:
On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yes, I have been thinking about that also. So what should happen
when you prepare a transaction that has sent a NOTIFY before?
From the user's point of view, nothing should
On Thu, Nov 19, 2009 at 12:03 AM, Scott Bailey arta...@comcast.net wrote:
The nice thing about XMLTABLE is that it adds xquery support. I think the
majority of xquery engines seem to be written in Java. XQuilla is C++. I'm
not sure if our licensing is compatible, but it I would love the irony
Hi,
Robert Haas wrote:
Settling on a syntax, and an internal representation for that syntax,
I've been under the impression that this was only about syntax. What are
the internal additions?
Generally speaking, I'd agree with Simon or even vote for doing the
internals first and add the
Robert Haas wrote:
On Thu, Nov 19, 2009 at 12:03 AM, Scott Bailey arta...@comcast.net wrote:
The nice thing about XMLTABLE is that it adds xquery support. I think the
majority of xquery engines seem to be written in Java. XQuilla is C++. I'm
not sure if our licensing is compatible, but it
Albe Laurenz laurenz.a...@wien.gv.at writes:
I did not know that contrib modules get translated too, else I would
have thrown the error messages there.
I'm not sure whether contrib is currently covered by the translation
teams, but it could someday be. In any case, an inadequate error
message
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tatsuo Ishii wrote:
Sorry for confusion. My example is under normal PostgreSQL, not under
HS enabled.
You get the same result in standby:
AFAICT Tatsuo's example just shows that we might wish to add a check
for read-only
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tatsuo Ishii wrote:
Sorry for confusion. My example is under normal PostgreSQL, not under
HS enabled.
You get the same result in standby:
AFAICT Tatsuo's example just shows that we might wish to add a check
Hi,
pg_restore --help gives this message for the --no-tablespaces parameter:
--no-tablespaces do not dump tablespace assignments
The message should say restore and not dump. You'll find a patch attached
that fixes this issue.
Thanks.
Regards.
--
Guillaume.
Wojciech Knapik webmas...@wolniartysci.pl writes:
Tom Lane wrote:
I tried to duplicate this test, but got no further than here:
ERROR: syntax error
CONTEXT: line 174 of configuration file
/home/tgl/testversion/share/postgresql/tsearch_data/polish.affix: L E C
On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner mar...@bluegap.ch wrote:
Hi,
Robert Haas wrote:
Settling on a syntax, and an internal representation for that syntax,
I've been under the impression that this was only about syntax. What are the
internal additions?
I haven't looked at it in
Florian G. Pflug wrote:
Heikki Linnakangas wrote:
At a quick glance, it doesn't seem hard to support 2PC. Messages should
be put to the queue at prepare, as just before normal commit, but the
backends won't see them until they see that the XID has committed.
Yeah, but if the server is
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
A better approach is to do something similar to what we do now: at
prepare, just store the notifications in the state file like we do
already. In notify_twophase_postcommit(), copy the messages to the
shared queue. Although it's
On Thu, 19 Nov 2009 14:23:57 +0100 Joachim Wieland wrote:
On Thu, Nov 19, 2009 at 1:51 PM, Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
And in addition i don't like the idea of having the sender sitting
around until there's room for more messages in the queue, because some
very
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
A better approach is to do something similar to what we do now: at
prepare, just store the notifications in the state file like we do
already. In notify_twophase_postcommit(), copy the messages to the
shared queue.
Florian G. Pflug f...@phlo.org writes:
Tom Lane wrote:
This is still ignoring the complaint: you are creating a clear risk
that COMMIT PREPARED will fail.
I'd see no problem with COMMIT PREPARED failing, as long as it was
possible to retry the COMMIT PREPARED at a later time. There surely
Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 18, 2009 at 11:18 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Kevin == Kevin Grittner kevin.gritt...@wicourts.gov
writes:
If he meant (A), then you store the event as:
(ts,tz) = (timestamp '2010-07-27 10:30:00',
On Nov 19, 2009, at 3:12 AM, Peter Eisentraut wrote:
The other approach, which is what James Pye's
new implementation proposes (as I understand it), is to convert
PostgreSQL types into specially made Python objects, such as
Postgres.types.record or Postgres.types.timestamp.
Convert is not a
Tom Lane wrote:
Florian G. Pflug f...@phlo.org writes:
Tom Lane wrote:
This is still ignoring the complaint: you are creating a clear
risk that COMMIT PREPARED will fail.
I'd see no problem with COMMIT PREPARED failing, as long as it
was possible to retry the COMMIT PREPARED at a later
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
A better approach is to do something similar to what we do now: at
prepare, just store the notifications in the state file like we do
already. In notify_twophase_postcommit(), copy the messages to the
shared queue.
On ons, 2009-11-18 at 12:28 -0500, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
Yes. That's exactly what I was complaining about upthread. I'm not
a Python user, but from what I can gather of the 2-to-3 changes,
having
On ons, 2009-11-18 at 13:36 -0700, James Pye wrote:
On Nov 18, 2009, at 8:37 AM, Peter Eisentraut wrote:
The question is whether it helps the user, not the implementer.
Sure, but do you have a patch waiting to implement tracebacks?
I'd argue the reason it's never been done is due to the
Peter Eisentraut pete...@gmx.net writes:
By the way, it occurred to me that having two different versions of
libpython loaded into the same process is probably not going to work
sanely.
Why not? There's no way they'd even know about each other. We tell
the loader not to make the symbols
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
[ TRIGGER WHEN patch ]
I'm starting to work this over now, and I've found one rather serious
omission: FreeTriggerDesc doesn't free the expression tree. This means
that trigger WHEN clauses will leak memory in CacheMemoryContext any
time
Boszormenyi Zoltan írta:
Hi,
my question is that what platform were these
functions developed and tested?
We have come across a value that fails a NOT NULL
constraint upon INSERT under HP-UX/IA64, but not
under x86-64 Linux. The value in question is
1.9998 assigned to a double
Boszormenyi Zoltan z...@cybertec.at writes:
for (; length 0 ptr[--length] == 0xff;);
I suspect that GCC does the --length after checking
length 0 and before checking the ptr[...] == 0xff,
but HP CC does it before checking length 0.
If it does, that is *unquestionably* a bug in
Tom Lane wrote:
Boszormenyi Zoltan z...@cybertec.at writes:
for (; length 0 ptr[--length] == 0xff;);
I suspect that GCC does the --length after checking
length 0 and before checking the ptr[...] == 0xff,
but HP CC does it before checking length 0.
If it does,
On Nov 19, 2009, at 11:32 AM, Peter Eisentraut wrote:
But you wouldn't, for example, get away with breaking SQL (or even
improving it incompatibly) to facilitate a better elog.
This doesn't fit the situation.
I'm not breaking PL/Python. I'm trying to add PL/Python3. =)
I think of a PL/Python
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
for (; length 0 ptr[--length] == 0xff;);
I suspect that GCC does the --length after checking
length 0 and before checking the ptr[...] == 0xff,
but HP CC does it before checking length 0.
If it does,
Boszormenyi Zoltan írta:
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
for (; length 0 ptr[--length] == 0xff;);
I suspect that GCC does the --length after checking
length 0 and before checking the ptr[...] == 0xff,
but HP CC does
Boszormenyi Zoltan wrote:
Is it *really* a bug? I recalled a comment from my C teacher
in '92 or '93 about this exact issue, that the prefix/postfix
increment/decrement operators are executed in the
statement in an implementation-defined order,
Not if they come after a short-circuit
Andrew Dunstan and...@dunslane.net writes:
Boszormenyi Zoltan wrote:
Is it *really* a bug? I recalled a comment from my C teacher
in '92 or '93 about this exact issue, that the prefix/postfix
increment/decrement operators are executed in the
statement in an implementation-defined order,
Fujii Masao wrote:
On Tue, Nov 3, 2009 at 12:33 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
BTW, are you going to submit another WIP patch for next commitfest?
Well, Heikki was going to keep working on this
Tom Lane írta:
Andrew Dunstan and...@dunslane.net writes:
Boszormenyi Zoltan wrote:
Is it *really* a bug? I recalled a comment from my C teacher
in '92 or '93 about this exact issue, that the prefix/postfix
increment/decrement operators are executed in the
statement in an
Hi,
Is it just me or the union test case fails in CVS head?
manu
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
g...@turnstep.com (Greg Sabino Mullane) writes:
BTW, did we discuss the issue of 2PC transactions versus notify?
The current behavior of 2PC with notify is pretty cheesy and will
become more so if we make this change --- you aren't really
guaranteed that the notify will happen, even though the
Tom Lane wrote:
*SNIP*
So about 55% of the time is going into affix pattern matching.
I wonder whether that couldn't be made faster. A lot of the cycles
are spent on coping with variable-length characters --- perhaps the
ispell code should convert to wchar representation before doing this?
Emmanuel Cecchet wrote:
Hi,
Is it just me or the union test case fails in CVS head?
The buildfarm is pretty much all green:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
So it looks like it's you :-)
cheers
andrew
--
Sent via pgsql-hackers mailing list
On fre, 2009-11-13 at 18:46 +0300, Teodor Sigaev wrote:
CREATE OR REPLACE FUNCTION incr(stuff int[]) RETURNS int[] AS $$
for x in stuff:
yield x+1
$$
LANGUAGE 'plpythonu';
# select incr(ARRAY[1,2,3]);
ERROR: invalid memory alloc request size 18446744073709551608
CONTEXT: while
On Thu, Nov 19, 2009 at 6:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, ignoring 2PC for a moment, I think the patch suffers from a little
race condition:
Session 1: BEGIN;
Session 1: INSERT INTO foo ..;
Session 1: NOTIFY 'foo';
Session 1: COMMIT -- commit begins
On tor, 2009-11-19 at 16:47 +0100, Guillaume Lelarge wrote:
pg_restore --help gives this message for the --no-tablespaces parameter:
--no-tablespaces do not dump tablespace assignments
The message should say restore and not dump. You'll find a patch attached
that fixes this
Le jeudi 19 novembre 2009 à 23:05:16, Peter Eisentraut a écrit :
On tor, 2009-11-19 at 16:47 +0100, Guillaume Lelarge wrote:
pg_restore --help gives this message for the --no-tablespaces
parameter:
--no-tablespaces do not dump tablespace assignments
The message should say
Kevin == Kevin Grittner kevin.gritt...@wicourts.gov writes:
For example, if you have a type T which incorporates a timestamp
and a timezone, what semantics does the T = T operator have? What
semantics apply if the definitions of timezones change?
Kevin I'd rather sort that out once and
On ons, 2009-11-18 at 13:52 +0900, Itagaki Takahiro wrote:
partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
Oops, it should be palloc. Thanks.
A very low-level comment:
1) Please stop casting the results of palloc and malloc. We are not
writing C++ here.
2) I would
Andrew Dunstan and...@dunslane.net writes:
Emmanuel Cecchet wrote:
Is it just me or the union test case fails in CVS head?
The buildfarm is pretty much all green:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
So it looks like it's you :-)
When in doubt, try make distclean and a full
On Wed, Nov 18, 2009 at 12:38:00PM +0200, Alexey Klyukin wrote:
Yes, current_call_data can't be allocate in the SPI memory context, since
it's used to extract the result after SPI_finish is called, although it
doesn't lead to problems here since no result is returned. Anyway, I'd move
Does anyone have a link for pl/ruby? I found a link under the postgres
documentation and found a web site from there talking about the code.
However when I clicked on the link to download it I noticed ftp wouldn't
respond on their site.
Thanks!
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Emmanuel Cecchet wrote:
Is it just me or the union test case fails in CVS head?
The buildfarm is pretty much all green:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
So it looks like it's you :-)
When
2009/11/16 Peter Eisentraut pete...@gmx.net:
On mån, 2009-11-16 at 10:05 -0500, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Magnus Hagander wrote:
On Mon, Nov 16, 2009 at 08:29, David Fetter da...@fetter.org wrote:
On Mon, Nov 16, 2009 at 06:56:54AM
Is there any actual reason why we are building without thread safety
by default on most platforms? Seems I get asked that every time
somebody forgets to add a --enable-thread-safety. Wouldn't it be
more logical to have that be the default, and provide
--disable-thread-safety if there are platforms
Hi
It seems that pl/pgsql ignores the DEFAULT value of domains for local
variables. With the following definitions in place
create domain myint as int default 0;
create or replace function myint() returns myint as $body$
declare
v_result myint;
begin
return v_result;
end;
$body$ language
On 11/15/09 11:07 PM, Heikki Linnakangas wrote:
- When replaying b-tree deletions, we currently wait out/cancel all
running (read-only) transactions. We take the ultra-conservative stance
because we don't know how recent the tuples being deleted are. If we
could store a better estimate for
On Fri, 2009-11-20 at 11:14 +0900, Josh Berkus wrote:
On 11/15/09 11:07 PM, Heikki Linnakangas wrote:
- When replaying b-tree deletions, we currently wait out/cancel all
running (read-only) transactions. We take the ultra-conservative stance
because we don't know how recent the tuples being
Hi
While trying to come up with a patch to handle domain DEFAULTs in
plpgsql I've stumbled across the following behavior regarding domain
DEFAULTs and prepared statements.
session 1: create domain myint as int default 0 ;
session 1: create table mytable (i myint) ;
session 2: prepare ins as
Without an order by, the order is not defined. The answers are the
same but the test gives a false failure because of the lack of
ordering.
Regards,
Ken
On Thu, Nov 19, 2009 at 07:54:30PM -0500, Emmanuel Cecchet wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Emmanuel
Then I guess that we need to fix the test.
Emmanuel
Kenneth Marshall wrote:
Without an order by, the order is not defined. The answers are the
same but the test gives a false failure because of the lack of
ordering.
Regards,
Ken
On Thu, Nov 19, 2009 at 07:54:30PM -0500, Emmanuel Cecchet
Joshua D. Drake wrote:
On Fri, 2009-11-20 at 11:14 +0900, Josh Berkus wrote:
On 11/15/09 11:07 PM, Heikki Linnakangas wrote:
- When replaying b-tree deletions, we currently wait out/cancel all
running (read-only) transactions. We take the ultra-conservative stance
because we don't
On Wed, Nov 18, 2009 at 9:00 AM, Jeff Davis pg...@j-davis.com wrote:
I'm in Tokyo right now, so please excuse my abbreviated reply.
On Tue, 2009-11-17 at 23:13 -0500, Robert Haas wrote:
Forgive me if this is discussed before, but why does this store the
strategy numbers of the relevant
On Wed, Nov 18, 2009 at 9:21 AM, Josh Berkus j...@agliodbs.com wrote:
All,
FWIW, I'm doing a redesign of a client's production web application
right now. I was able, by combining OEC and the Period type from
pgfoundry, to make a set of constraints for declaratively asserting in a
sports
On 11/5/2009 8:10 PM, Robert Haas wrote:
On Thu, Nov 5, 2009 at 4:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
Since the return value is ignored anyway, why do we have to complain
if it's left out altogether? Granted, it's easy to
On 11/5/2009 4:33 PM, Tom Lane wrote:
So I was testing the next step of plpgsql modification, namely actually
letting the parser hooks do something, and it promptly blew up in
trigger functions, like so:
+ ERROR: OLD used in query that is not in a rule
+ LINE 1: SELECT OLD
+ ^
RObert,
I guess I'm going to have to vote -1 on this proposal. I code see
inventing a pgsql-specific SQLSTATE value for exclusion constraints,
since they will be a pgsql-specific extension, but reusing the unique
key violation value seems misleading. I admit it may help in a
limited number
Hi,
partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
1) Please stop casting the results of palloc and malloc. We are not
writing C++ here.
I thought it was/is a good C programming practice to typecast (void *)
always to the returning structure type!!
Regards,
Nikhils
Kenneth Marshall k...@rice.edu writes:
Without an order by, the order is not defined.
Yeah, but with the same data and the same software it should generally
give the same result; as evidenced by the fact that these same
regression tests have worked for most people for years. There's
something
On fre, 2009-11-20 at 11:14 +0530, Nikhil Sontakke wrote:
Hi,
partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
1) Please stop casting the results of palloc and malloc. We are not
writing C++ here.
I thought it was/is a good C programming practice to typecast
On Thu, 2009-11-19 at 10:13 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Recovery does *not* take the same locks as the original statements on
the master took. For example, the WAL record for an INSERT just makes
its changes without acquiring locks. This is OK as long as we only
On Thu, 2009-11-19 at 17:15 +0900, Tatsuo Ishii wrote:
Simon Riggs wrote:
Recovery does *not* take the same locks as the original statements on
the master took. For example, the WAL record for an INSERT just makes
its changes without acquiring locks. This is OK as long as we only allow
On tor, 2009-11-19 at 13:43 -0500, Tom Lane wrote:
But in any case, my main concern here is that I don't want to have
to predetermine which python version a user of Red Hat/Fedora will
have to use. If they can only use one at a time, that's still a
good bit better than not having a choice at
Jan Wieck janwi...@yahoo.com writes:
But this brings up another point about the recent discussion of what
RENAME is good for. Removing RENAME may conflict with using OLD/NEW in
UPDATE ... RETURNING. No?
Um ... not sure why. Specific example please?
regards, tom lane
Simon Riggs wrote:
On Thu, 2009-11-19 at 17:15 +0900, Tatsuo Ishii wrote:
Simon Riggs wrote:
Recovery does *not* take the same locks as the original statements on
the master took. For example, the WAL record for an INSERT just makes
its changes without acquiring locks. This is OK as long as we
Nikhil Sontakke nikhil.sonta...@enterprisedb.com writes:
partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
1) Please stop casting the results of palloc and malloc. We are not
writing C++ here.
I thought it was/is a good C programming practice to typecast (void *)
always
Joshua D. Drake wrote:
On Fri, 2009-11-20 at 11:14 +0900, Josh Berkus wrote:
On 11/15/09 11:07 PM, Heikki Linnakangas wrote:
- When replaying b-tree deletions, we currently wait out/cancel all
running (read-only) transactions. We take the ultra-conservative stance
because we don't know how
On Fri, Nov 20, 2009 at 11:14 AM, Josh Berkus j...@agliodbs.com wrote:
On 11/15/09 11:07 PM, Heikki Linnakangas wrote:
- When replaying b-tree deletions, we currently wait out/cancel all
running (read-only) transactions. We take the ultra-conservative stance
because we don't know how recent
On 11/20/2009 1:12 AM, Tom Lane wrote:
Jan Wieck janwi...@yahoo.com writes:
But this brings up another point about the recent discussion of what
RENAME is good for. Removing RENAME may conflict with using OLD/NEW in
UPDATE ... RETURNING. No?
Um ... not sure why. Specific example please?
On Fri, Nov 20, 2009 at 2:58 AM, Andrew Dunstan and...@dunslane.net wrote:
Right. The major use I was hoping for from HS was exactly to be able to run
long-running queries. In once case I am thinking of we have moved the
business intelligence uses off the OLTP server onto a londiste replica,
Joachim Wieland wrote:
The example you brought up fails if
Session 2 disregards the notifications based on the current set of
channels that it is listening to at this point.
Right. Session 2 might not be listening at all yet.
If I understand you
correctly what you are suggesting is to not
Peter Eisentraut pete...@gmx.net writes:
2) I would prefer that you apply sizeof on the variable, not on the
type. That way, the expression is independent of any type changes of
the variable, and can be reviewed without having to scroll around for
the variable definition.
FWIW, I think the
On Fri, 2009-11-20 at 11:14 +0900, Josh Berkus wrote:
On 11/15/09 11:07 PM, Heikki Linnakangas wrote:
- When replaying b-tree deletions, we currently wait out/cancel all
running (read-only) transactions. We take the ultra-conservative stance
because we don't know how recent the tuples being
On Fri, 2009-11-20 at 06:47 +, Greg Stark wrote:
On Fri, Nov 20, 2009 at 2:58 AM, Andrew Dunstan and...@dunslane.net wrote:
Right. The major use I was hoping for from HS was exactly to be able to run
long-running queries. In once case I am thinking of we have moved the
business
On tor, 2009-11-19 at 13:12 -0700, James Pye wrote:
I think of a PL/Python function as a Python script file stored
in the database.
For Python, I think that's a mistake. Python scripts are independent
applications.
Is there any precedent for the sort of behavior that you are
On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote:
Is there any actual reason why we are building without thread safety
by default on most platforms?
Consistent defaults on all platforms?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote:
On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner mar...@bluegap.ch wrote:
Hi,
Robert Haas wrote:
Settling on a syntax, and an internal representation for that syntax,
I've been under the impression that this was only about syntax.
Simon Riggs wrote:
On Fri, 2009-11-20 at 06:47 +, Greg Stark wrote:
I missed the original discussion of this problem, do you happen to
remember the subject or url for the details?
December 2008; hackers; you, me and Heikki.
Yep:
2009/11/20 Peter Eisentraut pete...@gmx.net:
On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote:
Is there any actual reason why we are building without thread safety
by default on most platforms?
Consistent defaults on all platforms?
So why do we have largefile enabled by default? And
1 - 100 of 102 matches
Mail list logo
