On 3 August 2011 04:40, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Dean Rasheed's message of sáb jul 30 18:40:46 -0400 2011:
Looks pretty good to me (not too dirty). I suppose given that the
parser transforms AT_ColumnConstraint into one of the existing command
subtypes,
I found that in previous version of patch I missed PageSetLSN
and PageSetTLI, but huge amount of WAL is still here. Also I found that huge
amount of WAL appears only with -O2. With -O0 amount of WAL is ok, but
messages FATAL: xlog flush request BFF11148/809A600 is not satisfied ---
flushed only
On 3 August 2011 00:52, Peter Geoghegan pe...@2ndquadrant.com wrote:
Now, the only warning that remains is that same
Correction - there are actually 3 additional warnings like this in repl_gram.c:
/home/peter/build/Release/bin/clang -O2 -Wall -Wmissing-prototypes
-Wpointer-arith
On Aug3, 2011, at 04:54 , Robert Haas wrote:
On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Would you feel comfortable with a patch which threw an error on
the DELETE case, as it does on the UPDATE case?
Yes, though with a little additional twist. The
Attached patch removes the tautologolical part of an evaluated
expression, fixing the problem flagged by this quite valid warning.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
diff --git a/src/interfaces/libpq/fe-exec.c
On 03.08.2011 12:25, Peter Geoghegan wrote:
Attached patch removes the tautologolical part of an evaluated
expression, fixing the problem flagged by this quite valid warning.
The check is only tautological if the compiler implements enums as
unsigned integers. Whether enums are signed or not
On 3 August 2011 10:34, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The check is only tautological if the compiler implements enums as unsigned
integers. Whether enums are signed or not is implementation-dependent.
Perhaps cast status to unsigned or signed explicitly before
On 03.08.2011 13:05, Peter Geoghegan wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
C99 says:
Each enumerated type shall be compatible with char, a
On 3 August 2011 11:05, Peter Geoghegan pe...@2ndquadrant.com wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
It actually gives leeway to implement the
On 03.08.2011 14:13, Peter Geoghegan wrote:
On 3 August 2011 11:05, Peter Geogheganpe...@2ndquadrant.com wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
On 3 August 2011 12:19, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Right, but the purpose of that check is to defend from programmer error. If
the programmer screws up and calls PQresStatus(-1), we want to give an
error, not crash. If you assume that the programmer will only
On Mon, Aug 01, 2011 at 01:23:49PM -0400, Tom Lane wrote:
daveg da...@sonic.net writes:
On Sun, Jul 31, 2011 at 11:44:39AM -0400, Tom Lane wrote:
I think we need to start adding some instrumentation so we can get a
better handle on what's going on in your database. If I were to send
you
Tom Lane t...@sss.pgh.pa.us writes:
Anyone have an opinion about that?
I still have this application where PREPARE takes between 50ms and 300ms
and EXECUTE 5ms to 10ms, and I can handle 1 PREPARE for 1 EXECUTE
quite easily. (Yes the database fits in RAM, and yes when that's no
longer the
On Wed, Aug 3, 2011 at 4:18 AM, Alexander Korotkov aekorot...@gmail.com wrote:
I found that in previous version of patch I missed PageSetLSN
and PageSetTLI, but huge amount of WAL is still here. Also I found that huge
amount of WAL appears only with -O2. With -O0 amount of WAL is ok, but
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 2, 2011 at 8:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe. But if that's the approach we want to use, let's just call it
pg_erand48 in the code, and dispense with the alias macros as well as
all vestiges of configure support.
Works
It occurred to me that you may be a little surprised that the patch
actually prevents the warning from occurring. If you have any doubts,
I can assure you that it does. Clang differentiates between 0 as an
rvalue, 0 from an enum literal and 0 resulting from evaluating a macro
expression (including
Peter Geoghegan pe...@2ndquadrant.com writes:
On 3 August 2011 12:19, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Right, but the purpose of that check is to defend from programmer error. If
the programmer screws up and calls PQresStatus(-1), we want to give an
error, not
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Would you feel comfortable with a patch which threw an error on
the DELETE case, as it does on the UPDATE case?
Yes, though with a little additional twist. The twist being that
I'd like the error to
daveg da...@sonic.net writes:
We have installed the patch and have encountered the error as usual.
However there is no additional output from the patch. I'm speculating
that the pg_class scan in ScanPgRelationDetailed() fails to return
tuples somehow.
Evidently not, if it's not logging
On 3 August 2011 15:29, Tom Lane t...@sss.pgh.pa.us wrote:
No, this is not an improvement at all. The point of the code is that we
are about to use the enum value as an integer array subscript, and we
want to make sure it is within the array bounds. Tying that logic to
some member of the
On Wed, Aug 3, 2011 at 10:48 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
As have many other data mangling bugs which we fix in minor
releases. Our point here is that it's never been like this in any
product that the Wisconsin Courts has used for triggers, and never
will be.
I don't
On Wed, Aug 3, 2011 at 4:50 AM, Florian Pflug f...@phlo.org wrote:
On Aug3, 2011, at 04:54 , Robert Haas wrote:
On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Would you feel comfortable with a patch which threw an error on
the DELETE case, as it does on the
2011/7/29 Greg Smith g...@2ndquadrant.com:
1) Postponing writes as long as possible always improves the resulting
throughput of those writes. Any incremental checkpoint approach will detune
throughput by some amount. If you make writes go out more often, they will
be less efficient; that's
On Wed, Jul 27, 2011 at 7:16 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
One thing I have not addressed is Noah's idea about creating a new lock
mode, KEY UPDATE, that would let us solve the initial problem that this
patch set to resolve in the first place. I am not clear on exactly
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Anyone have an opinion about that?
I still have this application where PREPARE takes between 50ms and 300ms
and EXECUTE 5ms to 10ms, and I can handle 1 PREPARE for 1 EXECUTE
quite easily. (Yes the
On Aug3, 2011, at 17:55 , Robert Haas wrote:
On that note, I think in some ways the problems we're hitting here are
very much like serialization anomalies.
Yeah, I had the same feeling of familiarity ;-)
If the user updates a tuple
based on its PK and sets some non-PK field to a constant,
On 03.08.2011 11:18, Alexander Korotkov wrote:
I found that in previous version of patch I missed PageSetLSN
and PageSetTLI, but huge amount of WAL is still here. Also I found that huge
amount of WAL appears only with -O2. With -O0 amount of WAL is ok, but
messages FATAL: xlog flush request
(moving this to hackers since I suspect we got an issue to fix here)
On Wed, Aug 3, 2011 at 6:35 AM, Sergey Konoplev gray...@gmail.com wrote:
Hi all,
I have PostgreSQL 9.0.3 installed on my Gentoo Linux box. The
configuration is default. There is no any activity in the database but
the
On Aug3, 2011, at 17:57 , Robert Haas wrote:
On Wed, Aug 3, 2011 at 4:50 AM, Florian Pflug f...@phlo.org wrote:
The different between Kevin's original patch and my suggestion is, BTW,
that he made step (7) through an error while I suggested the error to
be thrown already at (4).
I think
Robert Haas robertmh...@gmail.com wrote:
Florian Pflug f...@phlo.org wrote:
Here's a step-by-step description of what happens in the case of
two UPDATES, assuming that we don't ignore any updated and throw
no error.
1) UPDATE T SET ... WHERE ID=1
2) Row with ID=1 is found locked
3)
Excerpts from Robert Haas's message of mié ago 03 12:14:15 -0400 2011:
On Wed, Jul 27, 2011 at 7:16 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
One thing I have not addressed is Noah's idea about creating a new lock
mode, KEY UPDATE, that would let us solve the initial problem that
On Wed, Aug 3, 2011 at 12:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Anyone have an opinion about that?
I still have this application where PREPARE takes between 50ms and 300ms
and EXECUTE 5ms to 10ms, and I
Florian Pflug f...@phlo.org wrote:
To me, it still seems conceptionally cleaner to just decree that a
row must not be modified while BEFORE triggers are running,
period.
This, BTW, also matches what Oracle does, only on a per-row
instead of per-table basis. Oracle AFAIR simply forbids
Excerpts from Dean Rasheed's message of mié ago 03 03:11:32 -0400 2011:
On 3 August 2011 04:40, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Dean Rasheed's message of sáb jul 30 18:40:46 -0400 2011:
Looks pretty good to me (not too dirty). I suppose given that the
parser
On Wed, Aug 3, 2011 at 12:27 PM, Florian Pflug f...@phlo.org wrote:
Going down that road opens the door to a *lot* of subtle semantic
differences between currently equivalent queries. For example,
UPDATE T SET f=f, a=1
would behave differently then
UPDATE T SET a=1
because in the first
On Aug 3, 2011, at 1:47 AM, Peter Geoghegan wrote:
So, there are 4 remaining warnings.
I haven't been paying attention to warnings, but FWIW 9.1beta3 has been
building with LLVM by default with Xcode 4. Both on Snow Leopard and on Lion I
saw something like this:
try=# select version();
On ons, 2011-08-03 at 10:25 +0100, Peter Geoghegan wrote:
Attached patch removes the tautologolical part of an evaluated
expression, fixing the problem flagged by this quite valid warning.
I think these warnings are completely bogus and should not be worked
around. Even in the most trivial
On ons, 2011-08-03 at 10:33 -0700, David E. Wheeler wrote:
I haven't been paying attention to warnings, but FWIW 9.1beta3 has
been building with LLVM by default with Xcode 4. Both on Snow Leopard
and on Lion I saw something like this:
try=# select version();
version
Excerpts from Alvaro Herrera's message of mié ago 03 13:12:38 -0400 2011:
... ah, maybe what we could do is have gram.y create a ColumnDef in the
new production, and stick that in cmd-def instead of the list of
constraints. So parse_utilcmd would have to know that if that node
IsA(ColumnDef)
On Aug 3, 2011, at 11:17 AM, Peter Eisentraut wrote:
Note that what you are using there is a GCC frontend with a LLVM
backend. (So I suppose you would get mostly GCC warnings.) Clang is a
new/different compiler frontend using the LLVM backend.
Yeah, not sure whether or not to tweak the
About nine months ago, we had a discussion of some benchmarking that
was done by the mosbench folks at MIT:
http://archives.postgresql.org/pgsql-hackers/2010-10/msg00160.php
Although the authors used PostgreSQL as a test harness for driving
load, it's pretty clear from reading the paper that
On Wed, Aug 03, 2011 at 02:21:25PM -0400, Robert Haas wrote:
It would be nice if the Linux guys would fix this problem for us, but
I'm not sure whether they will. For those who may be curious, the
problem is in generic_file_llseek() in fs/read-write.c. On a platform
with 8-byte atomic reads,
Tom Lane t...@sss.pgh.pa.us writes:
So yes, it'd get a little worse for that use-case. But you have to
weigh that against the likelihood that other use-cases will get better.
If our requirement for a transient-plan mechanism is that no individual
case can ever be worse than before, then we
Martijn van Oosterhout klep...@svana.org writes:
On Wed, Aug 03, 2011 at 02:21:25PM -0400, Robert Haas wrote:
It would be nice if the Linux guys would fix this problem for us, but
I'm not sure whether they will. For those who may be curious, the
problem is in generic_file_llseek() in
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mar ago 02 22:46:55 -0400 2011:
I have created a documentation patch to clarify this, and to mention
CREATE TABLE AS which also has this optimization.
It doesn't seem particularly better to me. How about something like
In
On 3 Aug 2011, at 19:20, David E. Wheeler wrote:
Yeah, not sure whether or not to tweak the Makefile to use Clang. I guess not?
export CC=clang
./configure
...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Aug 3, 2011 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Martijn van Oosterhout klep...@svana.org writes:
On Wed, Aug 03, 2011 at 02:21:25PM -0400, Robert Haas wrote:
It would be nice if the Linux guys would fix this problem for us, but
I'm not sure whether they will. For those who
Robert Haas robertmh...@gmail.com writes:
This seems like a good design. Now what would be really cool is if
you could observe a stream of queries like this:
SELECT a, b FROM foo WHERE c = 123
SELECT a, b FROM foo WHERE c = 97
SELECT a, b FROM foo WHERE c = 236
...and say, hey, I could
On Aug 3, 2011, at 11:28 AM, Grzegorz Jaskiewicz wrote:
export CC=clang
./configure
...
Thanks, I'll give that a try the next time I build (RC1 I guess).
David
On Wed, Aug 3, 2011 at 3:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
This seems like a good design. Now what would be really cool is if
you could observe a stream of queries like this:
SELECT a, b FROM foo WHERE c = 123
SELECT a, b FROM foo WHERE c =
Simon Riggs si...@2ndquadrant.com writes:
I think its possible to tell automatically whether we need to replan
always or not based upon the path we take through selectivity
functions.
I don't really believe that, or at least I think it would only detect a
few cases. Examples of
Robert Haas robertmh...@gmail.com writes:
On a straight pgbench -S test, you get four system calls per query:
recvfrom(), lseek(), lseek(), sendto(). Adding -M prepared eliminates
the two lseeks.
[ scratches head... ] Two? Is that one for the table and one for its
lone index, or are we
Peter Geoghegan pe...@2ndquadrant.com writes:
On 3 August 2011 15:29, Tom Lane t...@sss.pgh.pa.us wrote:
There is another point here, though, which is that if we're not sure
whether the compiler considers ExecStatusType to be signed or unsigned,
then we have no idea what the test status
On Wed, Aug 3, 2011 at 3:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On a straight pgbench -S test, you get four system calls per query:
recvfrom(), lseek(), lseek(), sendto(). Adding -M prepared eliminates
the two lseeks.
[ scratches head... ] Two?
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 3, 2011 at 3:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(If the query ended up being a seqscan, I'd expect a second
lseek(SEEK_END) when the executor starts up, but I gather from the other
complaints that the mosbench people were only
During btvacuumscan(), we lock the index for extension and then wait
to acquire a cleanup lock on the last page. Then loop until we find a
point where the index has not expanded again during our wait for lock
on that last page. On a busy index this can take some time, especially
when people
On Wed, Aug 3, 2011 at 4:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 3, 2011 at 3:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(If the query ended up being a seqscan, I'd expect a second
lseek(SEEK_END) when the executor starts up, but I gather
On Wed, Aug 3, 2011 at 12:33 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
The only problem, other than a surprising behavior that you noted,
that I see with this approach is that we might repeatedly try to
truncate a relation which in fact does not have anything to truncate.
The worst
Excerpts from Dean Rasheed's message of sáb jul 23 04:37:06 -0400 2011:
On 22 July 2011 22:28, Robert Haas robertmh...@gmail.com wrote:
mine was that we need a command such as
ALTER TABLE foo ALTER COLUMN bar SET NOT NULL name_of_notnull_constr
where the last bit is what's new.
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 3, 2011 at 4:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... We could possibly accept stale values for the
planner estimates, but I think heapam's number had better be accurate.
I think the exact requirement is that, if the relation turns
Hackers,
Python's getattr() allows for dynamic lookup of attributes on an
object, as in:
inst = MyClass(x=12, y=24)
v = getattr(inst, 'x')
assert v == 12
Oftentimes in writing data validating trigger functions, it'd be real
handy to be able to do a similar thing in
Simon Riggs si...@2ndquadrant.com writes:
What seems strange is that we make no attempt to check whether we have
already identified all tuples being removed by the VACUUM. We have the
number of dead tuples we are looking for and we track the number of
tuples we have deleted from the index, so
On Aug 2, 2011, at 7:09 AM, Simon Riggs wrote:
The best compression and flexibility in
that case is to store a bitmap since that will average out at about 1
bit per row, with variable length bitmaps. Which is about 8 times
better compression ratio than originally suggested, without any loss
On Aug 3, 2011, at 1:21 PM, Robert Haas wrote:
1. We configure PostgreSQL to use a 2 Gbyte application-level cache
because PostgreSQL protects its free-list with a single lock and thus
scales poorly with smaller caches. This is a complaint about
BufFreeList lock which, in fact, I've seen as a
On Wed, Aug 03, 2011 at 04:03:39PM -0400, Tom Lane wrote:
The C standard specifies that signed-to-unsigned conversions must work
like that; and even if the standard didn't, it would surely work like
that on any machine with two's-complement representation, which is to
say every computer built
James Robinson jlrob...@socialserve.com writes:
Python's getattr() allows for dynamic lookup of attributes on an
object, as in:
inst = MyClass(x=12, y=24)
v = getattr(inst, 'x')
assert v == 12
Oftentimes in writing data validating trigger functions, it'd be real
On 3 August 2011 21:03, Tom Lane t...@sss.pgh.pa.us wrote:
I mean that it's unclear what you'll get if status has a bitpattern
equivalent to a negative integer. If the compiler implements the
comparison as signed, the test will yield TRUE; if unsigned, it's FALSE.
On compilers on which the
I have not explained well what I have in my mind in first message.
Main goal is more buffers to stay dirty in memory for longer time. So
checkpoint segments have to be 2, 3... times than in current approach. And
separate parameter can control how much buffers to write at once. DBA can
tune:
-
On Wed, Aug 3, 2011 at 5:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That still seems utterly astonishing to me. We're touching each of
those files once per query cycle; a cycle that contains two message
sends, who knows how many internal spinlock/lwlock/heavyweightlock
acquisitions inside
On Wed, Aug 3, 2011 at 6:05 PM, Jim Nasby j...@nasby.net wrote:
Not sure how much this relates to this discussion, but I have often wished we
had AFTER FOR EACH STATEMENT triggers that provided OLD and NEW recordsets
you could make use of. Sometimes it's very valuably to be able to look at
On Wed, Aug 03, 2011 at 01:40:42PM +0300, Heikki Linnakangas wrote:
On 03.08.2011 13:05, Peter Geoghegan wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
Excerpts from Jim Nasby's message of mié ago 03 18:05:21 -0400 2011:
Not sure how much this relates to this discussion, but I have often wished we
had AFTER FOR EACH STATEMENT triggers that provided OLD and NEW recordsets
you could make use of. Sometimes it's very valuably to be able to look
On Wed, Aug 3, 2011 at 6:21 PM, Jim Nasby j...@nasby.net wrote:
On Aug 3, 2011, at 1:21 PM, Robert Haas wrote:
1. We configure PostgreSQL to use a 2 Gbyte application-level cache
because PostgreSQL protects its free-list with a single lock and thus
scales poorly with smaller caches. This is a
On 04.08.2011 04:21, David Fetter wrote:
On Wed, Aug 03, 2011 at 01:40:42PM +0300, Heikki Linnakangas wrote:
On 03.08.2011 13:05, Peter Geoghegan wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be
74 matches
Mail list logo
