My coworker Dan suggested that some people copy and paste scripts. However
I feel that that is an orthogonal problem and if there is a very high rate
of input psql should detect that and turn interactive off. And I
still strongly feel that on_error_rollback=interactive should be the
default.
Until
On Fri, Oct 7, 2011 at 10:10 AM, Julien Tachoires wrote:
> Hi,
>
> Here's a patch to allow TOAST tables to be moved to a different tablespace.
> This item has been picked up from the TODO list.
> Main idea is to consider that a TOAST table can have its own tablespace.
>
Hi,
This patch doesn't ap
On 11/14/2011 10:09 PM, Robert Haas wrote:
I continue to think that we should be trying to sort these by subject
matter. The term "core extensions" doesn't convey that these are
server management and debugging tools, hence Josh's confusion.
I'm not attached to the name, which I just pulled
On Mon, Nov 14, 2011 at 8:44 PM, Greg Smith wrote:
> On 11/14/2011 07:56 PM, Josh Berkus wrote:
>>
>> So I'm a bit unclear on why most of the optional data types were
>> excluded from your list of Core Extensions.
>
> I was aiming for the extensions that seemed uncontroversial for a first pass
> h
On 11-10-31 12:11 AM, Jun Ishiduka wrote:
>>
>> Agreed. I'll extract FPW stuff from the patch that I submitted, and revise it
>> as the infrastructure patch.
>>
>> The changes of pg_start_backup() etc that Ishiduka-san did are also
>> a server-side infrastructure. I will extract them as another inf
On 11/14/2011 07:56 PM, Josh Berkus wrote:
So I'm a bit unclear on why most of the optional data types were
excluded from your list of Core Extensions.
I was aiming for the extensions that seemed uncontroversial for a first
pass here. One of the tests I applied was "do people sometimes need
On 15 November 2011 00:56, Josh Berkus wrote:
> So I'm a bit unclear on why most of the optional data types were
> excluded from your list of Core Extensions. I would regard the
> following as stable and of general utility:
> isn
I consider contrib/isn to be quite broken. It hard codes ISBN pre
On 15 November 2011 00:56, Josh Berkus wrote:
> Greg,
>
> So I'm a bit unclear on why most of the optional data types were
> excluded from your list of Core Extensions. I would regard the
> following as stable and of general utility:
>
> btree_gin
> btree_gist
> citext
> dblink
> file_fdw
> fuzzy
Greg,
So I'm a bit unclear on why most of the optional data types were
excluded from your list of Core Extensions. I would regard the
following as stable and of general utility:
btree_gin
btree_gist
citext
dblink
file_fdw
fuzzystrmatch
hstore
intarray
isn
ltree
pgcrypto
pg_trgm
unaccent
uuid-oss
> This is a related problem, we should have a terminology for contrib
> tools such as pg_standby or pg_archivecleanup, for modules like the one
> you talk about, that provide new features but nothing visible from SQL,
> and extensions, that are all about SQL --- and if I can work on my plans
> wil
> On the other hand, if our goal in life is to promote the extended
> query protocol over the simple query protocol at all costs, then I
> agree that we shouldn't optimize the simple query protocol in any way.
> Perhaps we should even post a big notice on it that says "this
> facility is deprecate
On Mon, Nov 14, 2011 at 1:01 PM, Robert Haas wrote:
> It looks like the problem is that the original has a blank line after
> the line that says "Version: GnuPG v2.0.17 (GNU/Linux)", but when you
> recall it from the query buffer, that extra blank line gets elided.
>
> The attached patch fixes it
On Mon, Nov 14, 2011 at 5:16 PM, Ross Reedstrom wrote:
> Concise output might look like (bikeshed argument: "splat" indicates
> columns "squashed" out):
>
> test=# \d+ foo
> Table "public.foo"
> Column | Type # Storage #
> +-+-+
> a | in
On Monday, November 14, 2011 10:22:52 PM Tom Lane wrote:
> "Kevin Grittner" writes:
> >> Tom Lane wrote:
> >>> Dunno ... where were the warnings exactly?
> >
> > From HEAD checkout of a few minutes ago I now see only 9:
> Hmm ... well, none of those look likely to be in performance-sensitive
> a
On Monday, November 14, 2011 10:25:19 PM Alvaro Herrera wrote:
> Excerpts from Kevin Grittner's message of lun nov 14 17:30:50 -0300 2011:
> > Tom Lane wrote:
> > > "Kevin Grittner" writes:
> > >> Also, is there something I should do to deal with the warnings
> > >> before this would be considere
On Mon, Nov 14, 2011 at 02:45:04PM -0800, Will Leinweber wrote:
> My coworker Dan suggested that some people copy and paste scripts. However
> I feel that that is an orthogonal problem and if there is a very high rate
> of input psql should detect that and turn interactive off. And I
> still strong
On Mon, Nov 14, 2011 at 06:25:19PM -0300, Alvaro Herrera wrote:
> > All 10 were like this:
> >
> > warning: dereferencing type-punned pointer will break
> > strict-aliasing rules
>
> Uhm, shouldn't we expect there to be one warning for each use of a Node
> using some specific node pointer
Robert Haas wrote:
> But Tom's point about XIDs and LSNs seems like it kind of puts a
> bullet through the heart of the whole idea. Now, before you can move
> the database (or table, or whatever) between clusters, you've got to
> rewrite all the data files to freeze XIDs and, I don't know, zero ou
Thom Brown writes:
> I'm all for removing all mention of "modules". It's ambiguous and
> used inconsistently.
The module is the shared library object. It should be possible to use
that consistently. And I have some plans on my TODO list about them
anyway, so making them disappear from the manu
On Wed, Sep 28, 2011 at 11:47:51AM -0700, David Fetter wrote:
> On Wed, Sep 28, 2011 at 02:25:44PM -0400, Gurjeet Singh wrote:
> > On Wed, Sep 28, 2011 at 1:51 PM, Kevin Grittner > > wrote:
> >
> > > Alvaro Herrera wrote:
> > >
> > > > See ON_ERROR_ROLLBACK
> > > > http://www.postgresql.org/docs
On Mon, Nov 07, 2011 at 11:01:39PM -0500, Josh Kupershmidt wrote:
> On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas wrote:
>
> > I can also see myself turning it on and then going
> > - oh, wait, is that column not there, or did it just disappear because
> > I'm in concise mode?
>
> Yeah, that wou
On Wed, Nov 9, 2011 at 7:58 AM, Alvaro Herrera
wrote:
>
> Excerpts from Jaime Casanova's message of mar nov 08 18:12:25 -0300 2011:
>> On Sun, Nov 6, 2011 at 5:38 AM, Magnus Hagander wrote:
>> >
>> > Looks pretty useful.
>>
>> thanks for the review, attached is a new version of it
>
> Note that A
On 14 November 2011 09:08, Greg Smith wrote:
> I've revived the corpose of the patch submitted in May, now that it's a much
> less strange time of the development cycle to consider it.
> http://archives.postgresql.org/message-id/4df048bd.8040...@2ndquadrant.com
> was the first attempt to move som
On Nov 14, 2011, at 4:31 PM, Greg Smith wrote:
> On 11/14/2011 04:04 PM, Robert Haas wrote:
>> Some pgbench -S numbers (SELECT-only test) from Nate Boley's 32-core
>> box
>
> It seems like Nate Boley's system should be be credited in the 9.2 release
> notes.
+1. Having access to that box h
On 11/14/2011 04:04 PM, Robert Haas wrote:
Some pgbench -S numbers (SELECT-only test) from Nate Boley's 32-core
box
It seems like Nate Boley's system should be be credited in the 9.2
release notes.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training
On 11/14/2011 03:43 PM, Josh Berkus wrote:
Purpose is to provide consistent WAL writes, even when WALInsertLock
contended. Currently no "off" option, thinking is that the overhead of
doing this is relatively low and so it can be "always on" - exactly as
it is for sync rep.
Hmmm, have y
Excerpts from Kevin Grittner's message of lun nov 14 17:30:50 -0300 2011:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
> >> Also, is there something I should do to deal with the warnings
> >> before this would be considered a meaningful test?
> >
> > Dunno ... where were the warnings exactly
"Kevin Grittner" writes:
>> Tom Lane wrote:
>>> Dunno ... where were the warnings exactly?
> From HEAD checkout of a few minutes ago I now see only 9:
Hmm ... well, none of those look likely to be in performance-sensitive
areas. But I wonder just how good the trouble-detection code is these
d
On 14 November 2011 20:54, Pavel Stehule wrote:
> Hello
>
> 2011/11/14 Thom Brown :
>> On 6 October 2011 12:52, Pavel Stehule wrote:
>>>
>>> Hello
>>>
>>> I am sending a version with regress tests and basic documentation
>>
>> Hi Pavel,
>>
>> I think this sentence needs rewriting:
>>
>> "checkfun
On Sun, Nov 13, 2011 at 9:40 PM, Robert Haas wrote:
> On Sun, Nov 13, 2011 at 8:57 PM, Robert Haas wrote:
>> In the -M extended case, we take a snapshot from exec_parse_message(),
>> and the same two in the exec_bind_message() call that are taken in the
>> -M prepared case. So reducing the prepa
Hello
2011/11/14 Thom Brown :
> On 6 October 2011 12:52, Pavel Stehule wrote:
>>
>> Hello
>>
>> I am sending a version with regress tests and basic documentation
>
> Hi Pavel,
>
> I think this sentence needs rewriting:
>
> "checkfunction is the name of a previously registered function that
> will
"Kevin Grittner" wrote:
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Also, is there something I should do to deal with the warnings
>>> before this would be considered a meaningful test?
>>
>> Dunno ... where were the warnings exactly?
>
> All 10 were like this:
>
> warning: deref
> Purpose is to provide consistent WAL writes, even when WALInsertLock
> contended. Currently no "off" option, thinking is that the overhead of
> doing this is relatively low and so it can be "always on" - exactly as
> it is for sync rep.
Hmmm, have you had a chance to do any performance tests?
Tom Lane wrote:
> Dunno ... where were the warnings exactly?
Ah, you asked "where", not "what". I don't think I saved that, and
I had to reboot for a new kernel, so I don't have the buffer sitting
around. I'll do a new build and let you know shortly.
-Kevin
--
Sent via pgsql-hackers mail
Tom Lane wrote:
> "Kevin Grittner" writes:
>> The results were interesting. While the small overlap between
>> samples from the two builds at most levels means that this was
>> somewhat unlikely to be just sampling noise, there could have
>> been alignment issues that account for some of the dif
"Kevin Grittner" writes:
> The results were interesting. While the small overlap between
> samples from the two builds at most levels means that this was
> somewhat unlikely to be just sampling noise, there could have been
> alignment issues that account for some of the differences. In
> short,
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: RangeVarGetAndCheckCreationNamespace() is used for
>> relations (except that
On 6 October 2011 12:52, Pavel Stehule wrote:
>
> Hello
>
> I am sending a version with regress tests and basic documentation
Hi Pavel,
I think this sentence needs rewriting:
"checkfunction is the name of a previously registered function that
will be called when a new function in the language i
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: RangeVarGetAndCheckCreationNamespace() is used for
> relations (except that a few places call RangeVarGetCreationNamespace
> directly, w
Florian Pflug wrote:
> If we're concerned about helping the compiler produce better code,
> I think we should try to make our code safe under strict aliasing
> rules. AFAIK, that generally helps much more than
> const-correctness. (Dunno how feasible that is, though)
To get a preliminary feel
On Mon, November 14, 2011 19:43, Tom Lane wrote:
> Jeff Davis writes:
>> On Mon, 2011-11-14 at 08:11 -0500, Tom Lane wrote:
>
> While thinking about this ... would it be sensible for range_lower and
> range_upper to return NULL instead of throwing an exception for empty or
> infinite ranges? As w
On Mon, Nov 14, 2011 at 4:23 PM, Nikhil Sontakke wrote:
>> > * Non-inheritable check constraints
>> >
>
> So, this patch got shifted to the next commitfest...
I'm sorry, I had intended to get to it for the last two weekends. I'm
not going to wait until the commitfest to look at it.
What I want
On Mon, Nov 14, 2011 at 12:48 PM, Nikhil Sontakke wrote:
>> So it's probably going to take a while to get this
>> completely nailed down, but we can keep chipping away at it.
>
> Agreed. So are you planning to commit this change? Or we want some more
> objects to be fixed? Last I looked at this, w
Jeff Davis writes:
> On Mon, 2011-11-14 at 08:11 -0500, Tom Lane wrote:
>> It needs to return FALSE, actually. After further reading I realized
>> that you have that behavior hard-wired into the range GiST routines,
>> and it's silly to make the stand-alone versions of the function act
>> differe
On Mon, Nov 14, 2011 at 10:33:36AM +0100, Dimitri Fontaine wrote:
> Martijn van Oosterhout writes:
> > While I agree that explicit partitioning is somewhat of a hack, it's a
> > really useful hack. But for me the most important use of partitioning
> > is "dropping a billion rows efficiently and g
On Mon, 2011-11-14 at 08:11 -0500, Tom Lane wrote:
> It needs to return FALSE, actually. After further reading I realized
> that you have that behavior hard-wired into the range GiST routines,
> and it's silly to make the stand-alone versions of the function act
> differently.
Good point. That ma
2011/11/13 Tomas Vondra :
> but recalling it from the query buffer results in
>
> ERROR: Corrupt ascii-armor
>
> I've noticed this on 9.1 but 9.2devel behaves exactly the same. I'm
> using 64-bit Linux with UTF8, nothing special.
It looks like the problem is that the original has a blank line af
Tomorrow November 15, patch submission will close for the 2011-11
CommitFest after 11:59PM PST. New patches ready for review should be
submitted to this mailing list and added to the CommitFest application
at https://commitfest.postgresql.org/ See
http://wiki.postgresql.org/wiki/Development_i
> So it's probably going to take a while to get this
> completely nailed down, but we can keep chipping away at it.
>
>
Agreed. So are you planning to commit this change? Or we want some more
objects to be fixed? Last I looked at this, we will need locking to be done
while creating tables, views, t
On Sun, Nov 13, 2011 at 6:16 PM, Tom Lane wrote:
> While investigating bug #6291 I was somewhat surprised to discover
> $SUBJECT. The cause turns out to be this kluge in alter_table.sql:
>
> select virtualtransaction
> from pg_locks
> where transactionid = txid_current()::int
On Mon, Nov 14, 2011 at 11:48 AM, Nikhil Sontakke
wrote:
>> If all you need to do is lock a schema, you can just call
>> LockDatabaseObject(NamespaceRelationId, namespace_oid, 0,
>> AccessShareLock); there's no need to fake up an objectaddress just to
>> take a lock. But I think that's not really
2011/11/14 Robert Haas :
> On Mon, Nov 14, 2011 at 10:45 AM, Emanuel Calvo
> wrote:
>> 2011/11/10 Robert Haas :
>>> On Wed, Nov 9, 2011 at 12:31 PM, Emanuel Calvo
>>> wrote:
> \dew+ lists the actual options supplied to a foreign data wrapper already.
Checked, but the options doesn
> If all you need to do is lock a schema, you can just call
> LockDatabaseObject(NamespaceRelationId, namespace_oid, 0,
> AccessShareLock); there's no need to fake up an objectaddress just to
> take a lock. But I think that's not really all you need to do,
> because somebody could drop the namespa
> > * Non-inheritable check constraints
> >
>
So, this patch got shifted to the next commitfest...
Regards,
Nikhils
On 14/11/11 13:09, Greg Smith wrote:
On 11/14/2011 10:44 AM, Rudyar wrote:
Ok, I'm working in that project. I will send you my results
and comparision with SQL server HHJ optimization in one or two months.
Please be careful not to share here details of how features like this
are built in any
On Mon, Nov 14, 2011 at 10:45 AM, Emanuel Calvo wrote:
> 2011/11/10 Robert Haas :
>> On Wed, Nov 9, 2011 at 12:31 PM, Emanuel Calvo
>> wrote:
\dew+ lists the actual options supplied to a foreign data wrapper already.
>>>
>>> Checked, but the options doesn't appear (the column exists, but is
On Mon, Nov 14, 2011 at 8:25 AM, Rudyar wrote:
> the hybrid hash join algorithm implemented in the current version of
> PostgreSQL has any kind of optimization
> for star join queries for Data Warehouse model?
Not really. As much as possible, we try to make the query optimizer a
general-purpose
On 11/14/2011 10:44 AM, Rudyar wrote:
Ok, I'm working in that project. I will send you my results
and comparision with SQL server HHJ optimization in one or two months.
Please be careful not to share here details of how features like this
are built in any commercial databases you evaluate. So
2011/11/10 Robert Haas :
> On Wed, Nov 9, 2011 at 12:31 PM, Emanuel Calvo wrote:
>>> \dew+ lists the actual options supplied to a foreign data wrapper already.
>>
>> Checked, but the options doesn't appear (the column exists, but is empty).
>
> Well, that just means that you didn't specify any opt
On 14/11/11 12:37, Robert Haas wrote:
On Mon, Nov 14, 2011 at 10:36 AM, Rudyar wrote:
On 14/11/11 12:20, Robert Haas wrote:
On Mon, Nov 14, 2011 at 8:25 AM, Rudyarwrote:
the hybrid hash join algorithm implemented in the current version of
PostgreSQL has any kind of optimization
for star j
On Mon, Nov 14, 2011 at 10:36 AM, Rudyar wrote:
> On 14/11/11 12:20, Robert Haas wrote:
>>
>> On Mon, Nov 14, 2011 at 8:25 AM, Rudyar wrote:
>>>
>>> the hybrid hash join algorithm implemented in the current version of
>>> PostgreSQL has any kind of optimization
>>> for star join queries for Data
On 14/11/11 12:20, Robert Haas wrote:
On Mon, Nov 14, 2011 at 8:25 AM, Rudyar wrote:
the hybrid hash join algorithm implemented in the current version of
PostgreSQL has any kind of optimization
for star join queries for Data Warehouse model?
Not really. As much as possible, we try to make the
On 14 November 2011 15:07, Robert Haas wrote:
> On Mon, Nov 14, 2011 at 10:05 AM, Thom Brown wrote:
> > On 14 November 2011 13:32, Robert Haas wrote:
> >>
> >> But Tom's point about XIDs and LSNs seems like it kind of puts a
> >> bullet through the heart of the whole idea.
> >
> > What about ha
On Mon, Nov 14, 2011 at 10:05 AM, Thom Brown wrote:
> On 14 November 2011 13:32, Robert Haas wrote:
>>
>> But Tom's point about XIDs and LSNs seems like it kind of puts a
>> bullet through the heart of the whole idea.
>
> What about having database-level XIDs rather than cluster-level? Is that
>
On 14 November 2011 13:32, Robert Haas wrote:
>
> But Tom's point about XIDs and LSNs seems like it kind of puts a
> bullet through the heart of the whole idea.
>
What about having database-level XIDs rather than cluster-level? Is that
remotely feasible?
--
Thom Brown
Twitter: @darkixion
IRC (
On 2011-10-15 07:41, Tom Lane wrote:
Yeb Havinga writes:
Hello Royce,
Thanks again for testing.
I looked this patch over but concluded that it's not ready to apply,
mainly because there are too many weird behaviors around error
reporting.
Thanks again for the review and comments. Attached is
On fre, 2011-11-11 at 15:53 -0500, Bruce Momjian wrote:
> Basically, git checkout assumes a tag, unless you -b for a branch.
No, git checkout assumes a branch, and if it doesn't find a branch, it
looks for a commit by the given name, and a tag is one way of naming a
commit. The -b option creates
On Mon, Nov 14, 2011 at 15:32, Tom Lane wrote:
> Kerem Kat writes:
>> Corresponding is currently implemented in the parse/analyze phase. If
>> it were to be implemented in the planning phase, explain output would
>> likely be as you expect it to be.
>
> It's already been pointed out to you that d
On Mon, Nov 14, 2011 at 4:55 AM, Thom Brown wrote:
> So can I humbly request we completely re-architect the whole of
> PostgreSQL to fit this feature? Thanks.
Heh.
I have to admit I've thought about this from time to time, and it
would be pretty cool. I was initially thinking that it wouldn't
Kerem Kat writes:
> Corresponding is currently implemented in the parse/analyze phase. If
> it were to be implemented in the planning phase, explain output would
> likely be as you expect it to be.
It's already been pointed out to you that doing this at parse time is
unacceptable, because of the
Hello,
the hybrid hash join algorithm implemented in the current version of
PostgreSQL has any kind of optimization
for star join queries for Data Warehouse model?
Regards.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
On 14 November 2011 11:29, Kerem Kat wrote:
> > This explain plan doesn't look right to me:
> >
> > test=# explain select a,b,c from one intersect corresponding by (a,c)
> > select a,b,c from two;
> > QUERY PLAN
> >
> -
Jeff Davis writes:
> On Sun, 2011-11-13 at 15:38 -0500, Tom Lane wrote:
>> I think this demonstrates that the current definition of range_before is
>> broken. It is not reasonable for it to throw an error on a perfectly
>> valid input ... at least, not unless you'd like to mark it VOLATILE so
>>
2011/11/14 Shigeru Hanada
> (2011/11/14 11:25), Robert Haas wrote:
> > My vote is to nuke 'em all. :-)
>
> +1.
>
> IIRC, main purpose of supporting tableoid for foreign tables was to be
> basis of foreign table inheritance, which was not included in 9.1, and
> we have not supported it yet. Othe
(2011/11/14 11:25), Robert Haas wrote:
> My vote is to nuke 'em all. :-)
+1.
IIRC, main purpose of supporting tableoid for foreign tables was to be
basis of foreign table inheritance, which was not included in 9.1, and
we have not supported it yet. Other system columns are essentially
garbage,
> This explain plan doesn't look right to me:
>
> test=# explain select a,b,c from one intersect corresponding by (a,c)
> select a,b,c from two;
> QUERY PLAN
> -
> HashSetOp Intersect
On 25 October 2011 18:49, Kerem Kat wrote:
> On Mon, Oct 24, 2011 at 20:52, Erik Rijkers wrote:
>> On Wed, October 19, 2011 15:01, Kerem Kat wrote:
>>> Adding CORRESPONDING to Set Operations
>>> Initial patch, filename: corresponding_clause_v2.patch
>>
>> I had a quick look at the behaviour of th
Enclosed patch implements Group Commit and also powersave mode for WALWriter.
XLogFlush() waits for WALWriter to run XLogBackgroundFlush(), which
flushes WAL and then wakes waiters. Uses same concepts and similar
code to sync rep.
Purpose is to provide consistent WAL writes, even when WALInsertLo
On 13 November 2011 15:26, Simon Riggs wrote:
> On Sun, Nov 13, 2011 at 1:13 PM, Thom Brown wrote:
>
>> I don't know if this has been discussed before, but would it be
>> feasible to introduce the ability to detach and attach databases? (if
>> you're thinking "stop right there" skip to the end)
Martijn van Oosterhout writes:
> While I agree that explicit partitioning is somewhat of a hack, it's a
> really useful hack. But for me the most important use of partitioning
> is "dropping a billion rows efficiently and getting the disk space
> back". And the biggest problem is always that dro
Tom Lane writes:
> to match the desired granularity of data removal. I don't really see
> any way that the database can be expected to know what that is, unless
> it's told in advance. So AFAICS you really have to have a declarative
> way of telling it how to do the partitioning --- it's not goi
2011-11-13 17:27 keltezéssel, Tom Lane írta:
> Boszormenyi Zoltan writes:
>> I had a report about ECPG code crashing which involved
>> a query using a date field. Attached is a one liner fix to make
>> the date type's offset computed consistently across
>> sqlda_common_total_size(), sqlda_compat_t
82 matches
Mail list logo
