On 17/01/12 18:06, Tom Lane wrote:
Anyway, I'm hoping to keep hacking at this for a couple more days before
the CF gets into full swing, and hopefully arrive at something committable
for 9.2. I'd really like to get this fixed in this cycle, since it's
been a problem for several releases now.
On 18.01.2012 07:49, Fujii Masao wrote:
On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenskijimm...@gmail.com wrote:
I have a need to send banner messages to a psql client that I can set
on the server and will be displayed on any psql client that connects
to the database. This would be mostly used
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
I still have some cleaning to do before to prepare the next patch
version, such as documentation updating and dealing with rewrites of
CHECK and DEFAULT column constraints in CREATE TABLE. I had to add
On Sat, Jan 14, 2012 at 8:10 AM, Matthew Draper matt...@trebex.net wrote:
I just remembered to make time to advance this from WIP to proposed
patch this week... and then worked out I'm rudely dropping it into the
last commitfest at the last minute. :/
The patch applies clean against master
On Wed, Jan 18, 2012 at 06:28, Noah Misch n...@leadboat.com wrote:
On Tue, Jan 17, 2012 at 04:01:23PM +0100, Magnus Hagander wrote:
Thus - if I were to change psql to output timing on failed queries as
well, will anybody object? ;)
+1
Done and applied.
--
Magnus Hagander
Me:
On 01/17/2012 09:00 PM, Jim Nasby wrote:
Could we expose both?
On our systems writes are extremely cheap... we don't do a ton of them
(relatively speaking), so they tend to just fit into BBU cache. Reads on the
other hard are a lot more expensive, at least if they end up actually hitting
On Tue, Jan 17, 2012 at 01:43, Scott Mead sco...@openscg.com wrote:
On Mon, Jan 16, 2012 at 6:10 PM, Scott Mead sco...@openscg.com wrote:
On Sun, Jan 15, 2012 at 4:28 AM, Greg Smith g...@2ndquadrant.com wrote:
On 01/12/2012 11:57 AM, Scott Mead wrote:
Pretty delayed, but please find the
$ pgbench --help
pgbench is a benchmarking tool for PostgreSQL.
Usage:
pgbench [OPTIONS]... [DBNAME]
Initialization options:
-i invokes initialization mode using COPY
-I invokes initialization mode using INSERTs
sounds usefull.
what about a long extra option:
On Wed, Jan 18, 2012 at 3:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 18.01.2012 07:49, Fujii Masao wrote:
On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenskijimm...@gmail.com wrote:
I have a need to send banner messages to a psql client that I can set
on the server
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
It doesn't, and it shouldn't have to. If those nodes get to the
rewriter then somebody forgot to apply parse analysis. What's your test
case?
I'm trying to rewrite the command string from the parse tree,
On Mon, Jan 16, 2012 at 5:09 AM, Noah Misch n...@leadboat.com wrote:
pgstattuple()'s decision to treat half-dead pages like deleted pages is
better. That transient state can only end in the page's deletion.
the only page in that index has 200 records (all live 0 dead) using
half the page
On 13.01.2012 06:24, YAMAMOTO Takashi wrote:
hi,
gistVacuumUpdate was removed when old-style VACUUM FULL was removed.
i wonder why.
it was not practical and REINDEX is preferred?
anyway, the removal seems incomplete and there are some leftovers:
F_TUPLES_DELETED
F_DELETED
On Wed, Jan 18, 2012 at 8:27 AM, Magnus Hagander mag...@hagander.netwrote:
On Tue, Jan 17, 2012 at 01:43, Scott Mead sco...@openscg.com wrote:
On Mon, Jan 16, 2012 at 6:10 PM, Scott Mead sco...@openscg.com wrote:
On Sun, Jan 15, 2012 at 4:28 AM, Greg Smith g...@2ndquadrant.com
On 01/17/2012 11:13 AM, Joel Jacobson wrote:
Since you only care about the parentfuncid in one level, it looks like
you will only be able to get a total call graph of all possible
function calls, and not each unique call graph per transaction.
True, for my purposes (function dependencies and
On 07.01.2012 02:15, Dan Ports wrote:
There's a corner case in the SSI cleanup code that isn't handled
correctly. It can arise when running workloads that are comprised
mostly (but not 100%) of READ ONLY transactions, and can corrupt the
finished SERIALIZABLEXACT list, potentially causing a
On 01/18/2012 03:56 AM, Fujii Masao wrote:
or syslog process (if you use syslog). So ISTM that there is no
guarantee that the order of log messages processed by the
hook is same as that of messages written to the log file. For
example, imagine the case where two backends call EmitErrorReport()
On 01/18/2012 11:12 AM, Martin Pihlak wrote:
On 01/18/2012 03:56 AM, Fujii Masao wrote:
or syslog process (if you use syslog). So ISTM that there is no
guarantee that the order of log messages processed by the
hook is same as that of messages written to the log file. For
example, imagine the
Excerpts from Andrew Dunstan's message of mié ene 18 13:27:40 -0300 2012:
On 01/18/2012 11:12 AM, Martin Pihlak wrote:
On 01/18/2012 03:56 AM, Fujii Masao wrote:
or syslog process (if you use syslog). So ISTM that there is no
guarantee that the order of log messages processed by the
Tom Lane t...@sss.pgh.pa.us writes:
create table foo (id serial, foo integer default 1, primary key(id));
That needs to go through transformCreateStmt(). The comments at the
head of parse_utilcmd.c might be informative.
Indeed, thanks for the heads up here.
While I've not looked at your
On sön, 2012-01-15 at 01:37 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I see that in some places our code already uses #ifdef
USE_ASSERT_CHECKING, presumably to hide similar issues. But in most
cases using this would significantly butcher the code. I found that
On sön, 2012-01-15 at 08:14 -0500, Andrew Dunstan wrote:
It would possibly have some documentary value too. Just looking very
quickly at Peter's patch, I don't really understand his assertion that
this would significantly butcher the code. The worst effect would be
that in a few cases we'd
Excerpts from Dimitri Fontaine's message of mié ene 18 16:03:29 -0300 2012:
At the moment the trigger functions are called from
standard_ProcessUtility() and are given the parse tree as handed over to
that function, before the parse analysis.
We can easily enough copy the parse tree and do
Peter Eisentraut pete...@gmx.net writes:
On sön, 2012-01-15 at 01:37 -0500, Tom Lane wrote:
Surely this will fail entirely on most non-gcc compilers?
No, because __attribute__() is defined to empty for other compilers. We
use this pattern already.
Oh, duh. In that case my only objection
On lör, 2012-01-07 at 16:41 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I suggest that we change PostgresMain(), PostmasterMain(), BackendRun(),
WalSenderMain(), and WalSndLoop() to return void as well.
I agree this code is not very consistent or useful, but one
On Wednesday, January 18, 2012 08:17:36 PM Alvaro Herrera wrote:
Excerpts from Dimitri Fontaine's message of mié ene 18 16:03:29 -0300 2012:
At the moment the trigger functions are called from
standard_ProcessUtility() and are given the parse tree as handed over to
that function, before the
On ons, 2012-01-04 at 00:39 +, Peter Geoghegan wrote:
This should work:
./configure --prefix=/home/peter/pgsql CFLAGS=-Werror
-Wno-error=unused-but-set-variable
However, it does not (with or without the -Wno-error):
checking whether getpwuid_r takes a fifth argument... no
checking
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
We can easily enough copy the parse tree and do another round of parse
analysis on it only when some command triggers are going to get called.
Is the cost of doing so acceptable?
It's not the costs I'm worried about so much as the side effects
On tis, 2012-01-03 at 21:23 -0500, Tom Lane wrote:
I see no point in -Werror whatsoever. If you aren't examining the make
output for warnings, you're not following proper development practice
IMO. gcc is not the only tool we use in the build process, so if you
are relying on -Werror to call
On ons, 2012-01-04 at 13:44 -0500, Robert Haas wrote:
I'm not thrilled about that either. Especially since they seem to be
adding more and more warnings that are harder and harder to work
around for issues that are less and less important. Unimportant
warnings that are easily avoidable are
On mån, 2012-01-16 at 22:59 -0300, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of lun ene 16 12:27:03 -0300 2012:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Peter Eisentraut's message of dom ene 15 10:00:03 -0300
2012:
On ons, 2011-12-28 at 14:35
On 18 January 2012 19:40, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2012-01-04 at 13:44 -0500, Robert Haas wrote:
I'm not thrilled about that either. Especially since they seem to be
adding more and more warnings that are harder and harder to work
around for issues that are less and
Peter Eisentraut pete...@gmx.net writes:
On mån, 2012-01-16 at 22:59 -0300, Alvaro Herrera wrote:
So who's going to work on a patch? Peter, are you? If not, we should
add it to the TODO list.
Not at this very moment, but maybe in a few weeks.
BTW, it strikes me that maybe the coding
Excerpts from Heikki Linnakangas's message of mar ene 17 03:21:28 -0300 2012:
On 16.01.2012 21:52, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of lun ene 16 16:17:42 -0300
2012:
On 15.01.2012 06:49, Alvaro Herrera wrote:
- pg_upgrade bits are missing.
I
On Wed, Jan 18, 2012 at 7:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On mån, 2012-01-16 at 22:59 -0300, Alvaro Herrera wrote:
So who's going to work on a patch? Peter, are you? If not, we should
add it to the TODO list.
Not at this very moment, but
9.2 + DW patch
---
FPW off FPW on DW on/FPW off
CK on CK on CK on
one disk: 11078 10394 3296 [1G shared_buffers, 8G RAM]
sep log disk: 13605 12015 3412
one disk: 7731 6613
On Wednesday, January 18, 2012 08:31:49 PM Tom Lane wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
We can easily enough copy the parse tree and do another round of parse
analysis on it only when some command triggers are going to get called.
Is the cost of doing so acceptable?
On 01/17/2012 11:40 PM, Marti Raudsepp wrote:
It seems you missed a comment, that the current implementation is also
affected by client_min_messages. I think that being affected by
client-specific settings is surprising. I would put the
if(emit_log_hook) inside the existing
On Jan 18, 2012, at 3:49 AM, Greg Smith wrote:
On 01/17/2012 09:00 PM, Jim Nasby wrote:
Could we expose both?
On our systems writes are extremely cheap... we don't do a ton of them
(relatively speaking), so they tend to just fit into BBU cache. Reads on the
other hard are a lot more
Alvaro Herrera alvhe...@commandprompt.com writes:
Huh, isn't it simpler to just pass the triggers the parse tree *after*
parse analysis? I don't understand what you're doing here.
I didn't realize that the parse analysis is in fact done from within
standard_ProcessUtility() directly, which
On Wed, Jan 18, 2012 at 22:56, Martin Pihlak martin.pih...@gmail.com wrote:
We need to keep the if separate
though -- the hook might want to omit the message from server
log so the output_to_server needs to be rechecked.
Oh, yes makes sense.
The updated patch looks good, marking as 'Ready for
On Wed, Jan 18, 2012 at 1:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 17, 2012 at 12:37 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I found it very helpful to reduce wal_writer_delay in pgbench tests, when
running with synchronous_commit=off. The reason is
On Wed, Jan 18, 2012 at 1:28 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 17, 2012 at 12:06 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2012-01-16 at 14:46 -0500, Robert Haas wrote:
On Mon, Jan 16, 2012 at 2:06 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2012-01-16
On Wed, Jan 18, 2012 at 5:49 PM, Simon Riggs si...@2ndquadrant.com wrote:
Can I just check with you that the only review comment is a one line
change? Seems better to make any additional review comments in one go.
No, I haven't done a full review yet - I just noticed that right at
the outset
hi,
On 13.01.2012 06:24, YAMAMOTO Takashi wrote:
hi,
gistVacuumUpdate was removed when old-style VACUUM FULL was removed.
i wonder why.
it was not practical and REINDEX is preferred?
anyway, the removal seems incomplete and there are some leftovers:
F_TUPLES_DELETED
F_DELETED
On Wed, Jan 18, 2012 at 12:10 AM, Nikhil Sontakke nikkh...@gmail.com wrote:
It appears that the only way to create a non-inherited CHECK constraint
is using ALTER TABLE. Is there no support in CREATE TABLE planned?
That looks a bit odd.
There are no plans to do that AFAIR, though maybe
Hi,
accidentally found a our sql typo, which runs without errors on pg 9.1, but
raises error on 9.0. It seems to me, that 9.0 behaviour was correct.
Reproducing case:
create table aaa(id integer NOT NULL, something double precision,
constraint pk_aaa primary key (id));
insert into aaa values
On 2012-01-19 00:25, Gražvydas Valeika wrote:
In PG 9.0 this script complains that: column aaa.something must appear
in the GROUP BY clause or be used in an aggregate function. Sorry, don't
have 9.0 at my hands, but error message is similar to quoted.
Same error is raised in 9.1 when ',
This is because PostgreSQL 9.1 added the feature of simple checking of
functional dependencies for GROUP BY. The manual of 9.1 explains quite well
when PostgreSQL considers there to be a functional dependency.
When GROUP BY is present, it is not valid for the SELECT list expressions
to
On Wed, Jan 18, 2012 at 09:46:20AM -0500, Jaime Casanova wrote:
On Mon, Jan 16, 2012 at 5:09 AM, Noah Misch n...@leadboat.com wrote:
pgstattuple()'s decision to treat half-dead pages like deleted pages is
better. ?That transient state can only end in the page's deletion.
the only page
On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
In sepgsql side, it determines a case to apply permission checks
according to the contextual information; that is same technique
when we implemented create permission.
Thus, it could checks db_xxx:{drop} permission
On Wed, Jan 18, 2012 at 05:18:31PM -0300, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of mar ene 17 03:21:28 -0300 2012:
On 16.01.2012 21:52, Alvaro Herrera wrote:
I was initially thinking that pg_multixact should return the
empty set if requested members of a multi
Simon Riggs si...@2ndquadrant.com writes:
I think we should apply the patch to return the correct SQLCODE in all
cases, even if its supposedly not possible.
[ shrug... ] My opinion about that has not changed. Those are internal
sanity checks, and as such, ERRCODE_INTERNAL_ERROR is exactly the
Gra*vydas Valeika wrote:
This is because PostgreSQL 9.1 added the feature of simple
checking of functional dependencies for GROUP BY. The manual of
9.1 explains quite well when PostgreSQL considers there to be a
functional dependency.
When GROUP BY is present, it is not valid for the
53 matches
Mail list logo
