Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 21 April 2015 at 22:21, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 April 2015 at 20:50, Stephen Frost sfr...@snowman.net wrote:
Thanks a lot for this. Please take a look at the attached.
I've given this a quick
On Wed, Apr 22, 2015 at 11:09 AM, Kevin Grittner kgri...@ymail.com wrote:
Robert Haas robertmh...@gmail.com wrote:
It's possible that we could use this infrastructure to freeze
more aggressively in other circumstances. For example, perhaps
VACUUM should freeze any page it intends to mark
On Tue, Apr 21, 2015 at 04:36:53PM -0400, Robert Haas wrote:
Keep in mind there's a disconnect between dirtying a page and writing it
to storage. A page could remain dirty for a long time in the buffer
cache. This writing of sequential pages would occur at checkpoint time
only, which
On 04/22/2015 11:29 AM, Jim Nasby wrote:
On 4/20/15 2:04 PM, David G. Johnston wrote:
SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
ERROR: record type has not been registered
While it may not be necessary to solve both problems I suspect they have
the same underlying root cause -
On Tue, Apr 21, 2015 at 10:33 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
[ new patch ]
A little more nitpicking:
ExecInitForeignScan() and ExecInitCustomScan() could declare
currentRelation inside the if (scanrelid 0) block instead of in the
outer scope.
I'm not too excited about the
On Wed, Apr 22, 2015 at 09:18:40AM +0200, Andres Freund wrote:
Peter, Michael,
On 2015-04-22 16:13:15 +0900, Michael Paquier wrote:
All the patches have been committed, finishing the work on this thread.
Many thanks for that effort!
And pg_upgrade thanks you. ;-)
--
Bruce Momjian
On 04/22/2015 05:33 PM, Robert Haas wrote:
On Tue, Apr 21, 2015 at 7:24 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 4/21/15 3:21 PM, Robert Haas wrote:
I'm not saying those ideas don't have problems, because they do. But
I think they are worth further exploring. The main reason I gave
On 4/20/15 2:04 PM, David G. Johnston wrote:
SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
ERROR: record type has not been registered
While it may not be necessary to solve both problems I suspect they have
the same underlying root cause - specifically the separation of concerns
Keenan,
* kee...@thebrocks.net (kee...@thebrocks.net) wrote:
I'm looking into connection to postgres using authentication from client
certificates. [1]
Nice! Glad to hear of more users of that capability. :)
The documentation states that the common name (aka CN) is read from the
On 21 April 2015 at 22:21, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 April 2015 at 20:50, Stephen Frost sfr...@snowman.net wrote:
Thanks a lot for this. Please take a look at the attached.
I've given this a quick read-through, and it looks good to me. The
interaction of permissive
Ah sorry, didn't realize I top posted. I'll test this new one.
Payal.
On Apr 21, 2015 10:23 PM, Jan de Visser j...@de-visser.net wrote:
On April 21, 2015 09:34:51 PM Jan de Visser wrote:
On April 21, 2015 09:01:14 PM Jan de Visser wrote:
On April 21, 2015 07:32:05 PM Payal Singh wrote:
On Tue, Apr 21, 2015 at 7:24 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 4/21/15 3:21 PM, Robert Haas wrote:
It's possible that we could use this infrastructure to freeze more
aggressively in other circumstances. For example, perhaps VACUUM
should freeze any page it intends to mark
On Wed, Apr 22, 2015 at 9:30 PM, Pedro Gimeno
pgsql-...@personal.formauri.es wrote:
Dean Rasheed wrote, On 2015-03-28 10:01:
On 28 March 2015 at 05:16, Andrew Gierth and...@tao11.riddles.org.uk wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I think the concern over backwards
At 2015-04-18 12:28:36 +0530, amit.kapil...@gmail.com wrote:
I think you have missed to address the below point:
4) prefetch
Updated patch attached, as well as the diff against the earlier version
just to make it easier to see the exact change I made (which is to copy
the skip logic from
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
postgres=# select * from ft1 for update;
ERROR: could not find junk tableoid1 column
I think this is a bug. Attached is a patch fixing this issue.
Pushed, thanks!
Stephen
signature.asc
Description: Digital signature
On 4/21/15 4:07 PM, Peter Eisentraut wrote:
On 4/21/15 4:45 PM, Jim Nasby wrote:
In order for a background worker to keep up with some of the workloads
that have been presented as counterexamples, you'd need multiple
background workers operating in parallel and preferring to work on
certain
On Wed, Mar 25, 2015 at 9:51 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
The attached patch adds GetForeignJoinPaths call on make_join_rel() only when
'joinrel' is actually built and both of child relations are managed by same
FDW driver, prior to any other built-in join paths.
I adjusted
Robert Haas robertmh...@gmail.com wrote:
It's possible that we could use this infrastructure to freeze
more aggressively in other circumstances. For example, perhaps
VACUUM should freeze any page it intends to mark all-visible.
That's not a guaranteed win, because it might increase WAL
On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian br...@momjian.us wrote:
But if the entire table is very hot, I think that that is just another of way
of saying that autovacuum is horribly misconfigured. I think the purpose of
Well, we have to assume there are many misconfigured configurations
On 22 April 2015 at 17:02, Stephen Frost sfr...@snowman.net wrote:
Pushed with those changes, please take a look and test!
Excellent, thanks! Will test.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 4/22/15 11:37 AM, Jim Nasby wrote:
On 4/21/15 4:07 PM, Peter Eisentraut wrote:
On 4/21/15 4:45 PM, Jim Nasby wrote:
In order for a background worker to keep up with some of the workloads
that have been presented as counterexamples, you'd need multiple
background workers operating in
On Tue, Apr 21, 2015 at 05:07:52PM -0400, Peter Eisentraut wrote:
On 4/21/15 4:45 PM, Jim Nasby wrote:
This comment made me wonder... has anyone considered handing the pruning
work off to a bgworker, at least for SELECTs? That means the selects
themselves wouldn't be burdened by the actual
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:tested, failed
Error in postgresql.conf gives the expected result on pg_ctl reload,
On April 22, 2015 11:14:08 AM Heikki Linnakangas wrote:
On 04/16/2015 06:51 AM, Alvaro Herrera wrote:
Seems reasonable, but why are you sleeping 1s if pg_ctl -w is in use? I
thought the -w would wait until promotion has taken effect, so there's
no need to sleep additional time.
-w is
On Fri, Mar 13, 2015 at 8:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 13, 2015 at 2:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't object to the concept, but I think that is a pretty bad place
to put the hook call: add_paths_to_joinrel is
On Wed, Apr 22, 2015 at 2:23 PM, Kevin Grittner kgri...@ymail.com wrote:
Robert Haas robertmh...@gmail.com wrote:
I just tested pgbench -i -s 40 -n followed by VACUUM or
alternatively followed by VACUUM FREEZE. The VACUUM generated
4641kB of WAL. The VACUUM FREEZE generated 515MB of WAL -
On 04/22/2015 09:30 PM, Robert Haas wrote:
On Wed, Apr 22, 2015 at 2:17 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
Note that it's a bit complicated to set up that scenario today. Archiving is
never enabled in recovery mode, so you'll need to use a custom cron job or
something to maintain the
On Wed, Apr 22, 2015 at 11:20 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/22/2015 11:29 AM, Jim Nasby wrote:
On 4/20/15 2:04 PM, David G. Johnston wrote:
SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
ERROR: record type has not been registered
While it may not be
Robert Haas robertmh...@gmail.com wrote:
I just tested pgbench -i -s 40 -n followed by VACUUM or
alternatively followed by VACUUM FREEZE. The VACUUM generated
4641kB of WAL. The VACUUM FREEZE generated 515MB of WAL - that
is, 113 times more.
Essentially a bulk load. OK, so if you bulk
On Wed, Apr 22, 2015 at 12:39 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
The thing that made me nervous about that approach is that it made the LSN
of each page critical information. If you somehow zeroed out the LSN, you
could no longer tell which pages are frozen and which are not. I'm
On Wed, Apr 22, 2015 at 2:17 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
Note that it's a bit complicated to set up that scenario today. Archiving is
never enabled in recovery mode, so you'll need to use a custom cron job or
something to maintain the archive that C uses. The files will not
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Seeing this when trying to apply the patch:
Patching file
Greg Stark st...@mit.edu wrote:
And it's a major headache, people are always being surprised that
their selects cause lots of I/O and slow down dramatically after
a big update or data load has finished. It's characterized as
why is the database writing everything twice (and saying it's
On Tue, Apr 21, 2015 at 8:30 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
This .partial segment renaming is something that we
should let the archive_command manage with its internal logic.
This strikes me as equivalent to saying we don't know how to make
this work right, but maybe our
Michael Paquier wrote:
Hi all,
I just bumped into the following problem in HEAD (1c41e2a):
=# create type my_array_float (INPUT = array_in, OUTPUT = array_out,
ELEMENT = float4, INTERNALLENGTH = 32);
ERROR: XX000: cache lookup failed for type 0
LOCATION: format_type_internal,
On 19/04/15 01:24, Michael Paquier wrote:
On Sat, Apr 18, 2015 at 8:38 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Apr 17, 2015 at 10:54 PM, Petr Jelinek wrote:
On 10/04/15 06:46, Michael Paquier wrote:
13) Some regression tests with pg_tablesample_method would be welcome.
On 04/22/2015 10:21 PM, Robert Haas wrote:
On Wed, Apr 22, 2015 at 3:01 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
For example, imagine that perform point-in-time recovery to WAL position
0/1237E568, on timeline 1. That falls within segment
00010012. Then we end recovery, and
On 20/04/15 17:50, Heikki Linnakangas wrote:
On 03/15/2015 09:07 PM, Petr Jelinek wrote:
Slightly updated version of the patch.
Mainly rebased against current master (there were several conflicts) and
fixed some typos, no real functional change.
I also attached initial version of the API sgml
On Wed, Apr 22, 2015 at 3:01 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 04/22/2015 09:30 PM, Robert Haas wrote:
On Wed, Apr 22, 2015 at 2:17 AM, Heikki Linnakangas hlinn...@iki.fi
wrote:
Note that it's a bit complicated to set up that scenario today. Archiving
is
never enabled in
Alvaro Herrera wrote:
Michael Paquier wrote:
Hi all,
I just bumped into the following problem in HEAD (1c41e2a):
=# create type my_array_float (INPUT = array_in, OUTPUT = array_out,
ELEMENT = float4, INTERNALLENGTH = 32);
ERROR: XX000: cache lookup failed for type 0
LOCATION:
Hi Robert,
Thanks for your comments.
A few random cosmetic problems:
- The hunk in allpaths.c is useless.
- The first hunk in fdwapi.h contains an extra space before the
closing parenthesis.
OK, it's my oversight.
And then:
+ else if (scan-scanrelid == 0
+
On Wed, Apr 22, 2015 at 06:36:23PM -0500, Jim Nasby wrote:
On 4/22/15 6:12 PM, Bruce Momjian wrote:
My point is that for the life of 200M transactions, you would have the
overhead of an additional file per table in the file system, and updates
of that. I just don't know if the overhead over
Moving thread to -hackers.
On Wed, Apr 8, 2015 at 11:18 PM, Jeff Davis pg...@j-davis.com wrote:
That example was just for illustration. My other example didn't require
creating a table at all:
SELECT a=b FROM (SELECT ''::text, ' ') x(a,b);
it's fine with me if we want that to fail, but I
On Thu, Apr 23, 2015 at 4:31 AM, Petr Jelinek p...@2ndquadrant.com wrote:
On 19/04/15 01:24, Michael Paquier wrote:
On Sat, Apr 18, 2015 at 8:38 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Apr 17, 2015 at 10:54 PM, Petr Jelinek wrote:
On 10/04/15 06:46, Michael Paquier
On Fri, Jan 30, 2015 at 01:26:22PM -0800, Josh Berkus wrote:
Robert, Stephen, etc.:
Apparently you can create a tablespace in the tablespace directory:
josh=# create tablespace tbl location '/home/josh/pg94/data/pg_tblspc/';
CREATE TABLESPACE
josh=# create table test_tbl ( test text )
On 2015/04/23 0:34, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
postgres=# select * from ft1 for update;
ERROR: could not find junk tableoid1 column
I think this is a bug. Attached is a patch fixing this issue.
Pushed, thanks!
Thank you.
Best regards,
Hello,
At Thu, 16 Apr 2015 14:43:33 -0700, David Fetter da...@fetter.org wrote in
20150416214333.ga...@fetter.org
On Wed, Apr 15, 2015 at 09:35:05AM +0900, Kyotaro HORIGUCHI wrote:
Hi,
Before suppressing the symptom, I doubt the necessity and/or
validity of giving foreign tables an
On Tue, Apr 21, 2015 at 05:36:41PM -0400, Robert Haas wrote:
On Mon, Apr 20, 2015 at 5:41 PM, Bruce Momjian br...@momjian.us wrote:
On Mon, Apr 20, 2015 at 05:04:14PM -0400, Robert Haas wrote:
On Mon, Apr 20, 2015 at 4:11 PM, Bruce Momjian br...@momjian.us wrote:
Slightly improved patch
My apologies if much of this is already assumed knowledge by most
-hackers...I'm trying to learn from observation instead of, largely,
reading code in a foreign language.
On Wed, Apr 22, 2015 at 6:40 PM, Jeff Davis pg...@j-davis.com wrote:
Moving thread to -hackers.
On Wed, Apr 8, 2015 at
Bruce Momjian wrote:
On Wed, Apr 22, 2015 at 04:36:17PM +0100, Greg Stark wrote:
On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian br...@momjian.us wrote:
Well, we have to assume there are many misconfigured configurations ---
autovacuum isn't super-easy to configure, so we can't just blame
On Wed, Apr 22, 2015 at 8:48 AM, Amit Kapila amit.kapil...@gmail.com wrote:
I have implemented this idea (note that I have to expose a new API
shm_mq_from_handle as TupleQueueFunnel stores shm_mq_handle* and
we sum_mq* to call shm_mq_detach) and apart this I have fixed other
problems reported
On Wed, Apr 22, 2015 at 06:07:00PM -0300, Alvaro Herrera wrote:
Good point, but doesn't vacuum remove the need for pruning as it removes
all the old rows?
Sure. The point, I think, is to make autovacuum runs of some sort that
don't actually vacuum but only do HOT-pruning. Maybe this is a
On Wed, Apr 22, 2015 at 3:23 PM, Peter Geoghegan p...@heroku.com wrote:
* We need to sort out those issues with the grammar, since that only
really applies to the inference specification. Maybe the WHERE clause
that the inference specification accepts can be broken out. No ON
CONFLICT UPDATE
On 4/22/15 2:12 PM, Merlin Moncure wrote:
That being said, I think json types with their associated API, given
that they are core types, will ultimately handle these types of
problems. That way, at least, we can avoid adding syntax and
functionality that will basically do the same thing. This
On Tue, Apr 21, 2015 at 08:39:37AM +0200, Andres Freund wrote:
On 2015-04-20 17:13:29 -0400, Bruce Momjian wrote:
Didn't you think any of the TODO threads had workable solutions? And
don't expect adding an additional file per relation will be zero cost
--- added over the lifetime of 200M
On 4/22/15 6:12 PM, Bruce Momjian wrote:
My point is that for the life of 200M transactions, you would have the
overhead of an additional file per table in the file system, and updates
of that. I just don't know if the overhead over the long time period
would be smaller than the VACUUM FREEZE.
On Wed, Apr 22, 2015 at 3:34 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 04/22/2015 10:21 PM, Robert Haas wrote:
On Wed, Apr 22, 2015 at 3:01 PM, Heikki Linnakangas hlinn...@iki.fi
wrote:
For example, imagine that perform point-in-time recovery to WAL position
0/1237E568, on timeline 1.
On Tue, Apr 21, 2015 at 7:57 AM, Andres Freund and...@anarazel.de wrote:
I'm not 100% sure Heikki and I am on exactly the same page here :P
I'm looking at git diff $(git merge-base upstream/master HEAD).. where
HEAD is e1a5822d164db0.
Merged your stuff into my Github branch. Heikki is pushing
On 4/22/15 1:51 PM, Kevin Grittner wrote:
(1) WAL log the insert.
(2) Write the tuple.
(3) Hint and rewrite the tuple.
(4) WAL log the freeze of the tuple.
(5) Rewrite the frozen tuple.
(6) WAL-log the delete.
(7) Rewrite the deleted tuple.
(8) Prune and rewrite the page.
(9) Free line pointers
On Tue, Apr 14, 2015 at 8:35 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Before suppressing the symptom, I doubt the necessity and/or
validity of giving foreign tables an ability to be a parent. Is
there any reasonable usage for the ability?
Gee, I don't see why that would be
On Mon, Apr 13, 2015 at 11:57 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 04/01/2015 07:12 PM, Bruce Momjian wrote:
On Fri, Dec 19, 2014 at 10:26:34PM +0200, Heikki Linnakangas wrote:
On 12/19/2014 02:55 PM, Heikki Linnakangas wrote:
I'm thinking that we should add a step to promotion,
Hi all,
After looking at bug #13128, I have been looking at the code around
LWLockAcquire/Release to see if there are similar issues elsewhere.
Here are my findings:
1) SimpleLruReadPage() holds a control lock at entry that will be held
at exit as well. However SlruReportIOError() can report an
On Wed, Apr 22, 2015 at 04:36:17PM +0100, Greg Stark wrote:
On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian br...@momjian.us wrote:
Well, we have to assume there are many misconfigured configurations ---
autovacuum isn't super-easy to configure, so we can't just blame the
user if this makes
Michael Paquier michael.paqu...@gmail.com writes:
After looking at bug #13128, I have been looking at the code around
LWLockAcquire/Release to see if there are similar issues elsewhere.
Here are my findings:
IIRC, we automatically release all LWLocks at the start of error recovery,
so I rather
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 21 April 2015 at 22:21, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 April 2015 at 20:50, Stephen Frost sfr...@snowman.net wrote:
Thanks a lot for this. Please take a look at the attached.
I've given this a quick
Dean Rasheed wrote, On 2015-03-28 10:01:
On 28 March 2015 at 05:16, Andrew Gierth and...@tao11.riddles.org.uk wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I think the concern over backwards compatibility here is probably
Tom overblown; but if we're sufficiently worried about it, a
On 4/22/15 1:24 PM, Robert Haas wrote:
I keep coming back to the idea of treating any page that is marked as
all-visible as frozen, and deferring freezing until the page is again
modified. The big downside of this is that if the page is set as
all-visible and then immediately thereafter
Peter, Michael,
On 2015-04-22 16:13:15 +0900, Michael Paquier wrote:
All the patches have been committed, finishing the work on this thread.
Many thanks for that effort!
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 04/16/2015 06:51 AM, Alvaro Herrera wrote:
Seems reasonable, but why are you sleeping 1s if pg_ctl -w is in use? I
thought the -w would wait until promotion has taken effect, so there's
no need to sleep additional time.
-w is not supported with pg_ctl promote. Only start, stop and restart.
On Sun, Apr 12, 2015 at 12:36 PM, Peter Eisentraut pete...@gmx.net wrote:
On 3/11/15 8:21 PM, Michael Paquier wrote:
Attached is a series of patch rebased on current HEAD, there were some
conflicts after perl-tidying the refactoring patch for MSVC. Note that
this series still uses PGXS in the
On 21/04/15 22:36, Andres Freund wrote:
On 2015-04-21 16:26:08 -0400, Robert Haas wrote:
On Tue, Apr 21, 2015 at 8:08 AM, Andres Freund and...@anarazel.de wrote:
I've now named the functions:
* pg_replication_origin_create
* pg_replication_origin_drop
* pg_replication_origin_get (map from
On 04/20/2015 05:21 AM, Michael Paquier wrote:
I have just made a run of the TAP tests of pg_rewind on my raspberry
PI 1 (hamster), where the tests are very slow, and I noticed that it
takes up to 10s to get confirmation from standby that it has caught up
with the changes from master, and 5s to
On Wed, Apr 22, 2015 at 8:40 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 04/20/2015 05:21 AM, Michael Paquier wrote:
I have just made a run of the TAP tests of pg_rewind on my raspberry
PI 1 (hamster), where the tests are very slow, and I noticed that it
takes up to 10s to get
73 matches
Mail list logo
