Bruce Momjian writes:
> I have applied the attached patch to mention the debugger. OK?
> Server developers should consider using the configure options
> --enable-cassert and --enable-debug to enhance
> the
> ability to detect and debug server errors. They should also c
Robert Haas 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 breaking compatibility w
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 a
On Tue, Nov 29, 2011 at 11:21 PM, Joe Abbate 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 says, it's some rando
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 detai
On Tue, Nov 29, 2011 at 11:50 AM, Bruce Momjian 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 trying to come up w
Robert Haas writes:
> On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate 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
>> pleas
On 11/29/2011 10:09 PM, Robert Haas wrote:
> On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate 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.
"Kevin Grittner" writes:
> Tom Lane 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
>
Dan Ports 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 was
> starting
Robert Haas wrote:
> On Tue, Nov 29, 2011 at 7:13 PM, Bruce Momjian 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.
On Tue, Nov 29, 2011 at 11:11 AM, Jaime Casanova wrote:
> On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Tom Lane wrote:
Robert Haas writes:
> Well, if we apply this, it has the possibility to break existing
> dumps.
>>
>> BTW, it occurs to me that w
On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate 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 explain why that is not t
On Tue, Nov 29, 2011 at 7:13 PM, Bruce Momjian 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. That's sti
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
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 b
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 wouldn'
Tom Lane 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
default_transaction_isolation and f
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 chec
Tom Lane wrote:
> Peter Eisentraut 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
Dan Ports 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 transaction open preve
On Tue, Nov 29, 2011 at 7:12 AM, Pavan Deolasee
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 micro-optimization. The assemb
Peter Eisentraut 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 additional te
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 developer
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
shared_buf
Dan Ports 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 worker was
> start
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 default
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 quickso
On Tuesday, November 29, 2011 07:48:37 PM Peter Geoghegan wrote:
> On 29 November 2011 15:31, Bruce Momjian 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
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.
> > >
>
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 Smith
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 separ
On Tuesday, November 29, 2011 05:51:40 AM Pavan Deolasee wrote:
> On Tue, Nov 29, 2011 at 8:30 AM, Kevin Grittner
>
> 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 find it at all
Peter Geoghegan wrote:
> On 29 November 2011 15:31, Bruce Momjian 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 challeng
Tom Lane 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
> anyway if you t
=?UTF-8?B?SmFuIEt1bmRyw6F0?= 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 replaced by "
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://" woul
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#$%^@/
Actua
2011/11/29 Pavel Stehule :
> 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 :
>> Pave
On 29 November 2011 15:31, Bruce Momjian 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 the first ar
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
Excerpts from Pavel Stehule's message of mar nov 29 14:37:24 -0300 2011:
> 2011/11/29 Tom Lane :
> > 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 whether you r
Royce Ausburn 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 relation "test" violate
2011/11/29 Tom Lane :
> Pavel Stehule writes:
>> 2011/11/29 Albe Laurenz :
>>> 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 is in new
Jeff Davis 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
>> page re
Pavel Stehule writes:
> 2011/11/29 Albe Laurenz :
>> 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 is in new file and there is
> necessary
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
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 see
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
2011/11/28 Dimitri Fontaine :
> Kohei KaiGai 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 contextual information
>> from object_a
On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Tom Lane wrote:
>>> Robert Haas 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 su
Bruce Momjian writes:
> Tom Lane wrote:
>> Robert Haas 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 message be a WARNING not
an ERROR.
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian 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 rea
Robert Haas writes:
> On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian 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 really much point.
The whole questi
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
>
On 11/29/2011 10:13 AM, Robert Haas wrote:
On Tue, Nov 29, 2011 at 3:32 AM, Stefan Keller 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" [
Pavan Deolasee wrote:
> On Sun, Nov 27, 2011 at 12:26 AM, Tom Lane wrote:
> > Pavan Deolasee writes:
> >> On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas
> >> wrote:
> >>> Furthermore, it's
> >>> hard to understand how this could be a net improvement in the general
> >>> case, because now both B
On Tue, Nov 29, 2011 at 3:32 AM, Stefan Keller 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 SQL/MED and wha
On Tue, Nov 29, 2011 at 3:37 AM, Daniel Farina 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 its symptoms
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 pa
Hello
2011/11/29 Albe Laurenz :
> 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
>>
On Tue, Nov 29, 2011 at 1:42 AM, YAMAMOTO Takashi
wrote:
>> On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs 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.
>>>
>>> I'm working on this alread
On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian 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 wrote:
>> > > On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
>> > >> On Tue, May 17, 2011
On Mon, Nov 28, 2011 at 8:40 PM, Tom Lane wrote:
> Alvaro Herrera 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 that this would enlighten on the
>> sourc
On Mon, Nov 28, 2011 at 4:44 PM, Alvaro Herrera
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
EnterpriseDB: http://www.en
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 na
Robert Haas wrote:
> 2011/11/28 Shigeru Hanada :
>> 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, would be the answ
On Mon, Nov 14, 2011 at 12:07 PM, Robert Haas wrote:
> On Mon, Nov 14, 2011 at 2:26 PM, Alvaro Herrera
> 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 we
>>> need to nail down: RangeVarGetAnd
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 doc
69 matches
Mail list logo
