On Wed, Feb 4, 2015 at 10:03 AM, Peter Geoghegan wrote:
> On Wed, Feb 4, 2015 at 9:54 AM, Heikki Linnakangas
> wrote:
>> I had compiled with -O0, but without assertions. I tried now again with -O3.
>> It's been running for about 10 minutes now, and I haven't seen any errors.
>
> Did you run with
Missed adding "pgsql-hackers" group while replying.
Regards,
Venkata Balaji N
On Thu, Feb 5, 2015 at 12:48 PM, Venkata Balaji N wrote:
>
>
> On Fri, Jan 30, 2015 at 7:58 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 01/30/2015 04:48 AM, Venkata Balaji N wrote:
>>
>>> I perf
On Wed, Feb 4, 2015 at 9:40 PM, Robert Haas wrote:
>
> On Fri, Jan 30, 2015 at 12:08 PM, Robert Haas
wrote:
> > Here's a new version. Andres mentioned previously that he thought it
> > would be a good idea to commit the addition of
> > BackgroundWorkerInitializeConnectionByOid() separately, as h
On Thu, Feb 5, 2015 at 3:11 AM, Josh Berkus wrote:
>
> On 02/04/2015 12:06 PM, Robert Haas wrote:
> > On Wed, Feb 4, 2015 at 1:05 PM, Josh Berkus wrote:
> >> Let me push "max_wal_size" and "min_wal_size" again as our new
parameter
> >> names, because:
> >>
> >> * does what it says on the tin
> >>
On Tue, Jan 20, 2015 at 12:57 PM, Michael Paquier
wrote:
> On Tue, Jan 20, 2015 at 1:56 AM, Andres Freund wrote:
>> On 2015-01-19 17:16:11 +0900, Michael Paquier wrote:
>>> On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
>>> wrote:
>>> > On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund
>>> > wr
On 2/4/15 6:16 PM, David Steele wrote:
On 2/4/15 3:06 PM, Robert Haas wrote:
Hmmm, I see your point. I spend a lot of time on AWS and in
container-world, where disk space is a lot more constrained. However,
it probably makes more sense to recommend non-default settings for that
environment, si
Tom Lane-2 wrote
> Kyotaro HORIGUCHI <
> horiguchi.kyotaro@.co
> > writes:
>> The phrase "{INDEX | TABLE |..} name" seems to me indivisible as
>> target specification. IMHO, the options for VACUUM and so is
>> placed *just after* command name, not *before* the target.
>
>> If this is right, the
On 04/02/15 19:02, Fujii Masao wrote:
> On Wed, Feb 4, 2015 at 5:27 PM, Ian Barwick wrote:
>> Hi
>>
>> A superfluous '/' in an xref tag is producing an unintended '>'
>> in the "Warning" box on this page:
>>
>>
>> http://www.postgresql.org/docs/current/interactive/sql-createtablespace.html
>
>
On Thu, Feb 5, 2015 at 10:20 AM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Wed, 4 Feb 2015 19:22:39 +0900, Fujii Masao wrote
> in
>> On Wed, Feb 4, 2015 at 4:58 PM, Kyotaro HORIGUCHI
>> wrote:
>> > I'm very sorry for confused report. The problem found in 9.4.0
>> > and the diagnosis was mistake
Andrew Dunstan writes:
> I'm not terribly keen on this. If you don't like "binworld", how about
> "world-no-docs"?
[ shrug... ] Doesn't bother me particularly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Kyotaro HORIGUCHI writes:
> The phrase "{INDEX | TABLE |..} name" seems to me indivisible as
> target specification. IMHO, the options for VACUUM and so is
> placed *just after* command name, not *before* the target.
> If this is right, the syntax would be like this.
> REINDEX [ (option [, optio
Hello,
At Wed, 4 Feb 2015 19:22:39 +0900, Fujii Masao wrote in
> On Wed, Feb 4, 2015 at 4:58 PM, Kyotaro HORIGUCHI
> wrote:
> > I'm very sorry for confused report. The problem found in 9.4.0
> > and the diagnosis was mistakenly done on master.
> >
> > 9.4.0 has no problem of feedback delay cau
On 02/04/2015 06:53 PM, Tom Lane wrote:
Or maybe use a make variable, like NO_DOC. I think that's preferable to
adding more targets.
Unless we can come up with a new target name that obviously means
"world minus docs", the make-variable idea may be the best.
I'm no
Hello,
> As per discussion, it seems to good with
> REINDEX { INDEX | TABLE | etc } name [ ( option [, option ...] ) ]
> or
> REINDEX { INDEX | TABLE | etc } [ (option [, optoin ...] ) ] name
> i.g., the options of reindex(VERBOSE and FORCE) are put at before or
> after object name.
>
> Because o
On Tue, Feb 2, 2015 at 01:06 AM, Andres Freund wrote:
> A first (not actually that quick :() look through the patches to see
> what actually happened in the last months. I didn't keep up with the
> thread.
So, let me get this out of the way: This is the first in-depth
technical review that this w
On 2/4/15 3:06 PM, Robert Haas wrote:
>> Hmmm, I see your point. I spend a lot of time on AWS and in
>> container-world, where disk space is a lot more constrained. However,
>> it probably makes more sense to recommend non-default settings for that
>> environment, since it requires non-default se
Peter Eisentraut writes:
> On 2/4/15 2:24 PM, Andrew Dunstan wrote:
>> On 02/03/2015 10:00 AM, David Fetter wrote:
>>> On 02/03/2015 08:55 AM, Kevin Grittner wrote:
I realize this is slightly OT, but I wonder if it might be worth having
targets that build and install everything but the d
I applied this patch to REL9_4_STABLE, and I was able to connect to a
foreign database (redshift, actually).
the basic outline of the test is below, names changed to protect my
employment.
create extension if not exists postgres_fdw;
create server redshift_server foreign data wrapper postgres_fd
On Thu, Feb 5, 2015 at 5:31 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> (BTW, why do you not leave a blank line between quoted text and your
>> responses?)
>
> +1. That vertical space is really helpful, at least to me.
Will do if people here are better with that.
On 02/04/2015 12:06 PM, Robert Haas wrote:
> On Wed, Feb 4, 2015 at 1:05 PM, Josh Berkus wrote:
>> Let me push "max_wal_size" and "min_wal_size" again as our new parameter
>> names, because:
>>
>> * does what it says on the tin
>> * new user friendly
>> * encourages people to express it in MB, not
On 2/3/15 11:53 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Note also that you only need to present the release notes from the
>> latest stable release branch on the web site, as opposed to
>> documentation for each branch.
>
> Yeah, JD suggested the same upthread. If we went over to a sep
On 2/4/15 2:24 PM, Andrew Dunstan wrote:
>
> On 02/03/2015 10:00 AM, David Fetter wrote:
>> On Tue, Feb 03, 2015 at 09:08:45AM -0500, Andrew Dunstan wrote:
>>> On 02/03/2015 08:55 AM, Kevin Grittner wrote:
I run `make -s -j4 world` on my i7 fairly often, and it is often
the doc build tha
* Robert Haas (robertmh...@gmail.com) wrote:
> (BTW, why do you not leave a blank line between quoted text and your
> responses?)
+1. That vertical space is really helpful, at least to me.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Feb 4, 2015 at 8:08 AM, Stephen Frost wrote:
> > Apologies for the confusion- the client isn't using it to determine if
> > there's activity. They're using it exactly as it's intended, as I
> > understand it- to check and see if the number of
On Mon, Feb 2, 2015 at 10:28 PM, Magnus Hagander
wrote:
> On Mon, Feb 2, 2015 at 10:06 PM, Robert Haas
> wrote:
>
>>
>>
>>
> When I clicked on "attach thread" without having logged in, it took me
>> to a bad URL. When I clicked on it after having logged in, it
>>
>
> Clearly a bug.
>
bug has
On Wed, Feb 4, 2015 at 1:05 PM, Josh Berkus wrote:
> Let me push "max_wal_size" and "min_wal_size" again as our new parameter
> names, because:
>
> * does what it says on the tin
> * new user friendly
> * encourages people to express it in MB, not segments
> * very different from the old name, so
On 02/03/2015 10:00 AM, David Fetter wrote:
On Tue, Feb 03, 2015 at 09:08:45AM -0500, Andrew Dunstan wrote:
On 02/03/2015 08:55 AM, Kevin Grittner wrote:
I run `make -s -j4 world` on my i7 fairly often, and it is often
the doc build that I wind up waiting for at the end.
I realize this is sli
On 02/04/2015 06:48 AM, Robert Haas wrote:
> Anyway, I'm not talking about deriving the GUC, I'm talking about
> deriving the WAL level which is currently controlled solely by the
> GUC. We do something like this for full-page writes. Even if you in
> general have full_page_writes=off, trying to
On 02/04/2015 09:28 AM, Robert Haas wrote:
> On Tue, Feb 3, 2015 at 4:18 PM, Josh Berkus wrote:
That's different from our current checkpoint_segments setting. With
checkpoint_segments, the documented formula for calculating the disk usage
is (2 + checkpoint_completion_target) * chec
On Wed, Feb 4, 2015 at 9:54 AM, Heikki Linnakangas
wrote:
> I had compiled with -O0, but without assertions. I tried now again with -O3.
> It's been running for about 10 minutes now, and I haven't seen any errors.
Did you run with an artificially high XID burn rate (i.e. did you also
apply Jeff's
On 02/03/2015 08:17 PM, Peter Geoghegan wrote:
On Tue, Feb 3, 2015 at 2:05 AM, Heikki Linnakangas
wrote:
TRAP: FailedAssertion("!(node->spec != SPEC_INSERT || node->arbiterIndex !=
((Oid) 0))", File: "nodeModifyTable.c", Line: 1619)
Is that just because of the hack in parse_clause.c?
Yes. I
This message was caused by a bug in the commitfest app. The bug has been
found and fixed.
Apologies for that one slipping through.
//Magnus
On Fri, Jan 30, 2015 at 7:21 PM, wrote:
> From nobody Fri Jan 30 18:20:23 2015
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-T
On Tue, Feb 3, 2015 at 4:18 PM, Josh Berkus wrote:
>>> That's different from our current checkpoint_segments setting. With
>>> checkpoint_segments, the documented formula for calculating the disk usage
>>> is (2 + checkpoint_completion_target) * checkpoint_segments * 16 MB. That's
>>> a lot less i
Shay Rojansky wrote
> The use case would be sending a query which might modify or might not
> (e.g.
> UPDATE), but we know that the user is uninterested in any result row.
How do you intend to gain this knowledge if the query doesn't structure
itself so that it does or does not return actual rows?
> searchable version of the release notes.
Would be a wonderful thing if it happened.
Segregating the content by version would help -- finding lots of notes
about version 7 & 8 when I'm running 9.3/4 helps not at all.
--
Steven Lembark 3646 Flora P
> Disk space isn't the only consideration here; if it were I'd not be
> concerned about this. Processing time is an issue, and so is distribution
> size, and so is the length of the manual if someone decides to print it
> on dead trees. I also live in fear of the day that we hit some hard-to-
>
> -1. I find it very useful to be able to go back through all the
> release notes using grep, and have done so on multiple occasions. It
> sounds like this policy would make that harder, and I don't see what
> we get out of of it. It doesn't bother me that the SGML documentation
> of the releas
Heikki Linnakangas writes:
> ... (there's a call to _bt_relbuf in contrib/pgstattuple, but it
> shouldn't really be used in 3rd party extensions)
Meh. I wouldn't say that. I agree that the coding in pgstat_btree_page
pretty much sucks, but on grounds of lack of consistency rather than that
thi
Kevin Grittner writes:
> I ran across this function in nbtpage.c:
> /*
> * _bt_relbuf() -- release a locked buffer.
> *
> * Lock and pin (refcount) are both dropped.
> */
> void
> _bt_relbuf(Relation rel, Buffer buf)
> {
> UnlockReleaseBuffer(buf);
> }
> Would anyone object to me removing
Heikki Linnakangas wrote:
> On 02/04/2015 04:49 PM, Kevin Grittner wrote:
>> Would anyone object to me removing the first parameter
>> (including, obviously, in all references in our code tree)?
>
> No objection, although I have to wonder why bother?
Because I ran across it while trying to work
On 02/04/2015 04:49 PM, Kevin Grittner wrote:
I ran across this function in nbtpage.c:
/*
* _bt_relbuf() -- release a locked buffer.
*
* Lock and pin (refcount) are both dropped.
*/
void
_bt_relbuf(Relation rel, Buffer buf)
{
UnlockReleaseBuffer(buf);
}
Would anyone object to me re
On Wed, Feb 4, 2015 at 2:44 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On 2/3/15 5:08 PM, Tom Lane wrote:
>>> Jim Nasby writes:
VACUUM puts the options before the table name, so ISTM it'd be best to
keep that with REINDEX. Either REINDEX (options) {INDEX | ...} or
REINDEX {INDEX |
Heikki Linnakangas writes:
> While looking at the memory leaks in ecpg that Coverity warned about and
> Michael just fixed, I started wondering if the code is ever used.
Michael Meskes would be the authority on that question, so I've cc'd
him to make sure he notices this thread ...
> The leaks
Andres Freund writes:
> On 2015-02-03 11:00:43 -0500, Robert Haas wrote:
>> Could we, maybe, even make it a derived value rather than one that is
>> explicitly configured? Like, if you set max_wal_senders>0, you
>> automatically get
>> wal_level=hot_standby?
> Our experience with derived gucs i
I ran across this function in nbtpage.c:
/*
* _bt_relbuf() -- release a locked buffer.
*
* Lock and pin (refcount) are both dropped.
*/
void
_bt_relbuf(Relation rel, Buffer buf)
{
UnlockReleaseBuffer(buf);
}
Would anyone object to me removing the first parameter (including,
obviously, in
On Wed, Feb 4, 2015 at 8:44 AM, Andres Freund wrote:
>> I think my vote is to maintain the status quo. What you're basically
>> proposing to do is ship the system half-configured for replication,
>> and I don't see the point of that.
>
> Not only replication, but also hot backup.
>
> I think we s
On Wed, Feb 4, 2015 at 8:08 AM, Stephen Frost wrote:
> Apologies for the confusion- the client isn't using it to determine if
> there's activity. They're using it exactly as it's intended, as I
> understand it- to check and see if the number of rollbacks is
> signifigant compared to the number of
On Wed, Feb 4, 2015 at 7:00 AM, Michael Paquier
wrote:
> Robert Haas wrote:
>> I wrote:
>>> src, dst and ctx are created respectively from mbuf_create_from_data,
>>> mbuf_create and pgp_init which never return NULL and they are palloc'd
>>> all the time. I think that we could simplify things with
On 2015-02-03 11:00:43 -0500, Robert Haas wrote:
> On Tue, Feb 3, 2015 at 7:43 AM, Andres Freund wrote:
> > I think these days there's no reason for the split between the archive
> > and hot_standby wal levels. The split was made out of volume and
> > stability concerns. I think we can by now be c
While looking at the memory leaks in ecpg that Coverity warned about and
Michael just fixed, I started wondering if the code is ever used.
The leaks were in the code that takes a host variable, and converts it
into a string for sending to the server as a query parameter. In
particular, it was
* Guillaume Lelarge (guilla...@lelarge.info) wrote:
> 2015-02-04 6:37 GMT+01:00 Tom Lane :
> > Stephen Frost writes:
> > No, somebody should fix check_postgres to count rollbacks as well as
> > commits as activity (as they obviously are).
> >
> Well, actually, no. This is a commit ratio, not an ac
On 02/03/2015 02:45 PM, Michael Paquier wrote:
On Tue, Feb 3, 2015 at 5:35 PM, Heikki Linnakangas
wrote:
>I think there are more similar leaks nearby. After the first hunk, there's
>another if-check with "return false" that also leaks mallocedval. Right
>after the two other hunks, if the ecpg_
Robert Haas wrote:
> I wrote:
>> src, dst and ctx are created respectively from mbuf_create_from_data,
>> mbuf_create and pgp_init which never return NULL and they are palloc'd
>> all the time. I think that we could simplify things with the patch
>> attached, note that I added an assertion for corr
On 2/4/15 12:36 PM, Stephen R. van den Berg wrote:
Marko Tiikkaja wrote:
This seems to be a common pattern, and I think it's a *huge* mistake
to specify maxrows=1 and/or ignore rows after the first one in the
driver layer. If the user says "give me the only row returned by
I guess it depends
Marko Tiikkaja wrote:
>On 2/4/15 12:13 PM, Stephen R. van den Berg wrote:
>>If you know beforehand the query might generate more than one row (SELECT)
>>yet you also know that you are not interested in those, then maxrows=1
>>is best; then again, modifying the query to include a LIMIT 1 is even
>>b
On 2/4/15 12:27 PM, Andres Freund wrote:
On 2015-02-04 12:23:51 +0100, Marko Tiikkaja wrote:
On 2/4/15 12:13 PM, Stephen R. van den Berg wrote:
If you know beforehand the query might generate more than one row (SELECT)
yet you also know that you are not interested in those, then maxrows=1
is be
On 2/4/15 12:31 PM, Andres Freund wrote:
On 2015-02-04 12:25:04 +0100, Marko Tiikkaja wrote:
On 2/4/15 12:17 PM, Stephen R. van den Berg wrote:
I believe he's talking about the network protocol of postgreSQL, not
about query optimisation (as you do).
I don't believe so.
Did you read the ori
On 2015-02-04 12:25:04 +0100, Marko Tiikkaja wrote:
> On 2/4/15 12:17 PM, Stephen R. van den Berg wrote:
> >Andres Freund wrote:
> >>On 2015-02-03 12:26:33 +0100, Shay Rojansky wrote:
> >>>find a way to execute a query but without fetching any rows. The Execute
> >>>message has a maximum result-row
On 2015-02-04 12:23:51 +0100, Marko Tiikkaja wrote:
> On 2/4/15 12:13 PM, Stephen R. van den Berg wrote:
> >If you know beforehand the query might generate more than one row (SELECT)
> >yet you also know that you are not interested in those, then maxrows=1
> >is best; then again, modifying the quer
On 2/4/15 12:17 PM, Stephen R. van den Berg wrote:
Andres Freund wrote:
On 2015-02-03 12:26:33 +0100, Shay Rojansky wrote:
find a way to execute a query but without fetching any rows. The Execute
message has a maximum result-row count, but zero is documented to mean
"fetch all rows".
Is this
On 2/4/15 12:13 PM, Stephen R. van den Berg wrote:
If you know beforehand the query might generate more than one row (SELECT)
yet you also know that you are not interested in those, then maxrows=1
is best; then again, modifying the query to include a LIMIT 1 is even
better, in which case maxrows
On 2015-02-04 12:17:23 +0100, Stephen R. van den Berg wrote:
> Andres Freund wrote:
> >On 2015-02-03 12:26:33 +0100, Shay Rojansky wrote:
> >> find a way to execute a query but without fetching any rows. The Execute
> >> message has a maximum result-row count, but zero is documented to mean
> >> "f
Andres Freund wrote:
>On 2015-02-03 12:26:33 +0100, Shay Rojansky wrote:
>> find a way to execute a query but without fetching any rows. The Execute
>> message has a maximum result-row count, but zero is documented to mean
>> "fetch all rows".
>Is this really a relevant optimization? If the user d
Shay Rojansky wrote:
>I'm working on the Npgsql, the .NET driver for PostgreSQL, and am trying to
>find a way to execute a query but without fetching any rows. The Execute
>message has a maximum result-row count, but zero is documented to mean
>"fetch all rows".
>The use case would be sending a qu
Jim Nasby wrote:
>Rather than trying to wedge this into a heap page, ISTM it'd be
>better to use a fork. Presumably if you're storing regular tuples
>that have the essential data from pg_class, pg_attribute (and maybe
>pg_type).
Well, three things:
- The information preferably is present in the sa
On Wed, Feb 4, 2015 at 4:58 PM, Kyotaro HORIGUCHI
wrote:
> I'm very sorry for confused report. The problem found in 9.4.0
> and the diagnosis was mistakenly done on master.
>
> 9.4.0 has no problem of feedback delay caused by slow xlog
> receiving on pg_basebackup mentioned in the previous mail. B
On Wed, Feb 4, 2015 at 5:27 PM, Ian Barwick wrote:
> Hi
>
> A superfluous '/' in an xref tag is producing an unintended '>'
> in the "Warning" box on this page:
>
> http://www.postgresql.org/docs/current/interactive/sql-createtablespace.html
I found that logicaldecoding.sgml also has the same t
2015-02-04 6:37 GMT+01:00 Tom Lane :
> Stephen Frost writes:
> > All,
> > We recently had a client complain that check_postgres' commitratio
> > check would alert about relatively unused databases. As it turns
> > out, the reason for this is because they automate running pg_dump
> > agai
Thank you for your comment.
Sorry for the silly typo in the subject.
Tue, 03 Feb 2015 10:12:12 -0500, Tom Lane wrote in
<2540.1422976...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > Most of OID types has reg* OID types. Theses are very convenient
> > when looking into system catalog/views, b
Hi
A superfluous '/' in an xref tag is producing an unintended '>'
in the "Warning" box on this page:
http://www.postgresql.org/docs/current/interactive/sql-createtablespace.html
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
I'm very sorry for confused report. The problem found in 9.4.0
and the diagnosis was mistakenly done on master.
9.4.0 has no problem of feedback delay caused by slow xlog
receiving on pg_basebackup mentioned in the previous mail. But
the current master still has this problem.
regards,
At Mon, 02
71 matches
Mail list logo
