Re: Andres Freund 2013-02-18 20130218213711.ga1...@awork2.anarazel.de
On 2013-02-14 10:02:13 -0800, Josh Berkus wrote:
- Please suggest project ideas for GSOC
pg_upgrade support for debian's pg_upgradecluster
We'd need Peter to be the student for that one :)
Robert Haas robertmh...@gmail.com writes:
Well, there's this, upon which we surely have not achieved consensus:
http://www.postgresql.org/message-id/ca+tgmobq6ngsxguihwqcygf0q+7y9zhnerepo3s1vswkknw...@mail.gmail.com
Sub-Transaction Handling. I fail to come up with a regression test
showing any
On Monday, February 18, 2013 8:06 PM Boszormenyi Zoltan wrote:
On 2013-01-29 11:15 keltezéssel, Magnus Hagander írta:
On Thu, Jan 24, 2013 at 7:04 AM, Hari Babu wrote:
On Wed, Jan 23, 2013 11:48 PM, Magnus Hagander wrote:
On Wed, Jan 23, 2013 at 10:18 AM, Hari Babu wrote:
Test scenario to
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Alvaro Herrera wrote:
I have pushed it now. Further testing, of course, is always
welcome.
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodondt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodondt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might have broken something.
Hmmm, interesting. A single
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Amit Kapila
Sent: Monday, February 18, 2013 6:38 PM
To: 'Heikki Linnakangas'
Cc: 'Phil Sorber'; 'Alvaro Herrera'; 'Magnus Hagander'; 'PostgreSQL-
development'
On Sat, Feb 16, 2013 at 11:42 AM, Andres Freund and...@2ndquadrant.com wrote:
Given that there have been wishes to support something like b) for quite
some time, independent from logical decoding, it seems like a good idea
to add support for it. Its e.g. useful for avoiding repeated detoasting
On Mon, Feb 18, 2013 at 4:48 PM, Kevin Grittner kgri...@ymail.com wrote:
This should allow me to simplify the code a little bit and move the
RMV step to the very end. That may have some advantages when users
want to start using the database while MVs are being populated.
In the department of
On Sun, Feb 17, 2013 at 4:12 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Well, a list of object OIDs is of exactly zero use once the command
has been carried out. So I don't think that that represents a useful
or even very testable feature on its own, if there's no provision to
fire
On 2013-02-19 08:48:05 -0500, Robert Haas wrote:
On Sat, Feb 16, 2013 at 11:42 AM, Andres Freund and...@2ndquadrant.com
wrote:
Given that there have been wishes to support something like b) for quite
some time, independent from logical decoding, it seems like a good idea
to add support
On Mon, Feb 18, 2013 at 10:42 AM, Merlin Moncure mmonc...@gmail.com wrote:
if you wanted to. And yes, I absolutely think this is superior to
cluttering the public namespace with xml specific verbage, and could
be extended to other formats. Look at the other way: we currently
have
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Robert Haas
Sent: 19 February 2013 15:05
To: Merlin Moncure
Cc: David E. Wheeler; PostgreSQL-development Hackers
The argument for removing json_ prefix is that when
On Tue, Feb 19, 2013 at 9:00 AM, Andres Freund and...@2ndquadrant.com wrote:
So the other way that we could do this is to use something that's the
same size as a TOAST pointer but has different content - the
seemingly-obvious choice being va_toastrelid == 0.
Unfortunately that would mean you
2013/2/19 Petr Jelinek pjmo...@pjmodos.net:
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Robert Haas
Sent: 19 February 2013 15:05
To: Merlin Moncure
Cc: David E. Wheeler; PostgreSQL-development Hackers
The
2013/2/19 Robert Haas robertmh...@gmail.com:
In the department of crazy ideas, what about having pg_dump NEVER
refresh ANY materialized views?
It's true that the job of pg_dump and pg_restore is to put the new
database in the same state that the old database was in, but I think
you could
On 2013-02-19 09:12:02 -0500, Robert Haas wrote:
On Tue, Feb 19, 2013 at 9:00 AM, Andres Freund and...@2ndquadrant.com wrote:
So the other way that we could do this is to use something that's the
same size as a TOAST pointer but has different content - the
seemingly-obvious choice being
On Tue, Feb 19, 2013 at 8:04 AM, Robert Haas robertmh...@gmail.com wrote:
The argument for removing json_ prefix is that when function behaviors
are unambiguously controlled by the arguments, decorating the function
name to match the input argument is unnecessary verbosity.
I've come to value
On Thu, Feb 14, 2013 at 4:08 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Hi all,
Please find attached a new set of 3 patches for REINDEX CONCURRENTLY (v11).
- 20130214_1_remove_reltoastidxid.patch
- 20130214_2_reindex_concurrently_v11.patch
-
On Mon, Feb 18, 2013 at 8:27 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
backupStartPoint is set, which signals recovery to wait for an end-of-backup
record, until the system is considered consistent. If the backup is taken
from a hot standby, backupEndPoint is set, instead of
On 2/19/13 8:54 AM, Robert Haas wrote:
In the department of crazy ideas, what about having pg_dump NEVER
refresh ANY materialized views?
It might be useful to have an option for this, but I don't think it
should be the default. The default should be that the new database is
ready to go.
Then
Dne 19.02.2013 11:27, Tom Lane napsal:
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodondt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might have broken
On Feb 19, 2013, at 6:11 AM, Petr Jelinek pjmo...@pjmodos.net wrote:
some of the points you raise are valid, but in my (minority) opinion
overloading creates more problems than it solves. You're not going to
convince me that get() is *ever* a good name for a function - you might as
well call
On Thu, Feb 14, 2013 at 4:02 PM, Josh Berkus j...@agliodbs.com wrote:
[...]
- Please suggest project ideas for GSOC
- Students seeing this -- please speak up if you have projects you plan
to submit.
I would like to propose implement a way to track creation times to database
objects. This
I've come to value greppability of source code pretty highly. I think
that
some of the points you raise are valid, but in my (minority) opinion
overloading creates more problems than it solves. You're not going to
convince me that get() is *ever* a good name for a function - you might as
2013/2/19 Josh Berkus j...@agliodbs.com:
I've come to value greppability of source code pretty highly. I think
that
some of the points you raise are valid, but in my (minority) opinion
overloading creates more problems than it solves. You're not going to
convince me that get() is *ever* a
On Mon, Feb 18, 2013 at 2:16 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 17.02.2013 14:55, Joachim Wieland wrote:
In access/transam/xlog.c we give the OS buffer caching a hint that we
won't need a WAL file any time soon with
posix_fadvise(openLogFile, 0, 0,
This was discussed before in this thread [1] but we don't reach a consensus
of what we'll do, so I propose we discuss any more about it and I can
implement it in GSOC2013, if my proposal will be accepted.
As a mentor or as a student?
--
Josh Berkus
PostgreSQL Experts Inc.
On Tue, Feb 19, 2013 at 5:38 PM, Josh Berkus j...@agliodbs.com wrote:
This was discussed before in this thread [1] but we don't reach a
consensus
of what we'll do, so I propose we discuss any more about it and I can
implement it in GSOC2013, if my proposal will be accepted.
As a mentor
On 19.02.2013 20:07, Fabrízio de Royes Mello wrote:
I would like to propose implement a way to track creation times to database
objects. This was discussed before in this thread [1].
This was discussed before in this thread [1] but we don't reach a consensus
of what we'll do, so I propose we
On 19.2.2013 11:27, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodondt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might have broken something.
Please find attached the patch for some cleanup and fix bit rot in pgindent
script.
There were a few problems with the script.
.) It failed to use the $ENV{PGENTAB} even if it was set.
.) The file it tries to download from Postgres' ftp site is no longer
present.
On Sat, February 16, 2013 02:01, Kevin Grittner wrote:
matview-v4.patch.gz
Hi,
I was wondering if material views should not go into information_schema. I was
thinking either
.views or .tables. Have you considered this?
I ask because as far as I can see querying for mv's has to go like this:
On 02/19/2013 02:09 PM, Erik Rijkers wrote:
On Sat, February 16, 2013 02:01, Kevin Grittner wrote:
matview-v4.patch.gz
Hi,
I was wondering if material views should not go into information_schema. I
was thinking either
.views or .tables. Have you considered this?
I ask because as
On Tue, Feb 19, 2013 at 11:09:13PM +0100, Erik Rijkers wrote:
On Sat, February 16, 2013 02:01, Kevin Grittner wrote:
matview-v4.patch.gz
Hi,
I was wondering if material views should not go into information_schema. I
was thinking either
.views or .tables. Have you considered this?
Erik Rijkers e...@xs4all.nl wrote:
I was wondering if material views should not go into
information_schema. I was thinking either .views or .tables.
Have you considered this?
I had not considered this to be a good idea because
information_schema is defined by the standard, and materialized
Tomas Vondra wrote:
AFAIK the stats remain the same within a transaction, and as a function
runs within a transaction, it will either get new data on the first
iteration, or it will run all 300 of them. I've checked several
buildfarm members and I'm yet to see a single duration between 12ms
Josh Berkus j...@agliodbs.com wrote:
Well, I'm not sure about information_schema, but we'll definitely
want a pg_matviews system view.
That could wait until 9.4, though.
That I could probably do. Do you think they should have a separate
pg_stat_user_matviews table, etc., or do you think it
On 19.2.2013 23:31, Alvaro Herrera wrote: Tomas Vondra wrote:
AFAIK the stats remain the same within a transaction, and as a
function runs within a transaction, it will either get new data on
the first iteration, or it will run all 300 of them. I've checked
several buildfarm members and I'm
That I could probably do. Do you think they should have a separate
pg_stat_user_matviews table, etc., or do you think it would be
better to include them in with tables there?
Well, ideally pg_matviews would have matview definitions, and
pg_stat_matviews would have stats on matview usage and
Kevin Grittner kgri...@ymail.com
There was one minor syntax issue not addressed by Noah, nor much
discussed in general that I didn't want to just unilaterally
choose; but given that nobody seems to care that much I will put
forward a proposal and do it that way tomorrow if nobody objects.
On 19 February 2013 20:19, Merlin Moncure mmonc...@gmail.com wrote:
In access/transam/xlog.c we give the OS buffer caching a hint that we
won't need a WAL file any time soon with
posix_fadvise(openLogFile, 0, 0, POSIX_FADV_DONTNEED);
If that's the case, why have the advisory call at
Josh Berkus j...@agliodbs.com wrote:
That I could probably do. Do you think they should have a separate
pg_stat_user_matviews table, etc., or do you think it would be
better to include them in with tables there?
Well, ideally pg_matviews would have matview definitions, and
pg_stat_matviews
Kevin Grittner kgri...@ymail.com wrote:
I'm attaching the patch for just the system_views.sql file
for discussion before I go write docs for this part.
Meh. If I'm gonna have pg_matviews I might as well include an
isscannable column. v2 attached.
--
Kevin Grittner
EnterpriseDB:
Hopefully I am not wrong.
+/* Size of a varlena data, excluding header */
#define VARSIZE_ANY_EXHDR(PTR) \
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterprsieDB Inc.
exhdr_comment.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 02/19/2013 03:41 PM, Kevin Grittner wrote:
Kevin Grittner kgri...@ymail.com wrote:
I'm attaching the patch for just the system_views.sql file
for discussion before I go write docs for this part.
Meh. If I'm gonna have pg_matviews I might as well include an
isscannable column. v2
On Mon, Jan 9, 2012 at 9:11 AM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 9, 2012 at 12:00, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 9, 2012 at 11:09, Magnus Hagander mag...@hagander.net
wrote:
On Mon, Jan 9, 2012 at 07:34, Jaime Casanova ja...@2ndquadrant.com
On Thu, Jan 24, 2013 at 11:40:41AM -0500, Xi Wang wrote:
On 1/24/13 10:48 AM, Tom Lane wrote:
The fundamental problem here is that the compiler, unless told otherwise
by a compilation switch, believes it is entitled to assume that no
integer overflow will happen anywhere in the program.
Sorry, I found one more typo. Attached is a patch.
Thanks,
Best regards,
Etsuro Fujita
-Original Message-
From: Magnus Hagander [mailto:mag...@hagander.net]
Sent: Friday, February 08, 2013 7:47 PM
To: Etsuro Fujita
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Comment typo
On Wed, Jan 23, 2013 at 12:06 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/1/14 Tom Lane t...@sss.pgh.pa.us:
Well, fine, but then it should fix both of them and remove
minimal_error_message altogether. I would however suggest eyeballing
what happens when you try \ef nosuchfunction
On Tue, Feb 19, 2013 at 5:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
In access/transam/xlog.c we give the OS buffer caching a hint that we
won't need a WAL file any time soon with
posix_fadvise(openLogFile, 0, 0, POSIX_FADV_DONTNEED);
I agree with Merlin and Joachim - if we have
On Tue, Jan 08, 2013 at 08:02:16PM -0500, Robert Haas wrote:
On Tue, Jan 8, 2013 at 7:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I was thinking more about a sprintf()-type function that only
understands a handful of escapes, but adds the additional
On Mon, Feb 18, 2013 at 7:50 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
So here's v11. I intend to commit this shortly. (I wanted to get it
out before lunch, but I introduced a silly bug that took me a bit to
fix.)
On Windows with Mingw I get this:
pgstat.c:4389:8: warning:
Hello, I looked this from another point of view.
I consider the current discussion to be based on how to predict
the last consistency point. But there is another aspect of this
issue.
I tried to postpone smgrtruncate after the next checkpoint. This
is similar to what hotstandby feedback does to
I have updated the patch as per comments from Tom and Heikki.
If you can verify it, then IMO it can be marked as 'Ready For
Committer'
Would you please do that?
Done.
Thank you.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing
54 matches
Mail list logo
