After having read the most recent thread here about FDW [1] I still in
doubt what the status is of FDW in PostgreSQL 9.1. Looking at the
official docs of file_fdw as Additional Supplied Module [2] there's
no clue about SQL/MED and what the SQL syntax is. I'd like to
contribute at least to the
On Mon, Nov 14, 2011 at 12:07 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 14, 2011 at 2:26 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun nov 14 15:56:43 -0300 2011:
Well, it looks to me like there are three different places that
Robert Haas wrote:
2011/11/28 Shigeru Hanada shigeru.han...@gmail.com:
I agree that allowing users to control which function/operator should be
pushed down is useful, but GUC seems too large as unit of switching
behavior. Routine Mapping, a mechanism which is defined in SQL/MED
standard,
Pavel Stehule wrote:
I am sending updated patch, that implements a CHECK FUNCTION and CHECK
TRIGGER statements.
This patch is significantly redesigned to previous version (PL/pgSQL
part) - it is more readable, more accurate. There are new regress
tests.
Please, can some English native
On Mon, Nov 28, 2011 at 4:44 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I wonder if it's related, because it seems pretty
much the same mechanism: sometimes, a btree index insert would be
randomly forgotten (its page write lost in vacuum, so to speak), ...
Groan.
--
Robert Haas
On Mon, Nov 28, 2011 at 8:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I wonder if it would be worthwhile to build some sort of tool to scan
the heap and ensure that there are index entries for all heap items,
just to test the hypothesis. Not
On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian br...@momjian.us wrote:
David Fetter wrote:
On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
On
On Tue, Nov 29, 2011 at 1:42 AM, YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp wrote:
On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs si...@2ndquadrant.com wrote:
5. Make the WAL writer more responsive, maybe using latches, so that
it doesn't take as long for the commit record to make it out to disk.
Hello
2011/11/29 Albe Laurenz laurenz.a...@wien.gv.at:
Pavel Stehule wrote:
I am sending updated patch, that implements a CHECK FUNCTION and CHECK
TRIGGER statements.
This patch is significantly redesigned to previous version (PL/pgSQL
part) - it is more readable, more accurate. There are
On 09/28/2011 03:53 PM, Brar Piening wrote:
Brar Piening wrote:
The attached patch includes documentation changes and excludes my
versions of pgbison.pl and pgflex.pl which have been replaced by
Andrews' versions that are already commited.
Building current head today I noticed that the
On Tue, Nov 29, 2011 at 3:37 AM, Daniel Farina dan...@heroku.com wrote:
Hmm, just to prod this thread: has any fix for this been committed?
After Nikhil confirmed that this bug could cause pg_dump to not be
able to operate without direct catalog surgery I have encountered this
bug (and treated
On Tue, Nov 29, 2011 at 3:32 AM, Stefan Keller sfkel...@gmail.com wrote:
After having read the most recent thread here about FDW [1] I still in
doubt what the status is of FDW in PostgreSQL 9.1. Looking at the
official docs of file_fdw as Additional Supplied Module [2] there's
no clue about
Pavan Deolasee wrote:
On Sun, Nov 27, 2011 at 12:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas robertmh...@gmail.com
wrote:
Furthermore, it's
hard to understand how this could be a net improvement
On 11/29/2011 10:13 AM, Robert Haas wrote:
On Tue, Nov 29, 2011 at 3:32 AM, Stefan Kellersfkel...@gmail.com wrote:
After having read the most recent thread here about FDW [1] I still in
doubt what the status is of FDW in PostgreSQL 9.1. Looking at the
official docs of file_fdw as Additional
Peter Geoghegan wrote:
Attached are the results from performing a similar process to the
prior benchmark, but on Greg Smith's high-end server, and with an
orderlines table that has been doubled-up until it is 1538 MB,
making the same old query perform a quicksort that's over 3GB. Short
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian br...@momjian.us wrote:
What happened to this patch for casts on domains from June?
Well, if we apply this, it has the possibility to break existing
dumps.
There's also the question of whether there's
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian br...@momjian.us wrote:
What happened to this patch for casts on domains from June?
Well, if we apply this, it has the possibility to break existing
dumps.
There's also the
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Well, if we apply this, it has the possibility to break existing
dumps.
BTW, it occurs to me that we could dodge that objection, with much less
work than Robert suggests, if we just made the
On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Well, if we apply this, it has the possibility to break existing
dumps.
BTW, it occurs to me that we could dodge that
2011/11/28 Dimitri Fontaine dimi...@2ndquadrant.fr:
Kohei KaiGai kai...@kaigai.gr.jp writes:
I found up a similar idea that acquires control on ProcessUtility_hook and
save necessary contextual information on auto variable then kicks the
original ProcessUtility_hook, then it reference the
Simon Riggs wrote:
This costs no performance; if anything it should be faster than now,
because we'll be replacing expensive transaction state probes with
relatively-cheap searches of an XID array that should almost always
be quite short.
With this approach, we would have no
One thing that bothered me while looking at the range types patch is
that it seemed you'd been mighty conservative about creating built-in
range types. In particular, I don't understand why there's not a
standard float8range type; that seems like a pretty common case.
I'd have also expected to
On Sat, 2011-11-26 at 19:26 -0500, Tom Lane wrote:
I'm inclined to propose that we should add some logic to say that
merging a new item into an existing one is forbidden if the penalty
function returns plus-infinity for the case. If all existing items on a
page return infinity, a new item
Pavel Stehule pavel.steh...@gmail.com writes:
2011/11/29 Albe Laurenz laurenz.a...@wien.gv.at:
There are a lot of small changes to pl/plpgsql/src/pl_exec.c, are they all
necessary? For example, why was copy_plpgsql_datum renamed to
plpgsql_copy_datum?
yes, it's necessary - a implementation
Jeff Davis pg...@j-davis.com writes:
On Sat, 2011-11-26 at 19:26 -0500, Tom Lane wrote:
I'm inclined to propose that we should add some logic to say that
merging a new item into an existing one is forbidden if the penalty
function returns plus-infinity for the case. If all existing items on a
2011/11/29 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2011/11/29 Albe Laurenz laurenz.a...@wien.gv.at:
There are a lot of small changes to pl/plpgsql/src/pl_exec.c, are they all
necessary? For example, why was copy_plpgsql_datum renamed to
plpgsql_copy_datum?
Royce Ausburn royce...@inomial.com writes:
One comment I have on the output is that strings are not in quotes. It's a
little jarring, but might not be that big a deal. A contrived case that is
pretty confusing:
test=# insert into test select 1, 2, '3, 4', 4;
ERROR: new row for
Excerpts from Pavel Stehule's message of mar nov 29 14:37:24 -0300 2011:
2011/11/29 Tom Lane t...@sss.pgh.pa.us:
I don't think renaming is necessary. plpgsql is a standalone shared
library and so its symbols don't matter to anybody but itself.
Possibly a larger question, though, is
On 11/29/11 18:51, Tom Lane wrote:
In short, I'm inclined to go ahead and apply this patch, after a bit of
cleanup to make it match our house style better and not break multibyte
characters.
Thanks a lot (and sorry for being lazy and not having updated the test
cases yet).
With kind regards,
On 29 November 2011 15:31, Bruce Momjian br...@momjian.us wrote:
These are exciting advanced you are producing and I am hopeful we can
get this included in Postgres 9.2.
Thanks Bruce.
I have mentioned already that I
think parallelism is the next big Postgres challenge, and of course, one
of
2011/11/29 Pavel Stehule pavel.steh...@gmail.com:
Hello
updated patch:
* recheck compilation and initdb
* working routines moved to pl_exec.c
* add entry to catalog.sgml about lanchecker field
* add node's utils
+ pg_dump support
Pavel
Regards
Pavel Stehule
2011/11/29 Albe Laurenz
Excerpts from Alexander Shulgin's message of Sat Nov 26 21:46:32 +0200 2011:
I would also think that if one is to specify the password in the URI, and the
password happen to contain the @-sign (e.g. !@#$%^,) it should be
percent-encoded, like:
postgresql://user:!%40#$%^@/
Actually,
Excerpts from Alexander Shulgin's message of Sat Nov 26 22:07:21 +0200 2011:
So how about this:
postgresql:ssl://user:pw@host:port/dbname?sslmode=...
The postgresql:ssl:// designator would assume sslmode=require, if not
overriden in extra parameters and postgresql:// would imply
=?UTF-8?B?SmFuIEt1bmRyw6F0?= j...@flaska.net writes:
Attached is a second version of this patch which keeps the size of the
output at 64 characters per column (which is an arbitrary value defined
as a const int, which I hope matches your style). Longer values have
their last three characters
Tom Lane t...@sss.pgh.pa.us wrote:
I was wondering in particular whether it wouldn't be appropriate
to include the same errdetail in ExecConstraints's other check,
the one for null in not-null columns. Arguably a not-null check
is just a slightly optimized form of a CHECK constraint, and
Peter Geoghegan wrote:
On 29 November 2011 15:31, Bruce Momjian br...@momjian.us wrote:
These are exciting advanced you are producing and I am hopeful we can
get this included in Postgres 9.2.
Thanks Bruce.
I have mentioned already that I
think parallelism is the next big Postgres
On Tuesday, November 29, 2011 05:51:40 AM Pavan Deolasee wrote:
On Tue, Nov 29, 2011 at 8:30 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Andres Freund wrote:
I would like to see somebody running a benchmark on a machine with
higher concurrency...
Yeah, me too. I don't
Andrew Dunstan wrote:
Some minor nitpicks:
Do we really need to create all those VSProject.pm and
VSSolution.pm files? They are all always included anyway. Why not
just stash all the packages in Solution.pm and Project.pm?
We certainly don't *need* them.
Having different files
I have applied the attached patch to help make suggestsions for server
developers. I didn't reproduce most of the text because it was already
listed with the options. Let me know if you want additional text.
---
Greg
Bruce Momjian wrote:
Bruce Momjian wrote:
I was wondering if it wouldn't make more sense to have pg_dumpall supply
its own version of exit_horribly to avoid separate pg_malloc and
pg_strdup ... but then those routines are so tiny that it hardly makes a
difference.
Another thing
On Tuesday, November 29, 2011 07:48:37 PM Peter Geoghegan wrote:
On 29 November 2011 15:31, Bruce Momjian br...@momjian.us wrote:
These are exciting advanced you are producing and I am hopeful we can
get this included in Postgres 9.2.
Thanks Bruce.
I have mentioned already that I
On 28 Nov 2011, at 02:15, Peter Geoghegan wrote:
Attached are the results from performing a similar process to the
prior benchmark, but on Greg Smith's high-end server, and with an
orderlines table that has been doubled-up until it is 1538 MB,
making the same old query perform a quicksort
I was doing some tests recently with default_transaction_isolation set
to 'serializable' in postgresql.conf when I noticed pg_locks filling up
with SIReadLocks rather more quickly than I expected.
After some investigation, I found that an autovacuum worker was
starting a transaction at the
Dan Ports d...@csail.mit.edu wrote:
I was doing some tests recently with default_transaction_isolation
set to 'serializable' in postgresql.conf when I noticed pg_locks
filling up with SIReadLocks rather more quickly than I expected.
After some investigation, I found that an autovacuum
Hi,
On Monday, November 28, 2011 08:55:28 PM Gurjeet Singh wrote:
This may not be necessary, but can you please share the modified config you
used for the last run.
I just copied the .conf I had for some independent development.
max_connections = 100
listen_addresses = ''
port=5432
On tis, 2011-11-29 at 16:32 -0500, Bruce Momjian wrote:
I have applied the attached patch to help make suggestsions for server
developers. I didn't reproduce most of the text because it was already
listed with the options. Let me know if you want additional text.
Advising server developers
Peter Eisentraut pete...@gmx.net writes:
On tis, 2011-11-29 at 16:32 -0500, Bruce Momjian wrote:
I have applied the attached patch to help make suggestsions for server
developers. I didn't reproduce most of the text because it was already
listed with the options. Let me know if you want
On Tue, Nov 29, 2011 at 7:12 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I think that a good idea. We need a representation that needs minimum
processing to derive the snapshot.
I was looking over the generated code for GetSnapshotData to see if there
is any low hanging fruit for
Dan Ports d...@csail.mit.edu writes:
After some investigation, I found that an autovacuum worker was
starting a transaction at the default isolation level. While using a
serializable transaction doesn't affect its behavior (because it's not
using a MVCC snapshot), having a serializable
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On tis, 2011-11-29 at 16:32 -0500, Bruce Momjian wrote:
I have applied the attached patch to help make suggestsions for server
developers. I didn't reproduce most of the text because it was already
listed with the options. Let me
Hi,
A few months ago, I got an email related to Pyrseas
(http://lists.pgfoundry.org/pipermail/pyrseas-general/2011-August/03.html)
where the user reported he had a table named user and reported a
failure in the dbtoyaml utility. I eventually implemented a simple
quote_id function (only
Tom Lane t...@sss.pgh.pa.us wrote:
Shouldn't we make the autovac launcher use READ COMMITTED, too?
Anything which starts a transaction and doesn't need to use a
transaction-lifetime snapshot plus SIRead locks to achieve truly
serializable behavior should probably be ignoring
On Tue, Nov 29, 2011 at 07:04:23PM -0500, Tom Lane wrote:
Hmm. Shouldn't we make the autovac launcher use READ COMMITTED, too?
Yeah, probably. That one doesn't seem so important because its
transactions aren't long-running (IIRC, it only starts a transaction to
scan pg_database). But it
Reviving a thread that has hit its second birthday:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00024.php
In our case not being able to restart Postgres when it has been taken
down in the middle of a base backup is starting to manifest as a
serious source of downtime: basically, any
Tom,
I think that if we move a few things into src/extension and set things
up such that they get installed even if you just do make install
rather than requiring make install-world, packagers who don't have
any terribly strong personal agenda will decide that means they ought
to be shipped
On Tue, Nov 29, 2011 at 7:13 PM, Bruce Momjian br...@momjian.us wrote:
Yes. -O0 is really a pretty horrid default choice, and we should NOT be
recommending it, especially not with no discussion of the disadvantages.
I have applied the attached patch to mention the debugger. OK?
Not really.
On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate j...@freedomcircle.com wrote:
It seems to me that since a TYPE in a column definition or function
argument can be a non-native TYPE, it could be a reserved word and
therefore it should always be allowable to quote the TYPE. Can someone
please
On Tue, Nov 29, 2011 at 11:11 AM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Well, if we apply this, it has the possibility to
Robert Haas wrote:
On Tue, Nov 29, 2011 at 7:13 PM, Bruce Momjian br...@momjian.us wrote:
Yes. ?-O0 is really a pretty horrid default choice, and we should NOT be
recommending it, especially not with no discussion of the disadvantages.
I have applied the attached patch to mention the
Dan Ports d...@csail.mit.edu writes:
I was doing some tests recently with default_transaction_isolation set
to 'serializable' in postgresql.conf when I noticed pg_locks filling up
with SIReadLocks rather more quickly than I expected.
After some investigation, I found that an autovacuum worker
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Shouldn't we make the autovac launcher use READ COMMITTED, too?
Anything which starts a transaction and doesn't need to use a
transaction-lifetime snapshot plus SIRead locks to achieve truly
serializable
On 11/29/2011 10:09 PM, Robert Haas wrote:
On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate j...@freedomcircle.com wrote:
It seems to me that since a TYPE in a column definition or function
argument can be a non-native TYPE, it could be a reserved word and
therefore it should always be allowable to
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate j...@freedomcircle.com wrote:
It seems to me that since a TYPE in a column definition or function
argument can be a non-native TYPE, it could be a reserved word and
therefore it should always be allowable to
On Tue, Nov 29, 2011 at 11:50 AM, Bruce Momjian br...@momjian.us wrote:
Just confirming we decided not to persue this.
Doesn't sound like it.
I've been thinking a lot about the more general problem here - namely,
that allowing catalog changes without an access exclusive lock is
unsafe - and
Alvaro Herrera wrote:
Excerpts from Greg Stark's message of s??b jun 25 21:01:36 -0400 2011:
I think this commit was ill-advised:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
Seems way to implementation-specific and detailed for
On Tue, Nov 29, 2011 at 11:21 PM, Joe Abbate j...@freedomcircle.com wrote:
Why does it allow quoting of integer as the table name and the column
name, but not as the type name? Furthermore,
Because there's nothing called integer in the pg_type catalog. It's
not really a type name; as Tom
On 11/29/2011 11:41 PM, Tom Lane wrote:
Another way to say that is that the type int4 can be specified in two
ways:
int4(an identifier)
INTEGER (a keyword)
Quoting int4 is no problem, because it's still an identifier, but
quoting integer takes away its
Robert Haas robertmh...@gmail.com writes:
I will cheerfully admit that this is confusing and inconvenient, and I
didn't understand it either until I implemented pg_dump
--quote-all-identifiers. However, I'm not sure there's any easy way
to improve the situation.
... especially without
Bruce Momjian br...@momjian.us writes:
I have applied the attached patch to mention the debugger. OK?
Server developers should consider using the configure options
option--enable-cassert/ and option--enable-debug/ to enhance
the
ability to detect and debug server
69 matches
Mail list logo
