On Fri, Oct 4, 2013 at 1:46 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Fri, Sep 27, 2013 at 6:44 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Fri, Sep 27, 2013 at 5:18 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Fri, Sep 27, 2013 at 1:28 PM, Sawada Masahiko
On 10/3/13 6:55 PM, Robert Haas wrote:
This looks like a nice clean patch. My only concern is that it makes
on and off unreserved plpgsql keywords. It looks like that will
make them unusable as unquoted identifiers in a few contexts in which
they can now be used. Has there been any discussion
Aside from the pg_upgrade discussion, here's an updated version of the
patch, rebased over master. It also contains some other misc refactoring
I've done while reading through the patch. I haven't tested this much, I
may well have also broken something, but I wanted to post an update
before
W dniu 04.10.2013 02:51, Robert Haas pisze:
Do you have a link to previous discussion on the mailing list?
Sorry, most of discussion was at IRC channel.
I'm not positive there's enough information available
at that stage, but if p_target_rangetblentry is populated at that
point, you should be
On 10/4/13 12:28 AM, Robert Haas wrote:
In fact, we can already get approximately the
desired effect already:
rhaas=# update foo as after set a = before.a + 1 from foo as before
where before.a = after.a returning before.a, after.a;
a | a
---+---
1 | 2
(1 row)
Now this is a hack, because we
Hi Robert,
On 2013-10-03 14:39:46 -0400, Robert Haas wrote:
On Mon, Sep 23, 2013 at 9:36 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I think the idea that we should consider a different way of handling
tabular configuration data has merit. In fact, how much sense does it
make to
On 03 October 2013 19:30 Bruce Momjian wrote:
On Thu, Oct 3, 2013 at 11:54:14AM +0530, Rushabh Lathia wrote:
Thanks Bruce.
Yes for me main problem was to make assumption that a 5-digit number
is a year, as was bit worried about side effect of that assumption in
the date/time module. I
On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
Heikki Linnakangas hlinnakan...@vmware.com wrote:
IMHO it would be better to remove xmin from the lock key, and vacuum
away the old predicate locks when the corresponding tuple
On 04.10.2013 13:23, Andres Freund wrote:
On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
Heikki Linnakangashlinnakan...@vmware.com wrote:
IMHO it would be better to remove xmin from the lock key, and vacuum
away the old
On 2013-10-04 13:51:00 +0300, Heikki Linnakangas wrote:
On 04.10.2013 13:23, Andres Freund wrote:
On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
Heikki Linnakangashlinnakan...@vmware.com wrote:
IMHO it would be better to remove
On 04.10.2013 14:02, Andres Freund wrote:
But locks on those still can have meaning, right? From my very limited
understanding of predicate.c/SSI I don't see why we cannot have
meaningful conflicts on tuples that are already vacuumable. You'd need
some curiously interleaved transactions, sure,
On Fri, Oct 4, 2013 at 12:28 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
Aside from the pg_upgrade discussion, here's an updated version of the
patch, rebased over master. It also contains some other misc refactoring
I've done while reading through the patch. I haven't tested this
Hi,
I noticed a couple of missing words (at least to my reading) in the
bgworker doc. This changes ...is started including the module name... to
...is started by including the module name... and ...to obtain
information the status of the worker. to ...to obtain information
regarding the status of
In HEAD of 9.4 I'm getting the following:
D:\9.4\binpostgres.exe -D d:\9.4\data
LOG: database system was shut down at 2013-10-05 00:43:33 NZDT
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
PANIC: space reserved for WAL record does not match what was
On 2013-10-05 01:05:37 +1300, David Rowley wrote:
In HEAD of 9.4 I'm getting the following:
D:\9.4\binpostgres.exe -D d:\9.4\data
LOG: database system was shut down at 2013-10-05 00:43:33 NZDT
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
PANIC:
On Sat, Oct 5, 2013 at 1:19 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-10-05 01:05:37 +1300, David Rowley wrote:
In HEAD of 9.4 I'm getting the following:
D:\9.4\binpostgres.exe -D d:\9.4\data
LOG: database system was shut down at 2013-10-05 00:43:33 NZDT
LOG: database
Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
Heikki Linnakangashlinnakan...@vmware.com wrote:
IMHO it would be better to remove xmin from the lock key,
and vacuum away the old predicate locks when the
corresponding tuple is vacuumed.
The xmin
On Sat, Oct 5, 2013 at 1:34 AM, David Rowley dgrowle...@gmail.com wrote:
On Sat, Oct 5, 2013 at 1:19 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-10-05 01:05:37 +1300, David Rowley wrote:
In HEAD of 9.4 I'm getting the following:
D:\9.4\binpostgres.exe -D d:\9.4\data
LOG:
On 2013-10-03 20:51:08 -0400, Robert Haas wrote:
On Thu, Oct 3, 2013 at 7:54 PM, Karol Trzcionka karl...@gmail.com wrote:
Compare EXPLAIN ANALYZE VERBOSE on your statement and on patched
workflow. I can see significant difference. And your after returns the
value after whole the work (after
On Thu, Oct 3, 2013 at 10:01 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Oct 3, 2013 at 6:36 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Greg Smith made a list some months ago of contrib modules that were
essential for forensics analysis and such. Weren't we going to do
On Fri, Oct 4, 2013 at 6:06 AM, Andres Freund and...@2ndquadrant.com wrote:
It'd be pretty easy to have a function that removes everything inside a
certain namespace. That'd be enough to make EmitWarningsOnPlaceholders()
work, right?
Maybe, but I don't think you're going to paper over the
On Fri, Oct 4, 2013 at 3:53 AM, Marko Tiikkaja ma...@joh.to wrote:
I don't think there has.
I originally had more ideas for options which you could turn on/off, which I
believe might have justified reserving them, but I'm not sure any of those
will ever happen, at least not as a simple on/off
On 2013-10-04 09:57:41 -0400, Robert Haas wrote:
On Fri, Oct 4, 2013 at 6:06 AM, Andres Freund and...@2ndquadrant.com wrote:
It'd be pretty easy to have a function that removes everything inside a
certain namespace. That'd be enough to make EmitWarningsOnPlaceholders()
work, right?
On Fri, Oct 4, 2013 at 4:42 AM, Karol Trzcionka karl...@gmail.com wrote:
W dniu 04.10.2013 02:51, Robert Haas pisze:
Do you have a link to previous discussion on the mailing list?
Sorry, most of discussion was at IRC channel.
I'm not positive there's enough information available
at that
On Fri, Oct 4, 2013 at 5:04 AM, Marko Tiikkaja ma...@joh.to wrote:
I might be completely in the woods here, but I believe something like this
was attempted by Karol earlier, and it failed if two concurrent transactions
did something similar to:
UPDATE foo SET a = a + 1 RETURNING BEFORE.a;
On Thu, Oct 3, 2013 at 5:11 PM, Sameer Thakur samthaku...@gmail.com wrote:
On Wed, Oct 2, 2013 at 6:40 PM, Sameer Thakur samthaku...@gmail.com wrote:
Looks pretty good. Do you want to package up the patch with your
change and do the honors and re-submit it? Thanks for helping out so
much!
Here's a small patch which greatly increases the speed of
pg_dump --column-inserts.
Previous to this patch a string was being build for the names of the
columns for each row in the table... I've now changed this to only do this
once for the table.
I also did some clean ups to remove calling the
From: Alvaro Herrera alvhe...@2ndquadrant.com
Can you please send a fixup patch to what's already committed?
OK, I'll send a patch against HEAD, which will be a few lines. Am I
understanding the meaning of fixup patch?
Yep, thanks.
Please use the attached patch. Thanks.
Regards
MauMau
On Fri, Oct 4, 2013 at 10:14 AM, Andres Freund and...@2ndquadrant.com wrote:
But that's not a new problem? It already exists and isn't really
excerbated by this.
...
I agree that we could use some more infrastructure around configuration,
but I fail to understand why it's this patch's duty to
On Fri, Oct 4, 2013 at 7:48 AM, Maciek Sakrejda m.sakre...@gmail.com wrote:
I noticed a couple of missing words (at least to my reading) in the bgworker
doc. This changes ...is started including the module name... to ...is
started by including the module name... and ...to obtain information the
David Rowley dgrowle...@gmail.com writes:
Here's a small patch which greatly increases the speed of
pg_dump --column-inserts.
The reason why no one's paid any attention to the speed of that code path
is that if you care about dump/restore speed, you should be using the COPY
code paths instead.
On Fri, Oct 4, 2013 at 11:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
Here's a small patch which greatly increases the speed of
pg_dump --column-inserts.
The reason why no one's paid any attention to the speed of that code path
is that if you care
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Oct 4, 2013 at 11:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
Here's a small patch which greatly increases the speed of
pg_dump --column-inserts.
The reason why no one's paid any attention to
On Fri, Oct 4, 2013 at 09:40:38AM +0530, Amit Kapila wrote:
On Thu, Oct 3, 2013 at 8:35 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
Shouldn't we do it for Set Constraints
On Fri, Oct 4, 2013 at 10:19:38AM +, Haribabu kommi wrote:
On 03 October 2013 19:30 Bruce Momjian wrote:
On Thu, Oct 3, 2013 at 11:54:14AM +0530, Rushabh Lathia wrote:
Thanks Bruce.
Yes for me main problem was to make assumption that a 5-digit number
is a year, as was bit
On Fri, Oct 4, 2013 at 6:44 AM, Robert Haas robertmh...@gmail.com wrote:
I think we were going to try to group the extensions into categories
(debugging tools, demonstration code, data types, etc.) and maybe
encourage packagers to put the debugging tools in the same OS package
as the core
On Fri, Aug 9, 2013 at 11:17 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-08-09 14:11:46 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-08-08 09:27:24 -0400, Robert Haas wrote:
How can it be safe to try to read catalogs if the transaction is aborted?
On 2013-10-04 15:15:36 -0400, Robert Haas wrote:
Andres, are you (or is anyone) going to try to fix this assertion failure?
I think short term replacing it by IsTransactionOrTransactionBlock() is
the way to go. Entirely restructuring how cache invalidation in the
abort path works is not a small
03.10.2013 01:35, Larry Rosenman kirjoitti:
On 2013-10-02 17:32, Josh Berkus wrote:
No fundamental reason; I'm hoping ZFS will be supported in addition to
btrfs, but I don't have any systems with ZFS filesystems at the moment
so I haven't been able to test it or find out the mechanisms ZFS
Hello
I am sending little bit cleaned patch
there is significant speedup (on example from bug report) - more than 100x
on my Dell D830
postgres=# select fill_2d_array(300,300,1);
fill_2d_array
───
9
(1 row)
Time: 751.572 ms -- patched
postgres=# \q
bash-4.1$ psql
On Sat, Oct 5, 2013 at 6:39 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Oct 4, 2013 at 11:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
Here's a small patch which greatly increases the speed of
41 matches
Mail list logo
