Jim Nasby 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 can be a Fun
On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh 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
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?
--
Sen
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
>
On July 3, 2015 06:21:09 PM Tom Lane wrote:
> Jan de Visser 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 seem
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 pgsq
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 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 this b
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 b
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
ope
On 3 July 2015 at 20:49, David Rowley wrote:
> On 3 July 2015 at 20:06, Andres Freund wrote:
>
>>
>> I've tested the patch just connecting to a database running on localhost
> and I'm not getting much of a speedup. Perhaps 1%, if that's not noise. I
> don't have enough hardware here to have clie
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
Andres Freund writes:
> On 2015-07-03 19:26:05 +0200, Andres Freund wrote:
>> commit cab9a0656c36739f59277b34fea8ab9438395869
>> Author: Tom Lane
>> Date: Sun Aug 23 19:23:41 2009 +
>>
>> Make TRUNCATE do truncate-in-place when processing a relation that was
>> created
>> or previously tr
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 ac
Jan de Visser 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 is so
> high-lev
Andreas Karlsson 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 version
Michael Paquier 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 that would avoid
On Fri, Jul 3, 2015 at 4:47 PM, I wrote:
> 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 descript
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 fu
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 ca
Martijn van Oosterhout 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 indicates that
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
Petr Korobeinikov 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 views.
Oh? If th
On 04/21/2015 04:02 PM, Michael Paquier wrote:
On Tue, Apr 21, 2015 at 4:33 PM, Asif Naeem wrote:
The v2 patch looks good to me, just a minor concern on usage message i.e.
C:\PG\postgresql\src\tools\msvc>install
Invalid command line options.
Usage: "install.bat [installtype]"
installtype: c
пт, 3 июля 2015 г. в 19:30, Tom Lane :
> 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 I've alrea
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 t
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 b
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 (whic
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 c
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; f
On Fri, Jul 03, 2015 at 12:53:56PM -0400, Tom Lane wrote:
> Fujii Masao 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
>
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
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
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
Fujii Masao 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 seems completely
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() ma
(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 the
On Fri, Jul 3, 2015 at 11:52 PM, Tom Lane wrote:
> Fujii Masao 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
Jeevan Chalke 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 to allow for views containing
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 sym
On 2015-07-03 15:50, Michael Paquier wrote:
On Thu, Jul 2, 2015 at 11:16 PM, Petr Jelinek 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
in
Fujii Masao 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 logged because wal_le
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 al
Fabien COELHO 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 how to shar
On Fri, Jul 3, 2015 at 3:01 PM, Martijn van Oosterhout
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 reproduc
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
wrote:
Is it reasonable to add this patch to CommitFest now?
It's always reasonable to add a patch
The home-grown lexer is missing e.g. dollar-quoting support, so this is not
be parsed correctly:
do $$
begin
...
end;
$$;
That would be very nice to handle correctly, I've used DO-blocks in pgbench
scripts many times, and it's a pain to have to write them in a single line.
Attached is a
On Thu, Jul 2, 2015 at 11:16 PM, Petr Jelinek 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 by Heikki previo
On Thu, Jul 2, 2015 at 8:02 PM, Fujii Masao 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 extension.
>
> IST
On 7/3/2015 8:19 AM, Michael Paquier wrote:
On Fri, Jul 3, 2015 at 2:47 PM, Marco Atzeri wrote:
On 7/2/2015 5:16 PM, Dave Page wrote:
-lldap
hstore_plperl.o: In function `hstore_to_plperl':
/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1
/contrib/hstore_plper
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 wrote:
> >
> > On Wed, Mar 25, 2015 at 9:46 PM, Fabrízio de Royes Mello
> > wrote:
> > >
> http://www.postgresql.org/message-id/ca+tgmozm+-0r7h0edpzzjbokvvq+g
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
different
On Thu, Jul 2, 2015 at 8:49 AM, Amit Kapila wrote:
>
> On Thu, May 21, 2015 at 10:19 PM, Robert Haas
wrote:
> >
> > On Sat, Mar 21, 2015 at 2:30 PM, Thom Brown wrote:
> > > Looks like one of the patches I applied is newer than the one in your
list:
> > >
> > > HEAD Commit-id: 13a10c0ccd984643ef8
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. Y
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
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 proble
On Thu, Apr 2, 2015 at 3:24 PM, Robert Haas wrote:
>
> On Wed, Mar 25, 2015 at 9:46 PM, Fabrízio de Royes Mello
> wrote:
> >
http://www.postgresql.org/message-id/ca+tgmozm+-0r7h0edpzzjbokvvq+gavkchmno4fypveccw-...@mail.gmail.com
>
> I like the idea of the feature a lot, but the proposal to which
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 re-i
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 statements
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
wrote:
Is it reasonable to add this patch to CommitFest now?
It's always reasonable to add a patch to the CommitFest if you would
like for it to be rev
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 Fri, Jul 3, 2015 at 6:23 PM, Fujii Masao wrote:
> On Fri, Jul 3, 2015 at 5:59 PM, Sawada Masahiko 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 server we should use as
>> the next maste
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 benefi
On Fri, Jul 3, 2015 at 5:59 PM, Sawada Masahiko wrote:
> On Fri, Jul 3, 2015 at 12:18 PM, Fujii Masao wrote:
>> On Fri, Jul 3, 2015 at 6:54 AM, 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
On Fri, Jul 3, 2015 at 12:18 PM, Fujii Masao wrote:
> On Fri, Jul 3, 2015 at 6:54 AM, 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
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 re
On 3 July 2015 at 20:06, Andres Freund 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 implement)
> > >
On Fri, Jul 3, 2015 at 1:23 AM, Simon Riggs wrote:
> On 2 July 2015 at 16:30, Sawada Masahiko 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 visible?
>
> The description makes
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 look
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 128
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 h
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 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 c
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 we
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 (pgsql-hacke
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
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 ne
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 wrote:
> > > Alright, I've done the change to use the RangeVar from CopyStmt, but
> > > also added a check wherein we verify that the rel
78 matches
Mail list logo
