On Wed, Mar 21, 2012 at 10:58 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Consider following sequence of commands
>
> > create type complex as (r float8, i float8);
> > create type quad as (c1 complex, c2 complex);
> > create temp table quadtable(f1 int, q quad);
>
> > insert into quadtable
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> 2012/3/14 Tom Lane
>> For most people it won't
>> matter, but for people who are using the feature, it seems like
>> important information. Per the OP's complaint, it's particularly
>> important for those who have forgotten they're using the f
-Original Message-
From: Atri Sharma [mailto:atri.j...@gmail.com]
Sent: 22 March 2012 09:20
To: 'Atri Sharma'
Subject: RE: [HACKERS] Regarding column reordering project for GSoc 2012
-Original Message-
From: Atri Sharma [mailto:atri.j...@gmail.com]
Sent: 20 March 2012 23:05
T
On Wed, Mar 21, 2012 at 10:59 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> ... although none of the issues alone is a show-stopper, but considering
>> all these things together, I'm starting to feel that this needs to be
>> pushed to 9.3. Thoughts?
>
> Agreed. In particular, I think you a
On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane wrote:
>> It strikes me that it likely wouldn't be any
>> worse than, oh, say, flipping the default value of
>> standard_conforming_strings,
>
> Really? It's taking away functionality and not supplying any substitute
> (or at least you did not propose any
Robert Haas writes:
> On Wed, Mar 21, 2012 at 8:44 PM, Tom Lane wrote:
>> Oh, right. So scratch that objection. The other one is still fatal
>> though ...
> So, could we just decide that we don't care about preserving that
> property any more, and document it as an incompatibility in whatever
>> Why not just enhance PL/pgsql
>
> plpgsql is based on PL/SQL and it is ADA. PSM is relative unique
> language - similar to modula with one significant feature - handlers -
> so ADA and PSM are different languages with different syntax.
Also, PSM is implemented by MySQL and DB2, so having it h
On Wed, Mar 21, 2012 at 8:44 PM, Tom Lane wrote:
> Oh, right. So scratch that objection. The other one is still fatal
> though ...
So, could we just decide that we don't care about preserving that
property any more, and document it as an incompatibility in whatever
release we break it in? It s
On Mon, Mar 19, 2012 at 12:23 PM, Robert Haas wrote:
...
>
> One thing that seems inefficient to me about our current algorithm is
> the use of the run number as a leading column in the sort key.
> There's no real reason why the tuples destined for the next run need
> to be maintained in heap orde
heap_freeze_tuple() was apparently designed at one point to cope with
being called with either a shared or exclusive buffer lock. But none
of the current callers call it with a shared lock; they all call it
with an exclusive lock, except for the heap-rewrite code which doesn't
take (or need) a loc
Robert Haas writes:
> On Wed, Mar 21, 2012 at 8:13 PM, Tom Lane wrote:
>> Another issue, quite independent from race conditions against other
>> observers of the row, is what if the tuple is part of an update chain?
>> You have no way to find the predecessor row version and update its
>> t_ctid f
On Wed, Mar 21, 2012 at 8:13 PM, Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> Specifically, I'm wondering if we couldn't get away with rearranging
>>> things so that the root line pointer (which has index entries) points
>>> to the actual tuple, and the other line pointer (which can't ha
Greg Stark writes:
> On Wed, Mar 21, 2012 at 2:22 PM, Tom Lane wrote:
>> Well, above Etsuro-san is proposing the other case, ie a Postgres index
>> definition for an index *not* stored in the database. But frankly
>> I think both ideas are pretty bad. There's no reason to expect that
>> Postgre
I wrote:
> Robert Haas writes:
>> Specifically, I'm wondering if we couldn't get away with rearranging
>> things so that the root line pointer (which has index entries) points
>> to the actual tuple, and the other line pointer (which can't have any
>> index entries) gets marked UNUSED.
> This wou
Robert Haas writes:
> Specifically, I'm wondering if we couldn't get away with rearranging
> things so that the root line pointer (which has index entries) points
> to the actual tuple, and the other line pointer (which can't have any
> index entries) gets marked UNUSED.
This would amount to chan
On Wed, Mar 21, 2012 at 2:22 PM, Tom Lane wrote:
> Well, above Etsuro-san is proposing the other case, ie a Postgres index
> definition for an index *not* stored in the database. But frankly
> I think both ideas are pretty bad. There's no reason to expect that
> Postgres' model of an index will
When the root tuple of a HOT chain is dead, but there's still at least
one non-dead member of the chain, we end up with a REDIRECT line
pointer, which points to a USED line pointer, which in turn points to
a live tuple. This means we're using 2 line pointers for only 1 line
tuple. Since line poin
On tis, 2012-03-20 at 15:04 -0400, Tom Lane wrote:
> Hm. I bet it thinks that PG_USED_FOR_ASSERTS_ONLY is the variable
> name, which means that the behavior might be more exciting for
> multi-word type names (for instance "struct foo" or "volatile int *".
> Could you check a few cases like that?
On Wed, Mar 21, 2012 at 3:34 PM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Thoughts?
>
> It was my impression that these patches were much about improving
> overall tps and more about reducing latency spikes for specific
> transactions that get hit by a che
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> Thoughts?
It was my impression that these patches were much about improving
overall tps and more about reducing latency spikes for specific
transactions that get hit by a checkpoint happening at a bad time.
Are there any reductions in max la
There are two checkpoint-related patches in this CommitFest that
haven't gotten much love, one from me and the other from Greg Smith:
https://commitfest.postgresql.org/action/patch_view?id=752
https://commitfest.postgresql.org/action/patch_view?id=795
Mine uses sync_file_range() when available (i
Ashutosh Bapat writes:
> Consider following sequence of commands
> create type complex as (r float8, i float8);
> create type quad as (c1 complex, c2 complex);
> create temp table quadtable(f1 int, q quad);
> insert into quadtable (f1, q.c1.r, q.c2.i) values(44,55,66);
> While parsing the INSER
On Wed, Mar 21, 2012 at 6:07 AM, Kohei KaiGai wrote:
> The reason why dynamic domain transition should be configured
> carefully is that it partially allows users to switch their own privileges
> in discretionary way, unlike trusted procedure.
>
> The original model of selinux on operating system
On Wed, Oct 26, 2011 at 10:37 AM, Pavel Stehule wrote:
> Oct 25 20:13:44 db-s-01 postgres: -- postgres[29970]:
> [3-1] 2011-10-25 20:13:44 CEST adifd 29970 ERROR: cache lookup failed
> for relation 319883311
> Oct 25 20:13:44 db-s-01 postgres: -- postgres[29970]:
> [3-2] 2011-10-25 20:13:44 C
Alex writes:
> Marko Kreen writes:
>
>> On Thu, Mar 15, 2012 at 11:29:31PM +0200, Alex wrote:
>>> https://github.com/a1exsh/postgres/commits/uri
>>
>> The point of the patch is to have one string with all connection options,
>> in standard format, yes? So why does not this work:
>>
>> db = PQ
On Wed, Mar 21, 2012 at 11:58 AM, Andres Freund wrote:
> On Wednesday, March 21, 2012 04:54:00 PM Robert Haas wrote:
>> On Tue, Mar 20, 2012 at 12:02 PM, Andres Freund wrote:
>> > The attached patch applies from 8.3 to 9.1 (8.2 has conflicts but
>> > thankfully...).
>>
>> It seems it doesn't appl
On Wed, Feb 29, 2012 at 10:18 AM, Michael Tautschnig wrote:
> In [3] it was suggested to fix the problem by placing a barrier in ResetLatch,
> which corresponds to placing it between lines 11 and 12 in the code above.
> This
> amounts to placing a barrier between the two reads (lines 7/19 and 12
Robert Haas writes:
> Well, there's something mighty tempting about having a way to say
> "just give me a random sample of the blocks and I'll worry about
> whether that represents a random sample of the rows".
> It's occurred to me a few times that it's pretty unfortunate you can't
> do that wit
On 03/21/2012 11:49 AM, Robert Haas wrote:
On Wed, Mar 21, 2012 at 11:34 AM, Tom Lane wrote:
Robert Haas writes:
Well, the standard syntax apparently aims to reduce the number of
returned rows, which ORDER BY does not. Maybe you could do it with
ORDER BY .. LIMIT, but the idea here I think
On Wednesday, March 21, 2012 04:54:00 PM Robert Haas wrote:
> On Tue, Mar 20, 2012 at 12:02 PM, Andres Freund wrote:
> > The attached patch applies from 8.3 to 9.1 (8.2 has conflicts but
> > thankfully...).
>
> It seems it doesn't apply to master (any more?).
Its not required there because of the
On Wed, Feb 29, 2012 at 5:48 AM, Fujii Masao wrote:
> Hi,
>
> In streaming replication, after failover, new master might have lots
> of un-applied
> WAL files with old timeline ID. They are the WAL files which were recycled as
> a
> future ones when the server was running as a standby. Since they
On Tue, Mar 20, 2012 at 12:02 PM, Andres Freund wrote:
> The attached patch applies from 8.3 to 9.1 (8.2 has conflicts but
> thankfully...).
It seems it doesn't apply to master (any more?).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
On Wed, Mar 21, 2012 at 11:34 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well, the standard syntax apparently aims to reduce the number of
>> returned rows, which ORDER BY does not. Maybe you could do it with
>> ORDER BY .. LIMIT, but the idea here I think is that we'd like to
>> sample the ta
On 12.03.2012 15:30, Fujii Masao wrote:
On Mon, Mar 12, 2012 at 10:27 PM, Fujii Masao wrote:
On Mon, Mar 12, 2012 at 7:58 PM, Heikki Linnakangas
wrote:
I also think we should backport commit
cff75130b5f63e45423c2ed90d6f2e84c21ef840, except for the removal of
wal_sender_delay).
Agreed. The
> Date: Wed, 21 Mar 2012 11:00:59 -0400
> From: and...@dunslane.net
> To: alvhe...@commandprompt.com
> CC: t...@sss.pgh.pa.us; robertmh...@gmail.com; huangq...@hotmail.com;
> neil.con...@gmail.com; dan...@heroku.com; j...@agliodbs.com;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Gso
Robert Haas writes:
> Well, the standard syntax apparently aims to reduce the number of
> returned rows, which ORDER BY does not. Maybe you could do it with
> ORDER BY .. LIMIT, but the idea here I think is that we'd like to
> sample the table without reading all of it first, so that seems to
> m
Hello
2012/3/21 Robert Haas :
> On Wed, Feb 22, 2012 at 4:19 PM, Pavel Stehule
> wrote:
>> I propose to integrate a PSM language into the core. This language is
>> defined as part of ANSI SQL - SQL/PSM and is used in some well known
>> databases like DB2, Terradata and some other less known RDBM
Andrew Dunstan writes:
> On 03/21/2012 10:47 AM, Alvaro Herrera wrote:
>> I disagree with there being zero interest ... the "order by random()"
>> stuff does come up occasionally.
> Presumably the reason that's not good enough is that is scans the whole
> table (as well as being non-portable)?
On Wed, Mar 21, 2012 at 11:11 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I don't think we can wait any longer for this; we're now more than two
>> months in to this CommitFest, and command triggers is still in full
>> swing.
>
> Is it possible to have another day to send out a revised p
On Wed, Mar 21, 2012 at 10:57 AM, Andres Freund wrote:
> On Wednesday, March 21, 2012 03:47:23 PM Alvaro Herrera wrote:
>> Excerpts from Tom Lane's message of mié mar 21 11:35:54 -0300 2012:
>> > Now that would all be fine if this were a widely-desired feature, but
>> > AFAIR the user demand for i
Robert Haas writes:
> I don't think we can wait any longer for this; we're now more than two
> months in to this CommitFest, and command triggers is still in full
> swing.
Is it possible to have another day to send out a revised patch? The
problem reported is either a show stopper or a less-than
On Wed, Feb 22, 2012 at 4:19 PM, Pavel Stehule wrote:
> I propose to integrate a PSM language into the core. This language is
> defined as part of ANSI SQL - SQL/PSM and is used in some well known
> databases like DB2, Terradata and some other less known RDBMS like
> MonetDB. A The proposed implem
On 03/21/2012 10:47 AM, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mié mar 21 11:35:54 -0300 2012:
Now that would all be fine if this were a widely-desired feature, but
AFAIR the user demand for it has been about nil. So I'm leaning to
the position that we don't want it.
I di
On Fri, Feb 24, 2012 at 2:23 PM, Ants Aasma wrote:
> On Wed, Feb 22, 2012 at 6:35 PM, Ants Aasma wrote:
>>> Some implementation notes. This currently fails regression test
>>> create_function_3, haven't looked into why yet.
>>
>> I'll take a look at it.
>
> The failure was due to leakproof chang
On Tue, Feb 28, 2012 at 12:05 AM, Josh Kupershmidt wrote:
> A simple fix would be just to pass fail_ok = false for the last
> connectDatabase() call inside connectMaintenanceDatabase(), and give
> up on trying to tack on a likely-misleading hint about the maintenance
> database. Patch attached.
C
Excerpts from Robert Haas's message of mié mar 21 11:43:17 -0300 2012:
> On Fri, Mar 16, 2012 at 1:34 PM, Peter Eisentraut wrote:
> > Here is a patch for being able to rename constraints of domains. It
> > goes on top of the previously committed patch for renaming table
> > constraints.
>
> I d
On Wednesday, March 21, 2012 03:47:23 PM Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of mié mar 21 11:35:54 -0300 2012:
> > Now that would all be fine if this were a widely-desired feature, but
> > AFAIR the user demand for it has been about nil. So I'm leaning to
> > the position tha
On Thu, Mar 8, 2012 at 9:39 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> Dimitri, are you going to post an updated patch for this CF?
>
> Yes, I intend to do that. Not sure about diverting from the command
> trigger patch while Thom is full speed on reviewing and helping me write
> the f
Excerpts from Tom Lane's message of mié mar 21 11:35:54 -0300 2012:
> Now that would all be fine if this were a widely-desired feature, but
> AFAIR the user demand for it has been about nil. So I'm leaning to
> the position that we don't want it.
I disagree with there being zero interest ... th
On Fri, Mar 16, 2012 at 1:34 PM, Peter Eisentraut wrote:
> Here is a patch for being able to rename constraints of domains. It
> goes on top of the previously committed patch for renaming table
> constraints.
I don't like the way you've modified get_constraint_oid(), which is
currently parallel
Robert Haas writes:
> One thing we should probably try to establish before you get started
> working on this is whether people want the feature, which is basically
> the ability to write something like this in the FROM clause of a
> query:
> table_name TABLESAMPLE { BERNOULLI | SYSTEM } ( sample_
Robert Haas writes:
> On Wed, Mar 21, 2012 at 4:47 AM, Etsuro Fujita
> wrote:
>> I did an investigation on DB2 a little bit. DB2 uses the CREATE INDEX
>> SPECIFICATION ONLY statement to define the properties of a remote index.
>>
>>CREATE INDEX index_name ON foreintable_name
>>(column_n
On Tue, Mar 20, 2012 at 10:22 PM, Qi Huang wrote:
> Thanks so much, Neil.
> I think I kind of understand the situation for now. The implementation
> posted by Neil was for the purpose of the talk, thus rushed and may not be
> up to st andard of Postgres Community. Also Neil mentioned the PRNG stat
Heikki Linnakangas writes:
> ... although none of the issues alone is a show-stopper, but considering
> all these things together, I'm starting to feel that this needs to be
> pushed to 9.3. Thoughts?
Agreed. In particular, I think you are right that it'd be prudent to
simplify the WAL-locatio
Heikki Linnakangas writes:
> On 21.03.2012 01:05, Tom Lane wrote:
>> Improve the -l (limit) option recently added to contrib/vacuumlo.
> Shouldn't this be backported? Without it, vacuumlo is effectively broken
> in 9.0 and 9.1.
I was wondering about that. You could argue for either "it's a new
On Tue, Mar 20, 2012 at 6:16 PM, Greg Stark wrote:
> On Tue, Mar 20, 2012 at 8:00 PM, Robert Haas wrote:
>>> Frankly that analysis didn't make any sense to me at the time.
>>> Comparing integers is fast, sure, but it's still slower than not
>>> having to do any comparison at all.
>>
>> I think yo
On Wed, Mar 21, 2012 at 7:52 AM, Heikki Linnakangas
wrote:
> So, although none of the issues alone is a show-stopper, but considering all
> these things together, I'm starting to feel that this needs to be pushed to
> 9.3. Thoughts?
I think I agree. I like the refactoring ideas that you're propo
On Wed, Mar 21, 2012 at 4:47 AM, Etsuro Fujita
wrote:
> I did an investigation on DB2 a little bit. DB2 uses the CREATE INDEX
> SPECIFICATION ONLY statement to define the properties of a remote index.
>
> CREATE INDEX index_name ON foreintable_name
> (column_name) SPECIFICATION ONLY
>
> How
On 21.03.2012 13:14, Fujii Masao wrote:
PANIC: space reserved for WAL record does not match what was
written, CurrPos: C/0, EndPos: B/FF00
So I think that the patch would have a bug which handles WAL boundary wrongly.
Thanks for the testing! These WAL boundary issues are really trick
On Thu, Mar 15, 2012 at 5:52 AM, Heikki Linnakangas
wrote:
> When all those changes are put together, the patched version now beats or
> matches the current code in the RAM drive tests, except that the
> single-client case is still about 10% slower. I added the new test results
> at http://communi
I think the reason the planner isn't too bright about this case is
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=cd1f0d04bf06938c0ee5728fc8424d62bcf2eef3
ie, it won't do IN/EXISTS pullup below a NOT EXISTS.
HEAD is better, thanks to commit
0816fad6eebddb8f1f0e21635e46625815d69
2012/3/20 Robert Haas :
> On Fri, Mar 16, 2012 at 3:44 AM, Yeb Havinga wrote:
>> In the patch with copy-editing documentation following that commit, at "in
>> at their option", s/in// ?
>
> Oh, yeah. Oops. Thanks.
>
>> Also 'rather than .. as mandated by the system':
>> I'm having trouble parsin
(2012/03/21 4:39), Robert Haas wrote:
On Fri, Mar 16, 2012 at 4:44 AM, Etsuro Fujita
wrote:
For a flat file, CREATE INDEX constructs an index in the same way as an
index for a regular table.
It seems really weird to have the data half inside the database and
half outside of it like this.
On 20.03.2012 23:41, Josh Berkus wrote:
Heikki,
The FSM is included in the base backup, and it is updated when VACUUM
records are replayed.
Oh? H. In that case, the issue I'm seeing in production is
something else. Unless that was a change for 9.1?
No, it's been like that since 8.4,
On 21.03.2012 01:05, Tom Lane wrote:
Improve the -l (limit) option recently added to contrib/vacuumlo.
Instead of just stopping after removing an arbitrary subset of orphaned
large objects, commit and start a new transaction after each -l objects.
This is just as effective as the original patch
65 matches
Mail list logo
