On Tue, May 18, 2010 at 6:57 AM, Simon Riggs wrote:
>
> I notice that there are more than a few projects on pgfoundry that are
> marked as "BSD licence" but then the project files don't contain any
> mention of the licence details. In some cases, projects are also clearly
> marked Copyright of peo
On Tue, May 18, 2010 at 3:24 PM, Simon Riggs wrote:
> On Tue, 2010-05-18 at 15:09 +0900, Fujii Masao wrote:
>> On Tue, May 18, 2010 at 2:26 PM, Simon Riggs wrote:
>> > On Tue, 2010-05-18 at 12:02 +0900, Fujii Masao wrote:
>> >> On Mon, May 17, 2010 at 9:01 PM, Simon Riggs
>> >> wrote:
>> >> >>
On Tue, 2010-05-18 at 15:09 +0900, Fujii Masao wrote:
> On Tue, May 18, 2010 at 2:26 PM, Simon Riggs wrote:
> > On Tue, 2010-05-18 at 12:02 +0900, Fujii Masao wrote:
> >> On Mon, May 17, 2010 at 9:01 PM, Simon Riggs wrote:
> >> >> (1)
> >> >> Smart or fast shutdown requested in PM_STARTUP state a
On Tue, May 18, 2010 at 2:26 PM, Simon Riggs wrote:
> On Tue, 2010-05-18 at 12:02 +0900, Fujii Masao wrote:
>> On Mon, May 17, 2010 at 9:01 PM, Simon Riggs wrote:
>> >> (1)
>> >> Smart or fast shutdown requested in PM_STARTUP state always removes
>> >> the backup_label file if it exists. But it m
I notice that there are more than a few projects on pgfoundry that are
marked as "BSD licence" but then the project files don't contain any
mention of the licence details. In some cases, projects are also clearly
marked Copyright of people or organizations.
For example, pg_batch is clearly marked
On Tue, 2010-05-18 at 12:02 +0900, Fujii Masao wrote:
> On Mon, May 17, 2010 at 9:01 PM, Simon Riggs wrote:
> >> (1)
> >> Smart or fast shutdown requested in PM_STARTUP state always removes
> >> the backup_label file if it exists. But it might be still required
> >> for subsequent recovery. I chan
On Tue, 2010-05-18 at 11:40 +0900, Fujii Masao wrote:
> ISTM that walreceiver might be invoked even after shutdown is
> requested. We should prevent the postmaster from starting up
> walreceiver if Shutdown > NoShutdown?
+1
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hacke
Bruce Momjian wrote:
> Well, to do it on the fly, you need to:
>
> use $libdir for regression .so files, not absolute paths
> change CREATE OR REPLACE LANGUAGE to simple CREAtE for 8.4
> run it twice to fix inheritance COPY column ordering
> deal with extra_float_digits
>
On Tue, May 4, 2010 at 5:17 PM, Tom Lane wrote:
> FWIW, that's not the case, anymore than it is for blocks in shared
> buffer cache for regular rels. smgrextend() results in an observable
> extension of the file EOF immediately, whether or not you can see
> up-to-date data for those pages.
>
> No
On Mon, May 17, 2010 at 9:01 PM, Simon Riggs wrote:
>> (1)
>> Smart or fast shutdown requested in PM_STARTUP state always removes
>> the backup_label file if it exists. But it might be still required
>> for subsequent recovery. I changed your patch so that additionally
>> the postmaster skips dele
On Mon, May 17, 2010 at 10:20 PM, Robert Haas wrote:
> OK, I think I understand now. But, the SIGTERM sent by the postmaster
> doesn't kill the recovery process unconditionally. It will invoke
> StartupProcShutdownHandler(), which will set set shutdown_requested =
> true. That gets checked by R
On Mon, May 17, 2010 at 9:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 17, 2010 at 4:01 PM, Tom Lane wrote:
>>> Perhaps this is a backpatchable bug fix. Comments?
>
>> I can't say whether this is safe enough to back-patch, but the way
>> this is set up, don't we also need to fix
Robert Haas writes:
> On Mon, May 17, 2010 at 4:01 PM, Tom Lane wrote:
>> Perhaps this is a backpatchable bug fix. Comments?
> I can't say whether this is safe enough to back-patch, but the way
> this is set up, don't we also need to fix some catalog entries and, if
> yes, isn't that problemati
On Mon, May 17, 2010 at 5:20 PM, Greg Smith wrote:
> Jim Nasby wrote:
>>
>> For archive_mode you should check the archives; where was discussion on
>> exactly why we can only enable archiving on restart. That GUC was added
>> specifically so that archive_command didn't require a restart
>
> I link
On Mon, May 17, 2010 at 4:01 PM, Tom Lane wrote:
> I wrote:
>>> Heikki Linnakangas writes:
Marking textanycat as not immutable would forbid using it in
expression indexes, too.
>
>>> True. On the other hand, the current state of affairs allows one to
>>> create an index on expressions
On Mon, May 17, 2010 at 2:10 PM, Jim Nasby wrote:
>> It seems prett clear that it isn't desirable to simply add backend ID
>> to RelFileNode, because there are too many places using RelFileNode
>> already for purposes where the backend ID can be inferred from
>> context, such as buffer headers and
Jaime Casanova wrote:
On Mon, May 17, 2010 at 7:00 PM, Andrew Dunstan wrote:
I have just released version 4.0 of the PostgreSQL Buildfarm client.
There are two new features:
* The SCM code is substantially rearranged into a separate OO
module, with subclasses supporting CVS and Git
On Mon, May 17, 2010 at 7:00 PM, Andrew Dunstan wrote:
>
> I have just released version 4.0 of the PostgreSQL Buildfarm client.
>
> There are two new features:
>
> * The SCM code is substantially rearranged into a separate OO
> module, with subclasses supporting CVS and Git. New config optio
I have just released version 4.0 of the PostgreSQL Buildfarm client.
There are two new features:
* The SCM code is substantially rearranged into a separate OO
module, with subclasses supporting CVS and Git. New config options
support these changes, while old style config parameters
Jim Nasby wrote:
For archive_mode you should check the archives; where was discussion on exactly
why we can only enable archiving on restart. That GUC was added specifically so
that archive_command didn't require a restart
I linked the most relevant bits from the archives into
http://wiki.po
On Mon, May 17, 2010 at 2:15 PM, Jim Nasby wrote:
> On May 6, 2010, at 4:29 PM, Merlin Moncure wrote:
>> On Thu, May 6, 2010 at 3:23 PM, Andrew Dunstan wrote:
>>> And many places regard "select *" in anything other than throw-away queries
>>> as bad practice anyway. I have seen people get bitten
On Mon, May 17, 2010 at 2:15 PM, Jim Nasby wrote:
> On May 6, 2010, at 4:29 PM, Merlin Moncure wrote:
>> On Thu, May 6, 2010 at 3:23 PM, Andrew Dunstan wrote:
>>> And many places regard "select *" in anything other than throw-away queries
>>> as bad practice anyway. I have seen people get bitten
On Mon, 2010-05-17 at 16:10 -0400, Tom Lane wrote:
> Jim Nasby writes:
> > On Apr 29, 2010, at 3:20 PM, Tom Lane wrote:
> >> This is not the time to be hacking stuff like this. You haven't even
> >> demonstrated that there's a significant performance issue here.
>
> > I tend to agree that this p
Excerpts from Michael Renner's message of sáb may 15 20:24:36 -0400 2010:
> On 16.05.2010 02:16, Tom Lane wrote:
> > Michael Renner writes:
> >> I've written a simple tool to generate traffic on a database [1], which
> >> did about 30 TX/inserts per second to a table. Upon inspecting the data
> >>
Jim Nasby writes:
> On Apr 29, 2010, at 3:20 PM, Tom Lane wrote:
>> This is not the time to be hacking stuff like this. You haven't even
>> demonstrated that there's a significant performance issue here.
> I tend to agree that this point of the cycle isn't a good one to be making
> changes, but
I wrote:
>> Heikki Linnakangas writes:
>>> Marking textanycat as not immutable would forbid using it in
>>> expression indexes, too.
>> True. On the other hand, the current state of affairs allows one to
>> create an index on expressions that aren't really immutable, with
>> ensuing hilarity.
>
On May 6, 2010, at 4:29 PM, Merlin Moncure wrote:
> On Thu, May 6, 2010 at 3:23 PM, Andrew Dunstan wrote:
>> And many places regard "select *" in anything other than throw-away queries
>> as bad practice anyway. I have seen people get bitten by it over and over
>> again, and I have worked at compa
On Apr 29, 2010, at 3:20 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Objections to commit?
>
> This is not the time to be hacking stuff like this. You haven't even
> demonstrated that there's a significant performance issue here.
I tend to agree that this point of the cycle isn't a good one to
On May 4, 2010, at 3:48 PM, Gurjeet Singh wrote:
> There are quite a few GUC parameters that need restart. Is there a way we can
> avoid some of them needing restart? I am specifically looking at archive_mode
> and the new wal_level.
For archive_mode you should check the archives; where was dis
On May 6, 2010, at 10:24 PM, Robert Haas wrote:
> On Tue, May 4, 2010 at 3:03 PM, Alvaro Herrera
> wrote:
> [smgr.c,inval.c] Do we need to call CacheInvalidSmgr for temporary
> relations? I think the only backend that can have an smgr reference
> to a temprel other than the owning bac
On May 6, 2010, at 4:31 AM, Florian Pflug wrote:
>> The use case for this was there were different news items,
>> and there were another table for summaries, that could point
>> to any of the news items table. Another use case could be
>> a large partitioned table with an FK to the main table where
On May 15, 2010, at 12:05 PM, Heikki Linnakangas wrote:
> What exactly is the user trying to monitor? If it's "how far behind is
> the standby", the difference between pg_current_xlog_insert_location()
> in the master and pg_last_xlog_replay_location() in the standby seems
> more robust and well-de
On May 17, 2010, at 11:20 AM, Peter Eisentraut wrote:
> We have in 9.0 plperl.c
>
> errcontext("while executing PostgreSQL::InServer::SPI::bootstrap")));
> errcontext("while parsing Perl initialization")));
> errcontext("while running Perl initialization")));
> errcontext("While executing PLC_TRU
Peter Eisentraut wrote:
We have in 9.0 plperl.c
errcontext("while executing PostgreSQL::InServer::SPI::bootstrap")));
errcontext("while parsing Perl initialization")));
errcontext("while running Perl initialization")));
errcontext("While executing PLC_TRUSTED.")));
errcontext("While executing
Peter Eisentraut writes:
> We have in 9.0 plperl.c
> errcontext("while executing PostgreSQL::InServer::SPI::bootstrap")));
> errcontext("while parsing Perl initialization")));
> errcontext("while running Perl initialization")));
> errcontext("While executing PLC_TRUSTED.")));
> errcontext("While e
We have in 9.0 plperl.c
errcontext("while executing PostgreSQL::InServer::SPI::bootstrap")));
errcontext("while parsing Perl initialization")));
errcontext("while running Perl initialization")));
errcontext("While executing PLC_TRUSTED.")));
errcontext("While executing utf8fix.")));
errcontext("Wh
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Attached is a patch that just checks the result from the existing
> > fflush() inside the FETCH_COUNT loop and drops out of that loop if we
> > get an error from it.
>
> I thought it might be about that simple once you went at it
Tom Lane wrote:
Andrew Dunstan writes:
OK ... I guess I was bothered because this has been referred to in a
public press release about the Beta. The PLPerl security stuff is
missing too, so I'll fix that also.
The security stuff isn't relevant to the 9.0 notes, since it's already
b
Andrew Dunstan writes:
> OK ... I guess I was bothered because this has been referred to in a
> public press release about the Beta. The PLPerl security stuff is
> missing too, so I'll fix that also.
The security stuff isn't relevant to the 9.0 notes, since it's already
been fixed in a previous
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> If you're combining this with the FETCH_COUNT logic then it seems like
>> it'd be sufficient to check ferror(fout) once per fetch chunk, and just
>> fall out of that loop then. I don't want psql issuing query cancels
>> on its own
Tom Lane wrote:
Andrew Dunstan writes:
Why do the release notes say this, under plperl:
* PL/Perl subroutines are now given names (Tim Bunce)
This is for the use of profiling and code coverage tools. DIDN'T
THEY HAVE NAMES BEFORE?
If whoever put this in the releas
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> If you're combining this with the FETCH_COUNT logic then it seems like
> it'd be sufficient to check ferror(fout) once per fetch chunk, and just
> fall out of that loop then. I don't want psql issuing query cancels
> on its own authority, either.
Attached
Just a reminder -- We've got a few spaces left for lightning talks.
Submit your idea today!
See below for details.
-selena
On Sat, May 8, 2010 at 6:46 AM, Selena Deckelmann wrote:
> Hi!
>
> We're having Lightning Talks again at PgCon - scheduled for 5:30pm on
> May 20th in Ottawa!
>
> Do you ha
Andrew Dunstan writes:
> Why do the release notes say this, under plperl:
> * PL/Perl subroutines are now given names (Tim Bunce)
> This is for the use of profiling and code coverage tools. DIDN'T
> THEY HAVE NAMES BEFORE?
> If whoever put this in the release notes had bothered to
Why do the release notes say this, under plperl:
* PL/Perl subroutines are now given names (Tim Bunce)
This is for the use of profiling and code coverage tools. DIDN'T
THEY HAVE NAMES BEFORE?
No they didn't, from perl's perspective, which is what this is about.
They had names fro
On Mon, May 17, 2010 at 7:44 AM, Fujii Masao wrote:
> On Mon, May 17, 2010 at 8:02 PM, Robert Haas wrote:
>>> (1)
>>> Smart or fast shutdown requested in PM_STARTUP state always removes
>>> the backup_label file if it exists. But it might be still required
>>> for subsequent recovery. I changed y
On Mon, 2010-05-17 at 16:38 +0900, Fujii Masao wrote:
> On Mon, May 17, 2010 at 10:25 AM, Robert Haas wrote:
> > Therefore I think
> > Fujii Masao's original idea was the best, but I have what I believe is
> > an equivalent but simpler implementation, which is attached.
>
> Seems good.
>
> I fou
On Mon, May 17, 2010 at 7:38 AM, Simon Riggs wrote:
> On Mon, 2010-05-17 at 07:33 -0400, Robert Haas wrote:
>> I would
>> prefer that we focus on the technical issues here rather than who
>> wrote the patch.
>
> There are three patches now from 2 authors. I agree we should focus on
> the technical
On Mon, May 17, 2010 at 8:02 PM, Robert Haas wrote:
>> (1)
>> Smart or fast shutdown requested in PM_STARTUP state always removes
>> the backup_label file if it exists. But it might be still required
>> for subsequent recovery. I changed your patch so that additionally
>> the postmaster skips dele
On Mon, 2010-05-17 at 07:33 -0400, Robert Haas wrote:
> I would
> prefer that we focus on the technical issues here rather than who
> wrote the patch.
There are three patches now from 2 authors. I agree we should focus on
the technical issues, but which issues, in which patch? If Masao had
accepte
On Mon, May 17, 2010 at 7:14 AM, Simon Riggs wrote:
> On Mon, 2010-05-17 at 06:55 -0400, Robert Haas wrote:
>
>> > I think we should review Masao's patch and ask him to make any changes
>> > we think are appropriate. There's no benefit to have multiple patch
>> > authors at one time.
>>
>> I did r
On Mon, 2010-05-17 at 06:55 -0400, Robert Haas wrote:
> > I think we should review Masao's patch and ask him to make any changes
> > we think are appropriate. There's no benefit to have multiple patch
> > authors at one time.
>
> I did review his patch. It duplicates a few lines of logic and I
>
On Mon, May 17, 2010 at 3:38 AM, Fujii Masao wrote:
> On Mon, May 17, 2010 at 10:25 AM, Robert Haas wrote:
>> Therefore I think
>> Fujii Masao's original idea was the best, but I have what I believe is
>> an equivalent but simpler implementation, which is attached.
>
> Seems good.
>
> I found ano
On Mon, May 17, 2010 at 6:41 AM, Simon Riggs wrote:
> On Mon, 2010-05-17 at 06:30 -0400, Robert Haas wrote:
>> On Mon, May 17, 2010 at 3:13 AM, Simon Riggs wrote:
>> > On Sun, 2010-05-16 at 21:25 -0400, Robert Haas wrote:
>> >
>> >> I have what I believe is
>> >> an equivalent but simpler impleme
On Mon, 2010-05-17 at 06:30 -0400, Robert Haas wrote:
> On Mon, May 17, 2010 at 3:13 AM, Simon Riggs wrote:
> > On Sun, 2010-05-16 at 21:25 -0400, Robert Haas wrote:
> >
> >> I have what I believe is
> >> an equivalent but simpler implementation, which is attached.
> >
> > There's no code comments
On Mon, May 17, 2010 at 3:13 AM, Simon Riggs wrote:
> On Sun, 2010-05-16 at 21:25 -0400, Robert Haas wrote:
>
>> I have what I believe is
>> an equivalent but simpler implementation, which is attached.
>
> There's no code comments to explain this, so without in-depth analysis
> of the problem, Mas
Tom Lane wrote:
> Bruce Momjian writes:
> > Andrew Dunstan wrote:
> >> It's going to require some fancy dancing to get the buildfarm to do it.
> >> Each buildfarm run is for a specific branch, and all the built artefacts
> >> are normally thrown away.
>
> > Uh, that is not actually a problem.
On Sun, 2010-05-16 at 16:53 +0100, Simon Riggs wrote:
> >
> > Attached patch rearranges the walsender loops slightly to fix the above.
> > XLogSend() now only sends up to MAX_SEND_SIZE bytes (== XLOG_SEG_SIZE /
> > 2) in one round and returns to the main loop after that even if there's
> > unsent
On Sat, May 15, 2010 at 3:20 AM, Robert Haas wrote:
> Hmm, OK, I think that makes sense. Would you care to propose a patch?
Yep. Here is the patch.
This patch distinguishes normal shutdown from unexpected exit, while the
server is in recovery. That is, when smart or fast shutdown is requested
d
On Mon, May 17, 2010 at 10:25 AM, Robert Haas wrote:
> Therefore I think
> Fujii Masao's original idea was the best, but I have what I believe is
> an equivalent but simpler implementation, which is attached.
Seems good.
I found another two problems related to shutdown in PM_STARTUP state:
(1)
On Sun, 2010-05-16 at 21:25 -0400, Robert Haas wrote:
> I have what I believe is
> an equivalent but simpler implementation, which is attached.
There's no code comments to explain this, so without in-depth analysis
of the problem, Masao's patch and this one its not possible to say
anything.
Plea
On Mon, 2010-05-17 at 11:51 +0900, Fujii Masao wrote:
> Is it OK that this keepalive message cannot be used by HS in file-based
> log-shipping? Even in SR, the startup process cannot use the keepalive
> until walreceiver has been started up.
Yes, I see those things.
We already have archive_time
62 matches
Mail list logo
