On Thu, Jul 2, 2015 at 8:02 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
While I'm implementing the patch around pg_archivecleanup, I found
the following warning about pg_archivecleanup in the document.
Note that the .backup file name passed to the program should not
include the
On Thu, Jul 2, 2015 at 11:16 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I was going through the code and have few comments:
- Why do you change the return value of TryReuseIndex? Can't we use reuse
the same OidIsValid(stmt-oldNode) check that ATExecAddIndex is doing
instead?
As pointed out
On 07/03/2015 06:27 AM, Heikki Linnakangas wrote:
On 05/27/2015 09:51 PM, Andrew Dunstan wrote:
On 05/27/2015 02:37 PM, Robert Haas wrote:
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de wrote:
Is it reasonable to add this patch to CommitFest now?
It's
On Fri, Jul 3, 2015 at 4:48 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Thu, Apr 2, 2015 at 3:24 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 25, 2015 at 9:46 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On 2015-07-03 15:50, Michael Paquier wrote:
On Thu, Jul 2, 2015 at 11:16 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I was going through the code and have few comments:
- Why do you change the return value of TryReuseIndex? Can't we use reuse
the same OidIsValid(stmt-oldNode) check that
On Fri, Jul 3, 2015 at 3:01 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Fri, Jul 03, 2015 at 02:34:44PM +0900, Fujii Masao wrote:
Hmm, for me it is 100% reproducable. Are you familiar with Docker? I
can probably construct a Dockerfile that reproduces it pretty reliably.
I could
Fujii Masao masao.fu...@gmail.com writes:
The optimization of TRUNCATE opereation that we can use when
CREATE TABLE and TRUNCATE are executed in the same transaction block
seems to cause the problem. In this case, only index file truncation is
logged, and index creation in btbuild() is not
On 7/3/2015 8:19 AM, Michael Paquier wrote:
On Fri, Jul 3, 2015 at 2:47 PM, Marco Atzeri marco.atz...@gmail.com wrote:
On 7/2/2015 5:16 PM, Dave Page wrote:
-lldap
hstore_plperl.o: In function `hstore_to_plperl':
Fabien COELHO coe...@cri.ensmp.fr writes:
I'm pretty clearly in favor of doing correct lexing. I think we should
generalize that and make it reusable. psql has it's own hacked up
version already, there seems little point in having variedly good copies
around.
I must admit that I do not know
On 07/03/2015 01:47 AM, Marco Atzeri wrote:
On 7/2/2015 5:16 PM, Dave Page wrote:
The PostgreSQL Global Development Group announces that the alpha
release of PostgreSQL 9.5, the latest version of the world's leading
open source database, is available today. This release contains
previews of
On Fri, Jul 03, 2015 at 12:53:56PM -0400, Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
Okay, so probably we need to change WAL replay of TRUNCATE so that
the index file is truncated to one containing only meta page instead of
empty one. That is, the WAL replay of TRUNCATE would
On 2015-07-03 10:27:05 -0700, Josh Berkus wrote:
On 07/03/2015 03:12 AM, Sawada Masahiko wrote:
Thanks. So we can choice the next master server using by checking the
progress of each server, if hot standby is enabled.
And a such procedure is needed even today replication.
I think that
On 04/21/2015 04:02 PM, Michael Paquier wrote:
On Tue, Apr 21, 2015 at 4:33 PM, Asif Naeem anaeem...@gmail.com wrote:
The v2 patch looks good to me, just a minor concern on usage message i.e.
C:\PG\postgresql\src\tools\msvcinstall
Invalid command line options.
Usage: install.bat targetdir
Fujii Masao masao.fu...@gmail.com writes:
Okay, so probably we need to change WAL replay of TRUNCATE so that
the index file is truncated to one containing only meta page instead of
empty one. That is, the WAL replay of TRUNCATE would need to call
index_build() after smgrtruncate() maybe.
That
I wrote:
As it stands, psqlscan.l has some external dependencies on the rest of
psql, but we could perhaps refactor some of those away, and provide dummy
implementations to satisfy others (eg pgbench could provide a dummy
GetVariable() that just always returns NULL).
So I'm imagining
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
Patch looks excellent now. No issues.
Found a typo which I have fixed in the attached patch.
Starting to look at this ...
The business with numbering lines from SELECT seems to me to be completely
nonsensical. In the first place, it fails
On 2015-07-03 18:49:31 +0200, Andres Freund wrote:
But the more interesting question is why that's not hhappening
today. RelationTruncateIndexes() does call the index_build() which
should end up WAL logging the index creation.
So that's because there's an XLogIsNeeded() preventing it.
Maybe
On Wed, Feb 25, 2015 at 11:37:24PM -0500, Stephen Frost wrote:
* Stephen Frost (sfr...@snowman.net) wrote:
I agree that it's great that we're catching issues prior to when the
feature is released and look forward to anything else you (or anyone
else!) finds.
I've pushed a fix for this.
пт, 3 июля 2015 г. в 19:30, Tom Lane t...@sss.pgh.pa.us:
So AFAICS, \ev and \sv should just number lines straightforwardly, with
1 being the first line of the CREATE command text. Am I missing
something?
Fixed. Now both \ev and \sv numbering lines starting with 1. New version
attached.
As
(although actually, why wouldn't we want to just implement variable
substitution exactly like it is in psql?
Pgbench variable substitution is performed when the script is run, not
while the file is being processed for being split, which is when a lexer
would be used. The situation is not
On 2015-07-03 19:14:26 +0200, Martijn van Oosterhout wrote:
Am I missing something. ISTM that if the truncate record was simply not
logged at all everything would work fine. The whole point is that the
table was created in this transaction and so if it exists the table on
disk must be the
On 2015-07-03 13:59:07 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
2) Replace relation forks, with the exception of the init fork which is
special anyway, with separate relfilenodes. Stored in seperate
columns in pg_class.
Different AMs have different fork needs; for heaps
On 07/03/2015 03:12 AM, Sawada Masahiko wrote:
Thanks. So we can choice the next master server using by checking the
progress of each server, if hot standby is enabled.
And a such procedure is needed even today replication.
I think that the #2 problem which is Josh pointed out seems to be
On 2015-07-03 19:02:29 +0200, Andres Freund wrote:
Maybe I'm just daft right now (35C outside, 32 inside, so ...), but I'm
right now missing how the whole skip wal logging if relation has just
been truncated optimization can ever actually be crashsafe unless we
use a new relfilenode (which we
On Fri, Jul 3, 2015 at 11:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
The optimization of TRUNCATE opereation that we can use when
CREATE TABLE and TRUNCATE are executed in the same transaction block
seems to cause the problem. In this case, only index
On 2015-07-04 01:39:42 +0900, Fujii Masao wrote:
Okay, so probably we need to change WAL replay of TRUNCATE so that
the index file is truncated to one containing only meta page instead of
empty one. That is, the WAL replay of TRUNCATE would need to call
index_build() after smgrtruncate()
Andres Freund wrote:
2) Replace relation forks, with the exception of the init fork which is
special anyway, with separate relfilenodes. Stored in seperate
columns in pg_class.
Different AMs have different fork needs; for heaps you want one main
fork, one VM, one fsm. But for indexes,
On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh gurj...@singh.im wrote:
On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Gregory Stark wrote:
I'm having trouble following what's going on with autovacuum and I'm
finding
the existing logging insufficient. In
Jim Nasby jim.na...@bluetreble.com writes:
On 7/3/15 2:33 AM, Heikki Linnakangas wrote:
On 07/03/2015 01:20 AM, Jim Nasby wrote:
Is there a way to determine the operator that resulted in calling the
operator function? I thought fcinfo-flinfo-fn_expr might get set to
the OpExpr, but seems it
Jan de Visser j...@de-visser.net writes:
Attached a new patch, rebased against the current head. Errors in
pg_hba.conf and pg_ident.conf are now also noticed.
I checked the documentation for pg_ctl reload, and the only place where
it's explained seems to be runtime.sgml and that description
On July 3, 2015 06:21:09 PM Tom Lane wrote:
Jan de Visser j...@de-visser.net writes:
Attached a new patch, rebased against the current head. Errors in
pg_hba.conf and pg_ident.conf are now also noticed.
I checked the documentation for pg_ctl reload, and the only place where
it's
On 2015-07-03 18:38:37 -0400, Tom Lane wrote:
Why exactly? The first truncation in the (sub)xact would have assigned a
new relfilenode, why do we need another one? The file in question will
go away on crash/rollback in any case, and no other transaction can see
it yet.
Consider:
BEGIN;
On Sat, Jul 4, 2015 at 2:44 AM, Andres Freund wrote:
This subthread is getting absurd, stopping here.
Yeah, I agree with Andres here, we are making a mountain of nothing
(Frenglish?). I'll send to the other thread some additional ideas soon
using a JSON structure.
--
Michael
--
Sent via
Martijn van Oosterhout klep...@svana.org writes:
With inserts the WAL records look as follows (relfilenodes changed):
...
And amazingly, the database cluster successfuly recovers and there's no
error now. So the problem is *only* because there is no data in the
table at commit time. Which
On 07/02/2015 08:48 AM, Kyotaro HORIGUCHI wrote:
- It was a problem when to give the first kick for async exec. It
is not in ExecInit phase, and ExecProc phase does not fit,
too. An extra phase ExecPreProc or something is too
invasive. So I tried pre-exec callback.
Any init-node can
On 2015-07-03 19:26:05 +0200, Andres Freund wrote:
On 2015-07-03 19:02:29 +0200, Andres Freund wrote:
Maybe I'm just daft right now (35C outside, 32 inside, so ...), but I'm
right now missing how the whole skip wal logging if relation has just
been truncated optimization can ever actually
Andres Freund and...@anarazel.de writes:
On 2015-07-03 19:26:05 +0200, Andres Freund wrote:
commit cab9a0656c36739f59277b34fea8ab9438395869
Author: Tom Lane t...@sss.pgh.pa.us
Date: Sun Aug 23 19:23:41 2009 +
Make TRUNCATE do truncate-in-place when processing a relation that was
On 7/3/15 2:33 AM, Heikki Linnakangas wrote:
On 07/03/2015 01:20 AM, Jim Nasby wrote:
Is there a way to determine the operator that resulted in calling the
operator function? I thought fcinfo-flinfo-fn_expr might get set to
the OpExpr, but seems it can be a FuncExpr even when called via an
Since apparently we're back to development work, I thought it was time
to share a patch implementing a few additional simple tricks to make
sorting text under a non-C locale even faster than in 9.5. These
techniques are mostly effective when values are physically clustered
together. This might be
On Wed, Jul 01, 2015 at 03:22:33AM -0400, Noah Misch wrote:
On Tue, Jun 30, 2015 at 09:45:08AM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Sun, Jun 28, 2015 at 07:00:14PM -0400, Tom Lane wrote:
Another idea would be to make a test during postmaster start to see
if
On July 3, 2015 06:21:09 PM Tom Lane wrote:
I wonder whether we should consider inventing similar views for
pg_hba.conf and pg_ident.conf.
(Apologies for the flurry of emails).
Was there not an attempt at a view for pg_hba.conf which ended in a lot of
bikeshedding and no decisions?
--
Sent
On July 3, 2015 09:24:36 PM Jan de Visser wrote:
On July 3, 2015 06:21:09 PM Tom Lane wrote:
BTW, this version of this patch neglects to update the comments in
miscadmin.h, and it makes the return convention for
ProcessConfigFileInternal completely unintelligible IMO; the inaccuracy
and
Attached a new patch, rebased against the current head. Errors in
pg_hba.conf and pg_ident.conf are now also noticed.
I checked the documentation for pg_ctl reload, and the only place where
it's explained seems to be runtime.sgml and that description is so
high-level that adding this new bit of
Michael Paquier michael.paqu...@gmail.com writes:
On Sat, May 2, 2015 at 9:53 PM, Fabien COELHO wrote:
Quick review: patches applies, make check is fine, all is well.
Thanks for the feedback, Fabien!
All the casting tests could be put in numeric.sql, as there are all
related to numeric and
Petr Korobeinikov pkorobeini...@gmail.com writes:
Fixed. Now both \ev and \sv numbering lines starting with 1. New version
attached.
Applied with a fair amount of mostly-cosmetic adjustment.
As I've already noticed that pg_get_viewdef() does not support full syntax
of creating or replacing
On Fri, Jul 03, 2015 at 07:21:21PM +0200, Andres Freund wrote:
On 2015-07-03 19:14:26 +0200, Martijn van Oosterhout wrote:
Am I missing something. ISTM that if the truncate record was simply not
logged at all everything would work fine. The whole point is that the
table was created in this
Andreas Karlsson andr...@proxel.se writes:
On 03/21/2015 01:19 PM, Julien Tachoires wrote:
I am confused by your fix. Wouldn't cleaner fix be to use
tbinfo-reltablespace rather than tbinfo-reltoasttablespace when
calling ArchiveEntry()?
Yes, doing this that way is cleaner. Here is a new
power 1,5 is almost certainly not right for all cases, but it is simple
and better.
It is better in some cases, as I've been told on my patch. If you have a
separate disk for WAL writes the power formula may just degrade
performance, or maybe not, or not too much, or it really should be a
On 07/03/2015 07:50 AM, Fabien COELHO wrote:
This doesn't behave correctly if you set -j to greater than -c, and also use
the rate limit option:
Indeed. v3 attached fixed the case when nthreads nclients.
Ok, committed. Thanks!
- Heikki
--
Sent via pgsql-hackers mailing list
Hello Andres,
In conclusion, and very egoistically, I would prefer if this patch could
wait for the checkpoint scheduling patch to be considered, as it would
basically invalidate the X00 hours of performance tests I ran:-)
These two patches target pretty independent mechanics. If you patch
On Fri, Jul 3, 2015 at 5:56 AM, Heikki Linnakangas wrote:
On 04/10/2015 01:46 PM, chenhj wrote:
I was about to commit the attached, but when I tested this between my
Windows 8.1 virtual machine and Linux host, I was not able to see any
performance difference. It may be because the case is
On 06/15/2015 09:12 PM, Fabien COELHO wrote:
v3 rebase (after pgbench moved to src/bin) and minor style tweaking.
v4 adds a fix to another progress timing issue:
Currently if pgbench/postgres get stuck somewhere, the report catches up
by repeating progresses several time in a row, which
On 3 July 2015 at 20:06, Andres Freund and...@anarazel.de wrote:
On 2015-07-02 23:56:16 +0300, Heikki Linnakangas wrote:
On 04/10/2015 01:46 PM, chenhj wrote:
Result(execute time):
default(8K), 7.370s
set SO_SNDBUF to 32K, 4.159s(the current
On Tue, Dec 02, 2014 at 11:32:27AM -0500, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Nov 27, 2014 at 2:03 AM, Stephen Frost sfr...@snowman.net wrote:
Alright, I've done the change to use the RangeVar from CopyStmt, but
also added a check wherein we verify
Hello,
This has been registered in the next 2015-09 CF since majority are in favor
of adding this multiple sync replication feature (with quorum/priority).
New patch will be submitted once we have reached a consensus on the design.
--
Beena Emerson
On 07/03/2015 01:20 AM, Jim Nasby wrote:
Is there a way to determine the operator that resulted in calling the
operator function? I thought fcinfo-flinfo-fn_expr might get set to
the OpExpr, but seems it can be a FuncExpr even when called via an
operator...
Don't think there is. Why do you
On 2015-07-02 23:56:16 +0300, Heikki Linnakangas wrote:
On 04/10/2015 01:46 PM, chenhj wrote:
Result(execute time):
default(8K), 7.370s
set SO_SNDBUF to 32K, 4.159s(the current implement)
set SO_SNDBUF to 64K, 2.875s
set SO_SNDBUF to 128K,
On 2015-06-07 13:44:08 -0700, Jeff Janes wrote:
I'd like to advocate for back-patching this to 9.0, 9.1, and 9.2. It has
run without problems for a while now, and it can be considered a bug that
systems with a very large number of objects cannot be upgraded in a
reasonable time.
In that
Indeed. v3 attached fixed the case when nthreads nclients.
Ok, committed. Thanks!
Thanks!
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 3, 2015 at 1:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 2 July 2015 at 16:30, Sawada Masahiko sawada.m...@gmail.com wrote:
Also, the flags of each heap page header might be set PD_ALL_FROZEN,
as well as all-visible
Is it possible to have VM bits set to frozen but not
On 04/28/2015 02:18 AM, Fabien COELHO wrote:
This patch removes the pgbench thread fork-emulation code and simplifies
things where possible, especially around pthread_create and pthread_join.
The stats collection for the report is done directly instead of using an
intermediate structure.
As a
On Fri, Jul 3, 2015 at 2:47 PM, Marco Atzeri marco.atz...@gmail.com wrote:
On 7/2/2015 5:16 PM, Dave Page wrote:
The PostgreSQL Global Development Group announces that the alpha
release of PostgreSQL 9.5, the latest version of the world's leading
open source database, is available today.
On Fri, Jul 03, 2015 at 02:34:44PM +0900, Fujii Masao wrote:
Hmm, for me it is 100% reproducable. Are you familiar with Docker? I
can probably construct a Dockerfile that reproduces it pretty reliably.
I could reproduce the problem in the master branch by doing
the following steps.
Thank
On Fri, Jul 3, 2015 at 2:47 PM, Marco Atzeri marco.atz...@gmail.com wrote:
On 7/2/2015 5:16 PM, Dave Page wrote:
The PostgreSQL Global Development Group announces that the alpha
release of PostgreSQL 9.5, the latest version of the world's leading
open source database, is available today.
On 2015/07/02 23:13, Kouhei Kaigai wrote:
To be honest, ISTM that it's difficult to do that simply and efficiently
for the foreign/custom-join-pushdown API that we have for 9.5. It's a
little late, but what I started thinking is to redesign that API so that
that API is called at
On Fri, Jul 3, 2015 at 3:14 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
I committed some of these that seemed like improvements on readability
grounds, but please just mark the rest as ignore in coverity.
Done. Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list
On 3 July 2015 at 06:38, Fabien COELHO coe...@cri.ensmp.fr wrote:
Hello Simon,
We could do better, but that is not a reason not to commit this, as is.
Commit, please.
My 0,02€: Please do not commit without further testing...
I've submitted a patch to improve checkpoint write
On 2015-07-03 07:38:15 +0200, Fabien COELHO wrote:
I've submitted a patch to improve checkpoint write scheduling, including X00
hours of performance test on various cases. This patch changes significantly
the load distribution over the whole checkpoint, and AFAICS has been tested
on rather
On Fri, Jul 3, 2015 at 12:18 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jul 3, 2015 at 6:54 AM, Josh Berkus j...@agliodbs.com wrote:
On 07/02/2015 12:44 PM, Andres Freund wrote:
On 2015-07-02 11:50:44 -0700, Josh Berkus wrote:
So there's two parts to this:
1. I need to ensure that
Hello,
TBH, I think that designing this as a hook-based solution is adding a whole
lot of complexity for no value. The hard parts of the problem are collecting
the raw data and making the results visible to users, and both of those
require involvement of the core code. Where is the benefit
On Fri, Jul 3, 2015 at 5:59 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Fri, Jul 3, 2015 at 12:18 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jul 3, 2015 at 6:54 AM, Josh Berkus j...@agliodbs.com wrote:
On 07/02/2015 12:44 PM, Andres Freund wrote:
On 2015-07-02 11:50:44 -0700,
On Fri, Jul 3, 2015 at 6:23 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jul 3, 2015 at 5:59 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
Yeah, quorum commit is helpful for minimizing data loss in comparison
with today replication.
But in this your case, how can we know which
On 05/27/2015 09:51 PM, Andrew Dunstan wrote:
On 05/27/2015 02:37 PM, Robert Haas wrote:
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de wrote:
Is it reasonable to add this patch to CommitFest now?
It's always reasonable to add a patch to the CommitFest if
On 2015-07-03 13:50:02 +0300, Heikki Linnakangas wrote:
As Tom pointed out, you need the full lexer to do this correctly. You can
argue that something that handles the most common cases is enough, but
realistically, by the time you've handled all the common cases correctly,
you've just
Sawada Masahiko wrote:
I think that the #2 problem which is Josh pointed out seems to be solved;
1. I need to ensure that data is replicated to X places.
2. I need to *know* which places data was synchronously replicated
to when the master goes down.
And we can address #1 problem
On 2015/07/03 15:32, Kouhei Kaigai wrote:
On 2015/07/02 23:13, Kouhei Kaigai wrote:
To be honest, ISTM that it's difficult to do that simply and efficiently
for the foreign/custom-join-pushdown API that we have for 9.5. It's a
little late, but what I started thinking is to redesign that API so
On 06/21/2015 11:12 AM, Fabien COELHO wrote:
Hello Josh,
Add backslash continuations to pgbench custom scripts.
[...]
IMHO this approach is the best compromise.
I don't personally agree. I believe that it it worth breaking backwards
compatibility to support line breaks in pgbench
On Thu, Apr 2, 2015 at 3:24 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 25, 2015 at 9:46 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
http://www.postgresql.org/message-id/ca+tgmozm+-0r7h0edpzzjbokvvq+gavkchmno4fypveccw-...@mail.gmail.com
I like the idea of the
On 2015-07-02 14:54:19 -0700, Josh Berkus wrote:
On 07/02/2015 12:44 PM, Andres Freund wrote:
On 2015-07-02 11:50:44 -0700, Josh Berkus wrote:
So there's two parts to this:
1. I need to ensure that data is replicated to X places.
2. I need to *know* which places data was synchronously
Hello Heikki,
I'm not clear on why we'd need a full SQL lexer.
Attached is a without lexer version which does ;-terminated SQL commands
and \-continuated meta commands (may be useful for \shell and long \set
expressions).
As Tom pointed out, you need the full lexer to do this correctly.
On Thu, Jul 2, 2015 at 8:49 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, May 21, 2015 at 10:19 PM, Robert Haas robertmh...@gmail.com
wrote:
On Sat, Mar 21, 2015 at 2:30 PM, Thom Brown t...@linux.com wrote:
Looks like one of the patches I applied is newer than the one in your
I'm pretty clearly in favor of doing correct lexing. I think we should
generalize that and make it reusable. psql has it's own hacked up
version already, there seems little point in having variedly good copies
around.
I must admit that I do not know how to share lexer rules but have
82 matches
Mail list logo
