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 :
> (2012/07/12
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 comp
On Wed, Jul 18, 2012 at 5:17 PM, Tom Lane 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 per
On Wed, Jul 18, 2012 at 3:59 PM, Tom Lane 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 are lucky enough t
On Wed, Jul 18, 2012 at 5:30 PM, Andrew Dunstan 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 lot of users woul
On Wed, Jul 18, 2012 at 5:49 PM, 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 to
>
On Thu, Jul 19, 2012 at 2:38 AM, Bruce Momjian 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 PostgreSQL Company
--
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 won't
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 remo
Robert Haas 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 far as that goes,
Robert Haas writes:
> On Wed, Jul 18, 2012 at 5:30 PM, Andrew Dunstan 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?
On 07/19/2012 10:12 AM, Tom Lane wrote:
Robert Haas writes:
On Wed, Jul 18, 2012 at 5:30 PM, Andrew Dunstan 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 share
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 avo
On Thu, Jul 19, 2012 at 09:41:29AM -0400, Robert Haas wrote:
> On Thu, Jul 19, 2012 at 2:38 AM, Bruce Momjian 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? When the clu
On Thu, Jul 19, 2012 at 10:09 AM, Tom Lane wrote:
> Robert Haas 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 lo
On Thu, Jul 19, 2012 at 12:02 PM, Bruce Momjian 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 wrote:
>> > No, the point is they run pg_upgrade on the stopped primary and stopped
>> > standbys. Are those the same? I am not
On Thu, Jul 19, 2012 at 12:43:23PM -0400, Robert Haas wrote:
> On Thu, Jul 19, 2012 at 12:02 PM, Bruce Momjian 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 wrote:
> >> > No, the point is they run pg_upgrade on the stop
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 just
Robert Haas writes:
> On Thu, Jul 19, 2012 at 10:09 AM, Tom Lane 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 the LWLock.
> 2. You say "fix t
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 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 (pgsql-hackers@postgres
On Thu, Jul 19, 2012 at 2:57 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 19, 2012 at 10:09 AM, Tom Lane 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 negligibl
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 (p
On tis, 2012-07-10 at 07:29 -0700, Josh Kupershmidt wrote:
> On Sat, Jul 7, 2012 at 5:43 PM, Noah Misch 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 Robert, I th
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 t
On Thu, Jul 19, 2012 at 4:29 PM, Joshua D. Drake 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 limit of t
Robert Haas 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 that there'll
be
On 07/19/2012 01:48 PM, Christopher Browne wrote:
On Thu, Jul 19, 2012 at 4:29 PM, Joshua D. Drake 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 nons
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
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 ver
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
wrote:
On 07/19/2012 01:04 PM, Pavel Stehule wrote:
I did a backport of temp_file_limit feature to 9.1, bu
Am 18.07.12 23:56, schrieb Tom Lane:
Samuel Vogel 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 the data type's bas
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 attrib
Samuel Vogel 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 of the payl
Pavel Stehule 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 nonsense. The varia
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 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 about th
On 20/07/12 12:02, Tom Lane wrote:
Pavel Stehule 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
Merlin Moncure 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 a whole-row Var
2012/7/20 Tom Lane :
> Pavel Stehule 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.
>
> Thi
2012/7/20 Pavel Stehule :
> 2012/7/20 Tom Lane :
>> Pavel Stehule 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
I wrote:
> I think the way to solve this is to do whatever it takes to get access
> to the subplan targetlist. We could then do something a bit cleaner
> than what the named-rowtype code is currently doing: if there are
> resjunk columns in the subplan targetlist, use the tlist to create a
> JunkF
41 matches
Mail list logo
