On Wed, Jul 18, 2012 at 09:36:51AM -0400, Robert Haas wrote:
On Tue, Jul 17, 2012 at 6:02 PM, Bruce Momjian br...@momjian.us wrote:
However, I have two ideas. First, I don't know _why_ the
primary/standby would be any different after pg_upgrade, so I added the
documentation mention because
Hanada-san,
What about the status of your patch?
Even though the 1st commit-fest is getting closed soon,
I'd like to pay efforts for reviewing to pull up the status of
pgsql_fdw into ready for committer by beginning of the
upcoming commit-fest.
Thanks,
2012/7/13 Shigeru HANADA
Hi,
Attached is v2 of the patch.
Changes are:
* more comments
* significantly cleaned/simpliefied coded
* crc validation
* addition of XLogReaderReadOne
Definitely needed are:
* better validation of records
* customizable error handling
The first is just work that needs to be done, nothing
On Wed, Jul 18, 2012 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've been chewing on this issue some more, and no longer like my
previous proposal, which was
... What I'm thinking about
is reducing the hash key to just RelFileNodeBackend + ForkNumber,
so that there's one hashtable entry
On Wed, Jul 18, 2012 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In short, then, the background writer process is entirely useless for
any database that fits completely into shared buffers.
Or to phrase that a bit more positively, there's no reason to do a
bunch of unnecessary writes if we
On Wed, Jul 18, 2012 at 5:30 PM, Andrew Dunstan and...@dunslane.net wrote:
Or we could provide an initdb flag which would set an upper bound on
shared_buffers, and have make check (at least) use it.
How about a flag that sets the exact value for shared_buffers, rather
than a maximum? I think a
On Wed, Jul 18, 2012 at 5:49 PM, Peter Eisentraut pete...@gmx.net wrote:
Sorry to raise this once again, but I still find this CHECK NO INHERIT
syntax to a bit funny. We are currently using something like
CHECK NO INHERIT (foo 0)
But we already have a different syntax for attaching
On Thu, Jul 19, 2012 at 2:38 AM, Bruce Momjian br...@momjian.us wrote:
No, the point is they run pg_upgrade on the stopped primary and stopped
standbys. Are those the same? I am not really sure.
Of course not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Alvaro has reminded me that I haven't sent out a notification to
buildfarm owners that they might need to add REL9_2_STABLE, which was
branched some time ago, to their rotations.
If you're using the latest code and running run_branches.pl and you have
$conf{branches_to_build} = 'ALL' you
On 07/17/2012 04:28 PM, Noah Misch wrote:
On Tue, Jul 17, 2012 at 01:56:19PM -0400, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of dom jul 15 16:42:22 -0400 2012:
I'm looking into that. But given that the default is to set
max_prepared_transactions to 0, shouldn't we just
Robert Haas robertmh...@gmail.com writes:
Seems a bit complex, but it might be worth it. Keep in mind that I
eventually want to be able to make an unlogged table logged or a visca
versa, which will probably entail unlinking just the init fork (for
the logged - unlogged direction).
Well, as
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 18, 2012 at 5:30 PM, Andrew Dunstan and...@dunslane.net wrote:
Or we could provide an initdb flag which would set an upper bound on
shared_buffers, and have make check (at least) use it.
How about a flag that sets the exact value for
On 07/19/2012 10:12 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 18, 2012 at 5:30 PM, Andrew Dunstan and...@dunslane.net wrote:
Or we could provide an initdb flag which would set an upper bound on
shared_buffers, and have make check (at least) use it.
How about a
Makes pg_dump sort overloaded functions in deterministic order.
The field proiargs has been added to FuncInfo and is set by getFuncs()
and getAggregates() for all functions and aggregates.
DOTypeNameCompare uses this field to break ties if the name and number of
arguments are the same. This
On Thu, Jul 19, 2012 at 09:41:29AM -0400, Robert Haas wrote:
On Thu, Jul 19, 2012 at 2:38 AM, Bruce Momjian br...@momjian.us wrote:
No, the point is they run pg_upgrade on the stopped primary and stopped
standbys. Are those the same? I am not really sure.
Of course not.
OK, but why?
On Thu, Jul 19, 2012 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Seems a bit complex, but it might be worth it. Keep in mind that I
eventually want to be able to make an unlogged table logged or a visca
versa, which will probably entail unlinking
On Thu, Jul 19, 2012 at 12:02 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, Jul 19, 2012 at 09:41:29AM -0400, Robert Haas wrote:
On Thu, Jul 19, 2012 at 2:38 AM, Bruce Momjian br...@momjian.us wrote:
No, the point is they run pg_upgrade on the stopped primary and stopped
standbys. Are
On Thu, Jul 19, 2012 at 12:43:23PM -0400, Robert Haas wrote:
On Thu, Jul 19, 2012 at 12:02 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, Jul 19, 2012 at 09:41:29AM -0400, Robert Haas wrote:
On Thu, Jul 19, 2012 at 2:38 AM, Bruce Momjian br...@momjian.us wrote:
No, the point is they run
2012/07/19 19:29, Andres Freund wrote:
Hi,
Attached is v2 of the patch.
Changes are:
* more comments
* significantly cleaned/simpliefied coded
* crc validation
* addition of XLogReaderReadOne
Definitely needed are:
* better validation of records
* customizable error handling
The first is
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 19, 2012 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What about checking just the immediately previous entry? This would
at least fix the problem for bulk-load situations, and the cost ought
to be about negligible compared to acquiring
Is there a real point to all this code in pg_backup_directory.c?
static void
createDirectory(const char *dir)
{
struct stat st;
/* the directory must not exist yet. */
if (stat(dir, st) == 0)
{
if (S_ISDIR(st.st_mode))
exit_horribly(modulename,
Peter Eisentraut pete...@gmx.net writes:
Couldn't we just call mkdir() and report the strerrno(errno) to begin
with, like everyone else does?
+1. It'll provide pretty much the same information anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Thu, Jul 19, 2012 at 2:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 19, 2012 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What about checking just the immediately previous entry? This would
at least fix the problem for bulk-load
Hello
I did a backport of temp_file_limit feature to 9.1, but when we tested
this patch, we found very restristrictive limit to 2GB.
2GB is nonsense, because this is session limit of temp files, and
these files should be longer than 2GB.
Regards
Pavel
--
Sent via pgsql-hackers mailing list
On tis, 2012-07-10 at 07:29 -0700, Josh Kupershmidt wrote:
On Sat, Jul 7, 2012 at 5:43 PM, Noah Misch n...@leadboat.com wrote:
I like the patch, as far as it goes. It's the natural addition to the
completions we already offer; compare the simplistic completion after WHERE.
Like Pavel and
On 07/19/2012 01:04 PM, Pavel Stehule wrote:
I did a backport of temp_file_limit feature to 9.1, but when we tested
this patch, we found very restristrictive limit to 2GB.
2GB is nonsense, because this is session limit of temp files, and
these files should be longer than 2GB.
I haven't read
On Thu, Jul 19, 2012 at 4:29 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 07/19/2012 01:04 PM, Pavel Stehule wrote:
I did a backport of temp_file_limit feature to 9.1, but when we tested
this patch, we found very restristrictive limit to 2GB.
2GB is nonsense, because this is session
Robert Haas robertmh...@gmail.com writes:
What if we change the hash table to have RelFileNode as the key and an
array of MAX_FORKNUM bitmapsets as the value? Then when you get a
forget request, you can just zap all the sets to empty.
Hm ... the only argument I can really make against that is
On 07/19/2012 01:48 PM, Christopher Browne wrote:
On Thu, Jul 19, 2012 at 4:29 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 07/19/2012 01:04 PM, Pavel Stehule wrote:
I did a backport of temp_file_limit feature to 9.1, but when we tested
this patch, we found very restristrictive
On 20/07/12 09:08, Joshua D. Drake wrote:
On 07/19/2012 01:48 PM, Christopher Browne wrote:
On Thu, Jul 19, 2012 at 4:29 PM, Joshua D. Drake
j...@commandprompt.com wrote:
On 07/19/2012 01:04 PM, Pavel Stehule wrote:
I did a backport of temp_file_limit feature to 9.1, but when we tested
On 20/07/12 09:58, Mark Kirkwood wrote:
On 20/07/12 09:08, Joshua D. Drake wrote:
On 07/19/2012 01:48 PM, Christopher Browne wrote:
On Thu, Jul 19, 2012 at 4:29 PM, Joshua D. Drake
j...@commandprompt.com wrote:
On 07/19/2012 01:04 PM, Pavel Stehule wrote:
I did a backport of
Am 18.07.12 23:56, schrieb Tom Lane:
Samuel Vogel s...@muel-vogel.de writes:
How would the b-tree know exactly that a value is only a reference? And
even in that case you say that it could get the bits, but make no use of
it, since it does not know what they represent, right?
It has access to
On Thu, Jul 19, 2012 at 12:49:37AM +0300, Peter Eisentraut wrote:
Sorry to raise this once again, but I still find this CHECK NO INHERIT
syntax to a bit funny. We are currently using something like
CHECK NO INHERIT (foo 0)
But we already have a different syntax for attaching attributes
Samuel Vogel s...@muel-vogel.de writes:
Am 18.07.12 23:56, schrieb Tom Lane:
It has access to the data type's basic storage parameters, which are
typbyval, typlen, and typalign; and we have standard conventions for
identifying the length etc of variable-length values. It's just the
meaning
Pavel Stehule pavel.steh...@gmail.com writes:
I did a backport of temp_file_limit feature to 9.1, but when we tested
this patch, we found very restristrictive limit to 2GB.
2GB is nonsense, because this is session limit of temp files, and
these files should be longer than 2GB.
This claim is
Is there a reason to vacuum the pgbench_* tables after the indexes on
them are built, rather than before?
Since the indexes are on fresh tables, they can't have anything that
needs to be cleaned.
I don't think the current order accomplishes anything, except to slow
down large initializations by
David Fetter da...@fetter.org writes:
On Thu, Jul 19, 2012 at 12:49:37AM +0300, Peter Eisentraut wrote:
But we already have a different syntax for attaching attributes to
constraints (NOT DEFERRABLE, NOT VALID, etc.), so it would make more
sense to have
CHECK (foo 0) NO INHERIT
How
On 20/07/12 12:02, Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
I did a backport of temp_file_limit feature to 9.1, but when we tested
this patch, we found very restristrictive limit to 2GB.
2GB is nonsense, because this is session limit of temp files, and
these files should be
Merlin Moncure mmonc...@gmail.com writes:
here's a cut down example:
with q as (select max(v) from (select 1 as v) q group by v) select q from q;
I traced through this example, and find that it's another issue in an
area we've hacked at before. ExecEvalVar, when it finds that it's
dealing with
2012/7/20 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I did a backport of temp_file_limit feature to 9.1, but when we tested
this patch, we found very restristrictive limit to 2GB.
2GB is nonsense, because this is session limit of temp files, and
these files
2012/7/20 Pavel Stehule pavel.steh...@gmail.com:
2012/7/20 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I did a backport of temp_file_limit feature to 9.1, but when we tested
this patch, we found very restristrictive limit to 2GB.
2GB is nonsense, because this
41 matches
Mail list logo
