On 09/26/2011 05:58 AM, Shigeru Hanada wrote:
> * Local variables added by the patch (secs, usecs, write_rate and
> endtime) can be moved into narrower scope.
> * Initializing starttime to zero seems unnecessary.
>
Setting starttime to 0 is already in the code; the change made to that
line was
On Tue, Oct 4, 2011 at 23:46, Amit Khandekar
wrote:
> On 4 October 2011 22:57, Alex Hunsaker wrote:
>> On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
>> wrote:
>>> On 4 October 2011 14:04, Alex Hunsaker wrote:
On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
wrote:
> WHen GetDatab
On 04.10.2011 22:46, Seiko Ishida (MP Tech Consulting LLC) wrote:
Our team drives the bug notification activity with our valued Windows partners.
This email is to notify you that PostgreSQL's application/driver experienced
compatibility issue(s) during internal Microsoft testing and has been bl
On 10/04/2011 03:45 PM, Royce Ausburn wrote:
I think I get this stats stuff now. Unless someone here thinks it's
too hard for a new postgres dev's 2nd patch, I could take a stab. I
might take a look at it tonight to get a feel for how hard, and what
stats we could collect. I'll start a new thre
On 4 October 2011 22:57, Alex Hunsaker wrote:
> On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
> wrote:
>> On 4 October 2011 14:04, Alex Hunsaker wrote:
>>> On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
>>> wrote:
>>>
WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
u
daveg writes:
> Postgresql 9.0.4 has the timezone:
> America/Blanc-Sablon
> However other sources seem to spell this with an underscore instead of dash:
> America/Blanc_Sablon
I don't know what "other sources" you're consulting, but "Blanc-Sablon"
is the way it appears in the Olson timezone d
Hi,
While the system is idle, we skip duplicate checkpoints for some
reasons. But when wal_level is set to hot_standby, I found that
checkpoints are wrongly duplicated even while the system is idle.
The cause is that XLOG_RUNNING_XACTS WAL record always
follows CHECKPOINT one when wal_level is set
Postgresql 9.0.4 has the timezone:
America/Blanc-Sablon
However other sources seem to spell this with an underscore instead of dash:
America/Blanc_Sablon
It appears that beside 'America/Blanc_Sablon', other multi-word timezones
are spelled with underscore. For example: 'Australia/Broken_Hi
2011/10/4 Simon Riggs :
> The problem is the *same* one I fixed in v2, yet now I see I managed
> to somehow exclude that fix from the earlier patch. Slap. Anyway,
> fixed again now.
Ah ok! I started reviewing the v4 patch version, this is my comments:
Submission review
===
1. The pat
On Wed, Oct 5, 2011 at 2:49 AM, Bruce Momjian wrote:
> Rather than parallelizing
> the entire backend, I imagine adding threading or helper processes for
> things like sorts, index scans, executor nodes, and stored procedure
> languages. I expect final code to be 2-3 years in the future.
I don'
On Wed, Oct 5, 2011 at 02:36, gabrielle wrote:
> This review was compiled from a PDXPUG group review (Dan Colish, Mark
> Wong, Brent Dombrowski, and Gabrielle Roth).
Hi, thanks for the review!
> - Regression test requires plpythonu; it needs to work without that.
The patch contains no regressi
Peter Geoghegan wrote:
> On the subject of highly ambitious optimisations to sorting, one
> possibility I consider much more practicable than GPU-accelerated
> sorting is simple threading; quicksort can be parallelised very
> effectively, due to its divide-and-conquer nature. If we could agree
> on
Bruce Momjian writes:
> Tom Lane wrote:
>> As of fairly recently, the Fedora package also uses pg_ctl for both
>> starting and stopping. We've fixed all the reasons that formerly
>> existed to avoid use of pg_ctl, and it's a real PITA to try to
>> implement the waiting logic at shell level.
> OK
Tom Lane wrote:
> Bruce Momjian writes:
> > Greg Stark wrote:
> >> An interactive tool can dwim automatically but that isn't appropriate
> >> for a startup script. A startupt script should always do the same
> >> thing exactly and do that based on the OS policy, not based on
> >> inspecting what p
This review was compiled from a PDXPUG group review (Dan Colish, Mark
Wong, Brent Dombrowski, and Gabrielle Roth).
--
We all agree this is a really useful feature. The patch applies
cleanly to the current git master with git apply, it's in context
diff, and does what it's supposed to do on Ubunt
On 04/10/2011, at 11:26 PM, Robert Haas wrote:
> On Mon, Oct 3, 2011 at 9:17 AM, Royce Ausburn wrote:
>> - I'm not sure if I'm supposed to update CATALOG_VERSION_NO in catalog.h.
>> In this patch I have.
>
> Generally that is left to the committer, as the correct value depends
> on the value
Bruce Momjian writes:
> Greg Stark wrote:
>> An interactive tool can dwim automatically but that isn't appropriate
>> for a startup script. A startupt script should always do the same
>> thing exactly and do that based on the OS policy, not based on
>> inspecting what programs are actually running
Greg Stark wrote:
> On Tue, Oct 4, 2011 at 2:42 PM, Bruce Momjian wrote:
> > Because pg_ctl 9.1 will read postmaster.pid and find the port number,
> > socket location, and listen host for wait mode --- I doubt someone would
> > do that work in a script.
>
> But this is the whole difference betwee
Dave Page writes:
> On Tue, Oct 4, 2011 at 8:27 PM, Tom Lane wrote:
>> OK. I can fix that while I'm busy hacking on guc.c. Does anyone care
>> enough about this to think it should be back-patched?
> I think it's worthwhile if the patch can be applied fairly easily to
> the older branches. If n
On Tue, Oct 4, 2011 at 8:27 PM, Tom Lane wrote:
> Dave Page writes:
>> On Tue, Oct 4, 2011 at 7:55 PM, Tom Lane wrote:
>>> I'm betting not, because I don't see any support for copying their
>>> values down to child processes in
>>> write_nondefault_variables/read_nondefault_variables.
>
>> Corre
Dave Page writes:
> On Tue, Oct 4, 2011 at 7:55 PM, Tom Lane wrote:
>> I'm betting not, because I don't see any support for copying their
>> values down to child processes in
>> write_nondefault_variables/read_nondefault_variables.
> Correct, it does not.
OK. I can fix that while I'm busy hack
On Tue, Oct 4, 2011 at 7:55 PM, Tom Lane wrote:
> I'm betting not, because I don't see any support for copying their
> values down to child processes in
> write_nondefault_variables/read_nondefault_variables.
Correct, it does not.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnak
I'm betting not, because I don't see any support for copying their
values down to child processes in
write_nondefault_variables/read_nondefault_variables.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Mon, Oct 03, 2011 at 04:49:21PM -0300, Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of lun oct 03 16:09:08 -0300 2011:
>
> > Yes, auto-creation of symlinks would be useful, but at that point pg_ctl
> > and pg_upgrade would have to use the real data directory, so I again
> >
On Tue, Oct 04, 2011 at 09:42:42AM -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On m?n, 2011-10-03 at 18:44 -0400, Bruce Momjian wrote:
> > > Agreed. You could argue that pg_ctl 9.1 is much better than anything
> > > anyone would be able to craft in a script.
> >
> > And what facts s
On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
wrote:
> On 4 October 2011 14:04, Alex Hunsaker wrote:
>> On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
>> wrote:
>>
>>> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
>>> utf8_str, so pg_verify_mbstr_len() will not get called. [.
Excerpts from Kevin Grittner's message of jue sep 29 14:51:38 -0300 2011:
> Alvaro Herrera wrote:
>
> > But I think these changes stand on their own, merely on code
> > clarity grounds).
>
> After a quick scan, I think it helps with that. This was a messy
> area to deal with in SSI given the
Tom Lane writes:
> I still don't see the point. If they want to change the default
> setting, they add an entry to postgresql.conf. Problem solved.
As you wish. They will have to figure the current defaults in some
other way then edit the file. That's good enough for now anyway.
>> We could
Dimitri Fontaine writes:
> Tom Lane writes:
>> Dimitri Fontaine writes:
>>> What I have in mind for extensions now that c_v_c is out would be to be
>>> able to declare any GUC in the control file, with default values, and
>>> without forcing extension to handle the GUC in its .so â I don't thi
pg_upgrade doesn't work if the 'postgres' database has been dropped in
the old cluster:
~/pgsql.master$ bin/pg_upgrade -b ~/pgsql.91stable/bin -B bin/ -d
~/pgsql.91stable/data -D data-upgraded/
Performing Consistency Checks
-
Checking current, bin, and data director
.
Alvaro Herrera-7 wrote:
>
> I dunno what about Gentoo.
> -
some info about gentoo
http://pastebin.com/9hbLmVJA
http://www.gentoo.org/doc/en/postgres-howto.xml
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Bug-with-pg-ctl-w-wait-and-config-only-directories-tp486020
Tom Lane writes:
> Dimitri Fontaine writes:
>> What I have in mind for extensions now that c_v_c is out would be to be
>> able to declare any GUC in the control file, with default values, and
>> without forcing extension to handle the GUC in its .so — I don't think
>> we have to change the code b
Robert Haas wrote:
> On Tue, Oct 4, 2011 at 10:55 AM, Bruce Momjian wrote:
> >> It seems both ugly and unnecessary to declare dump_config_variable as
> >> char[MAXPGPATH]. ?MAXPGPATH doesn't seem like the right length for a
> >> buffer intended to hold a GUC name, but in fact I don't think you nee
On Tue, Oct 4, 2011 at 10:55 AM, Bruce Momjian wrote:
>> It seems both ugly and unnecessary to declare dump_config_variable as
>> char[MAXPGPATH]. MAXPGPATH doesn't seem like the right length for a
>> buffer intended to hold a GUC name, but in fact I don't think you need
>> a buffer at all. I th
Robert Haas wrote:
> On Mon, Oct 3, 2011 at 11:04 PM, Bruce Momjian wrote:
> > OK, here is a patch that adds a -C option to the postmaster so any
> > config variable can be dumped, even while the server is running (there
> > is no security check because we don't have a user name at this point),
>
Dimitri Fontaine writes:
> What I have in mind for extensions now that c_v_c is out would be to be
> able to declare any GUC in the control file, with default values, and
> without forcing extension to handle the GUC in its .so â I don't think
> we have to change the code beside removing the c_v
On Tue, Oct 4, 2011 at 2:42 PM, Bruce Momjian wrote:
> Because pg_ctl 9.1 will read postmaster.pid and find the port number,
> socket location, and listen host for wait mode --- I doubt someone would
> do that work in a script.
But this is the whole difference between them. An init.d script
*shou
Peter Eisentraut wrote:
> On m?n, 2011-10-03 at 18:44 -0400, Bruce Momjian wrote:
> > Agreed. You could argue that pg_ctl 9.1 is much better than anything
> > anyone would be able to craft in a script.
>
> And what facts support that argument?
Because pg_ctl 9.1 will read postmaster.pid and find
On Tue, Oct 4, 2011 at 1:05 PM, Fujii Masao wrote:
> On Tue, Oct 4, 2011 at 5:33 AM, Robert Haas wrote:
>> On Mon, Oct 3, 2011 at 4:25 PM, Simon Riggs wrote:
>>> On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas wrote:
>>>
Sorry, but I still don't really think it's fair to say that you've
p
On Wed, Sep 28, 2011 at 11:51 AM, Kohei KaiGai wrote:
> I rebased the patches towards the latest git master, so I believe these
> are available to apply.
Reviewing away...
I don't see why we need one struct called ObjectProperty and another
called CatalogProperty. Just fold CatalogProperty into
On Mon, Oct 3, 2011 at 9:17 AM, Royce Ausburn wrote:
> - I'm not sure if I'm supposed to update CATALOG_VERSION_NO in catalog.h. In
> this patch I have.
Generally that is left to the committer, as the correct value depends
on the value at the time of commit, not the time you submit the patch;
a
On Mon, Oct 3, 2011 at 11:04 PM, Bruce Momjian wrote:
> OK, here is a patch that adds a -C option to the postmaster so any
> config variable can be dumped, even while the server is running (there
> is no security check because we don't have a user name at this point),
> e.g.:
>
> postgres -
On Tue, Oct 4, 2011 at 1:46 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Ok. Could you phrase that as a code comment?
>
> Here's a version of the patch I've been working on. There's no functional
> changes, just a lot of moving things around, comment changes, etc. to
> ho
On Tue, Oct 4, 2011 at 5:33 AM, Robert Haas wrote:
> On Mon, Oct 3, 2011 at 4:25 PM, Simon Riggs wrote:
>> On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas wrote:
>>
>>> Sorry, but I still don't really think it's fair to say that you've
>>> proposed a solution to this problem. Or if you have, neithe
On Mon, Oct 3, 2011 at 6:31 PM, Fujii Masao wrote:
>> Also, in pg_last_xact_insert_timestamp, the errhint() seems a little
>> strange - this is not exactly a WAL *control* function, is it?
>
> Not only "control" but also "WAL" might be confusing. What about
> "transaction information functions"?
Hello
There is not possible to get a number of processed rows when COPY is
evaluated via SPI. Client can use a tag, but SPI doesn't use a tag.
I propose a small change a ProcessUtility to return a processed rows.
Note: I found a small inconsistency between SPI and Utility interface.
SPI still us
Kaigai-san,
Thanks for the review.
(2011/10/03 17:07), Kohei KaiGai wrote:
> At first, I tried to use file_fdw, however, it was crashed of course.
> It seems to me this logic should be modified to confirm whether the target FDW
> support join push down, or not.
>
> + if (enable_foreignjoin
On Oct4, 2011, at 00:59 , Andrew Dunstan wrote:
> However, there are lots of wrinkles. For example, the names of objects appear
> in LOTS of places, and making sure we caught them all might be quite tricky.
> Say you have a table x that inherits a,b, and c, and you decide to restore
> with b ren
On 04.10.2011 11:51, Alexander Korotkov wrote:
On Tue, Oct 4, 2011 at 12:12 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
Can you elaborate the consider-split algorithm? The criteria to select the
new split over the previously selected one is this:
! /*
!
On Tue, Oct 4, 2011 at 2:51 AM, Dickson S. Guedes wrote:
> 2011/10/3 Simon Riggs :
>> On Sun, Oct 2, 2011 at 11:45 PM, Dickson S. Guedes
>> wrote:
>>> I'm trying your patch, it was applied cleanly to master and compiled
>>> ok. But since I started postgres I'm seeing a 99% of CPU usage:
>>
>> O
On 4 October 2011 14:04, Alex Hunsaker wrote:
> On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
> wrote:
>
>> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
>> utf8_str, so pg_verify_mbstr_len() will not get called. That's the
>> reason, pg_verify_mbstr_len() is under the ( ret
On Tue, Oct 4, 2011 at 12:12 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Can you elaborate the consider-split algorithm? The criteria to select the
> new split over the previously selected one is this:
>
>> ! /*
>> !* If ratio is acceptable,
On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
wrote:
> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
> utf8_str, so pg_verify_mbstr_len() will not get called. That's the
> reason, pg_verify_mbstr_len() is under the ( ret == utf8_str )
> condition.
Consider a latin1 database
On 22.09.2011 22:12, Alexander Korotkov wrote:
Patch without that dead code is attached.
Thanks.
Can you elaborate the consider-split algorithm? The criteria to select
the new split over the previously selected one is this:
! /*
!* If ratio is acceptable, we sho
Tom Lane writes:
>> Or do you want to open SET typo.wrogn TO 'foobar' to just work silently?
>
> Well, right at the moment it *does* work silently, as long as the prefix
> is one you listed in custom_variable_classes. I don't think we want to
> take that away, and in particular I don't want to as
On mån, 2011-10-03 at 18:44 -0400, Bruce Momjian wrote:
> Agreed. You could argue that pg_ctl 9.1 is much better than anything
> anyone would be able to craft in a script.
And what facts support that argument?
Anyway, this comes back to your favorite argument upthread. pg_ctl has
had occasional
On mån, 2011-10-03 at 17:12 -0400, Andrew Dunstan wrote:
>
> On 10/03/2011 04:41 PM, Peter Eisentraut wrote:
> > On mån, 2011-10-03 at 15:09 -0400, Bruce Momjian wrote:
> >> Why were people not using pg_ctl? Because of the limitations which
> >> were fixed in PG 9.1? As Dave already said, window
57 matches
Mail list logo
