On 15/06/10 08:09, Takahiro Itagaki wrote:
Fujii Masao wrote:
On Fri, Jun 11, 2010 at 7:25 PM, Heikki Linnakangas
What's the policy with that, should all the sections in the sample config
file and docs have a corresponding enum in config_group_names?
+1. This seems sensible.
Here is a pa
On 15/06/10 08:23, Fujii Masao wrote:
On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane wrote:
I'm not sure if it's worth the trouble, or even a particularly smart
idea, to force the output of the status function to be monotonic
regardless of what happens underneath. I think removing that claim
from
On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Even then, we wouldn't need to start from the beginning of the WAL
>> segment AFAICS. The point is to start from the Redo pointer, not from
>> the checkpoint record, because as soon as we read the checkpoint record
On 15/06/10 07:47, Fujii Masao wrote:
On Tue, Jun 15, 2010 at 12:02 AM, Tom Lane wrote:
Fujii Masao writes:
Walsender tries to send WAL up to xlogctl->LogwrtResult.Write. OTOH,
xlogctl->LogwrtResult.Write is updated after XLogWrite() performs fsync.
Wrong. LogwrtResult.Write tracks how far
Fujii Masao wrote:
> On Fri, Jun 11, 2010 at 7:25 PM, Heikki Linnakangas
> > What's the policy with that, should all the sections in the sample config
> > file and docs have a corresponding enum in config_group_names?
>
> +1. This seems sensible.
Here is a patch to do that. I used terms in the
On Tue, Jun 15, 2010 at 12:02 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Fri, Jun 11, 2010 at 11:47 PM, Tom Lane wrote:
>>> Well, we're already not waiting for fsync, which is the slowest part.
>
>> No, currently walsender waits for fsync.
>
> No, you're mistaken.
>
>> Walsender tries to se
On Mon, Jun 14, 2010 at 10:13 PM, Robert Haas wrote:
> On Mon, Jun 14, 2010 at 8:41 AM, Fujii Masao wrote:
>> On Mon, Jun 14, 2010 at 8:10 PM, Robert Haas wrote:
>>> Maybe. That sounds like a pretty enormous foot-gun to me, considering
>>> that we have no way of recovering from the situation wh
(2010/06/15 12:28), Tom Lane wrote:
> KaiGai Kohei writes:
> The attached patch tries to add one more security hook on the
> initialization of PostgreSQL instance (InitPostgres()).
>
>>> Yeah, but so what? Stephen's point is still valid.
>
>> On the hook, I'd like to obtain security con
On Mon, Jun 14, 2010 at 10:35 PM, Fujii Masao wrote:
> On Tue, Jun 15, 2010 at 12:09 AM, Robert Haas wrote:
>> The testing that I have been doing while we've been discussing this
>> reveals that you are correct. I set up an HS/SR master and slave
>> (running on the same machine), ran pgbench on
KaiGai Kohei writes:
The attached patch tries to add one more security hook on the
initialization of PostgreSQL instance (InitPostgres()).
>> Yeah, but so what? Stephen's point is still valid.
> On the hook, I'd like to obtain security context of the client process
> which connected t
On Tue, Jun 15, 2010 at 12:09 AM, Robert Haas wrote:
> The testing that I have been doing while we've been discussing this
> reveals that you are correct. I set up an HS/SR master and slave
> (running on the same machine), ran pgbench on the master, and then
> started randomly sending SIGSEGV to
(2010/06/15 10:12), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei:
>> (2010/06/15 9:22), Robert Haas wrote:
>>> 2010/6/14 KaiGai Kohei:
On the hook, I'd like to obtain security context of the client process
which connected to the PostgreSQL instance. It is not available at the
_PG_init
2010/6/14 KaiGai Kohei :
> (2010/06/15 9:22), Robert Haas wrote:
>> 2010/6/14 KaiGai Kohei:
>>> On the hook, I'd like to obtain security context of the client process
>>> which connected to the PostgreSQL instance. It is not available at the
>>> _PG_init() phase, because clients don't connect yet.
(2010/06/15 9:22), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei:
>> On the hook, I'd like to obtain security context of the client process
>> which connected to the PostgreSQL instance. It is not available at the
>> _PG_init() phase, because clients don't connect yet.
>
> Can't you just call getpee
2010/6/14 KaiGai Kohei :
> On the hook, I'd like to obtain security context of the client process
> which connected to the PostgreSQL instance. It is not available at the
> _PG_init() phase, because clients don't connect yet.
Can't you just call getpeercon() the first time you need the context
and
(2010/06/14 21:35), Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> This is essentially the same patch that I wrote and posted several
>> weeks ago, with changes to the comments and renaming of the
>> identifiers. Are you trying to represent it as your own work?
>
> Ehh, I
(2010/06/14 22:11), Robert Haas wrote:
> On Mon, Jun 14, 2010 at 8:46 AM, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> 2010/6/14 KaiGai Kohei:
It adds makeRangeTblEntry() into makefuncs.c to keep the code more
clean. It shall be also used for the upcoming DML
(2010/06/14 21:15), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei:
>> (2010/06/14 20:01), Stephen Frost wrote:
>>> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch tries to add one more security hook on the
initialization of PostgreSQL instance (InitPostgres()).
It
Josh Berkus wrote:
On 6/14/10 3:39 PM, Lacey Powers wrote:
Bruce Momjian wrote:
Lacey Powers wrote:
I tried to send something out Thursday about this to
pgsql-performance, and I tried to send something out last night about
this to pgsql-announce. Neither seem to have gotten through, or
approve
Andrew Dunstan wrote:
Lacey Powers wrote:
Do any of the other minor releases made at the same time have this
problem, or just 8.4.4?
The only ones affected were 8.4.4 for CentOS 5 x86_64 and i386.
That also covers RHEL5 x86_64/i386, no? I assume you use the same RPMs
for both.
cheers
Lacey Powers wrote:
Do any of the other minor releases made at the same time have this
problem, or just 8.4.4?
The only ones affected were 8.4.4 for CentOS 5 x86_64 and i386.
That also covers RHEL5 x86_64/i386, no? I assume you use the same RPMs
for both.
cheers
andrew
--
Sent via p
On 6/14/10 3:39 PM, Lacey Powers wrote:
> Bruce Momjian wrote:
>> Lacey Powers wrote:
>>> I tried to send something out Thursday about this to
>>> pgsql-performance, and I tried to send something out last night about
>>> this to pgsql-announce. Neither seem to have gotten through, or
>>> approved.
Bruce Momjian wrote:
Lacey Powers wrote:
I tried to send something out Thursday about this to pgsql-performance,
and I tried to send something out last night about this to
pgsql-announce. Neither seem to have gotten through, or approved. =( =( =(
Yes, I suspected that might have happened.
T
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, how do we properly get rid of all those buggy 8.4.4 installs? Seems
> > a posting to announce is not enough, and we need to show users how to
> > tell if they are running a de-buggy version.
>
> The original thread already covered that in sufficien
Bruce Momjian writes:
> OK, how do we properly get rid of all those buggy 8.4.4 installs? Seems
> a posting to announce is not enough, and we need to show users how to
> tell if they are running a de-buggy version.
The original thread already covered that in sufficient detail: check
debug_assert
Lacey Powers wrote:
> I tried to send something out Thursday about this to pgsql-performance,
> and I tried to send something out last night about this to
> pgsql-announce. Neither seem to have gotten through, or approved. =( =( =(
Yes, I suspected that might have happened.
> Thursday to the Pe
Excerpts from Marko Kreen's message of jue jun 10 18:10:50 -0400 2010:
> Jan's proposal of storing small struct into segmented files
> sounds like it could work. Can't say anything more because
> I can't imagine it as well as Jan. Would need to play with
> working implementation to say more...
> "Tom" == Tom Lane writes:
Tom> But actually, there's another issue here: hstore defines not one
Tom> but three => operators:
Tom> text => textyields hstore (with 1 element)
Tom> text[] => text[]yields hstore (with N elements)
Tom> hstore => text[]yiel
Tom Lane wrote:
> "Kevin Grittner" writes:
>> The fact that LOG is categorized the same as INFO has led me to
>> believe that they are morally equivalent --
>
> They are not morally equivalent. INFO is for output that the user
> has explicitly requested appear on his console (eg, via VACUUM
>
On 06/14/2010 11:54 AM, Tom Lane wrote:
> Joe Conway writes:
>> I didn't even think people were using those functions for many years
>> since I never heard any complaints. I'd say better to not backpatch
>> changes to logical ordering, but FWIW the attached at least fixes the
>> immediate bug in h
Joe Conway writes:
> I didn't even think people were using those functions for many years
> since I never heard any complaints. I'd say better to not backpatch
> changes to logical ordering, but FWIW the attached at least fixes the
> immediate bug in head and ought to work at least a few branches.
Robert Haas wrote:
> On Mon, Jun 14, 2010 at 10:59 AM, Andrew Dunstan wrote:
> > Robert Haas wrote:
> >>> Ok, so shouldn't it be
> >>>
> >>> "The %_SHARED variable and other global state(s?)
> >>> within the language *are* public data"
> >>>
> >>> ?
> >> It seems correct to me as-is, but I just wo
On 06/14/2010 11:21 AM, Tom Lane wrote:
> Actually, I was working on it myself. On further reflection I think
> that logical numbers are clearly the right thing --- if we define it
> as being physical numbers then we will have headaches in the future
> when/if we support rearranging columns. Howe
On Mon, Jun 14, 2010 at 20:22, Tom Lane wrote:
> Simon Riggs writes:
>> LOG is already over-used and so anything said at that level is drowned.
>
> This is nonsense.
Whether it's over-used or not may be, but that doesn't make the
general issue nonsense.
But the fact is that having LOG at a high
On 6/14/10 7:57 AM, Tom Lane wrote:
> However, I do agree that it's not helpful to loop forever. If we can
> easily make it retry once and then PANIC, I'd be for that --- otherwise
> I tend to agree that the best thing is just to PANIC immediately. There
> are many many situations where a slave r
"Kevin Grittner" writes:
> Simon Riggs wrote:
>> LOG is already over-used and so anything said at that level is
>> drowned. In many areas of code we cannot use a higher level
>> without trauma. That is a problem since we have no way to separate
>> the truly important from the barely interesting.
Simon Riggs wrote:
> LOG is already over-used and so anything said at that level is
> drowned. In many areas of code we cannot use a higher level
> without trauma. That is a problem since we have no way to separate
> the truly important from the barely interesting.
The fact that LOG is catego
Simon Riggs writes:
> LOG is already over-used and so anything said at that level is drowned.
This is nonsense.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
> At the risk of sounding obsessed, this is an area where predicate
> locks might be usefully extended, if and when the serializable patch
> makes it in.
Yes, we see your patch in 9.1-first. ;-)
--
-- Josh Berkus
PostgreSQ
Joe Conway writes:
> On 06/14/2010 10:58 AM, Tom Lane wrote:
>> The current effective behavior of the code is that the column numbers
>> are physical numbers. Should we document it that way, or change it?
> Probably it should be changed to deal with dropped columns correctly,
> but I won't have
On 06/14/2010 10:58 AM, Tom Lane wrote:
> A recent bug report
> http://archives.postgresql.org/pgsql-admin/2010-06/msg00101.php
> shows that dblink_build_sql_update and friends are really not all there
> when it comes to dealing with dropped columns in the target table.
Yup, was just looking at th
A recent bug report
http://archives.postgresql.org/pgsql-admin/2010-06/msg00101.php
shows that dblink_build_sql_update and friends are really not all there
when it comes to dealing with dropped columns in the target table.
The immediate cause of the reported crash is just an internal matter,
but wh
On Mon, 2010-06-14 at 11:09 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > Should I be downgrading Hot Standby breakages to LOG? That will
> > certainly help high availability as well.
>
> If a message is being issued in a non-user-connected session, there
> is basically not a lot of point in W
On Mon, Jun 14, 2010 at 1:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> Not sure I agree with this - what I think the problem is here is we
>> need to make a clear distinction between recoverable errors and
>> unrecoverable errors.
>
> Um, if it's recoverable, it's not really an error ...
Gah.
On Sat, Jun 12, 2010 at 1:21 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> Which, IIRC, is new in 9.1, so could in theory be removed, especially if
>> there was an
>> hstore(text[], text[])
>
> Oh --- now that I look, both that and the hstore => text[] one are new
> in 9.0, which m
Robert Haas writes:
> Not sure I agree with this - what I think the problem is here is we
> need to make a clear distinction between recoverable errors and
> unrecoverable errors.
Um, if it's recoverable, it's not really an error ...
regards, tom lane
--
Sent via pgsql-
On Mon, Jun 14, 2010 at 12:31 PM, Simon Riggs wrote:
>> If that's the case, I guess Tom's right, once more, saying that LOG is
>> fine here. If we want to be more subtle than that, we'd need to revise
>> each and every error message and attribute it the right level, which it
>> probably have alrea
On Mon, 2010-06-14 at 18:11 +0200, Dimitri Fontaine wrote:
> Robert Haas writes:
> > On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> Should I be downgrading Hot Standby breakages to LOG? That will
> >>> certainly help high availability as well.
> >>
> >> If a mes
Folks,
The PostgreSQL 9.1 Development Plan:
http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan
calls for a ReviewFest to run from the 15th of June (tomorrow) until
the start of the first CommitFest for the 9.1 release. The idea is
that those with time available to contribute bey
On sön, 2010-06-13 at 12:11 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Jun 12, 2010 at 1:45 AM, Peter Eisentraut wrote:
> >> I wrote it down now:
> >> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan
>
> > Thanks! Looks good, except I thought our plan was to cut alp
Robert Haas writes:
> On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
>> Simon Riggs writes:
>>> Should I be downgrading Hot Standby breakages to LOG? That will
>>> certainly help high availability as well.
>>
>> If a message is being issued in a non-user-connected session, there
>> is basical
Bruce Momjian wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010:
Yes, the folks at commandprompt need to be told about this. Loudly.
It's a serious packaging error.
Just notified L
Heikki Linnakangas napsal(a):
On 12/06/10 17:18, Pavel Baros wrote:
I am curious how could I solve the problem:
During refreshing I would like to know, if MV is stale or fresh? And I
had an idea:
In fact, MV need to know if its last refresh (transaction id) is older
than any INSERT, UPDATE, DE
On Mon, Jun 14, 2010 at 1:55 PM, Dimitri Fontaine
wrote:
> What about /usr/bin/true, or a simple archive where you cp in a given
> location (which could happen to be a remote server thanks to unix
> network file systems or windows shares), etc. It seems to me those are
> existing problem that we s
On Mon, Jun 14, 2010 at 11:34 AM, Simon Riggs wrote:
> On Mon, 2010-06-14 at 11:14 -0400, Robert Haas wrote:
>> On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
>> > Simon Riggs writes:
>> >> Should I be downgrading Hot Standby breakages to LOG? That will
>> >> certainly help high availability
Robert Haas writes:
> On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
>> If a message is being issued in a non-user-connected session, there
>> is basically not a lot of point in WARNING or below. It should either
>> be LOG, or ERROR/FATAL/PANIC (which are probably all about the same
>> thing
On Mon, 2010-06-14 at 11:14 -0400, Robert Haas wrote:
> On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
> > Simon Riggs writes:
> >> Should I be downgrading Hot Standby breakages to LOG? That will
> >> certainly help high availability as well.
> >
> > If a message is being issued in a non-user-
Excerpts from Bruce Momjian's message of dom jun 13 10:00:16 -0400 2010:
> Why have I received no reply to this email? Do people think this is not
> a serious issue? I know it is a weekend but the problem was identified
> on Thursday, meaning there was a full workday for someone from
> CommandPr
Robert Haas wrote:
> What Pavel's trying to do here is be smart about figuring out when
> an MV needs to be refreshed. I'm pretty sure this is the wrong
> way to go about it, but it seems entirely premature considering
> that we don't have a working implementation of a *manually*
> refreshed MV
On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
> Simon Riggs writes:
>> Should I be downgrading Hot Standby breakages to LOG? That will
>> certainly help high availability as well.
>
> If a message is being issued in a non-user-connected session, there
> is basically not a lot of point in WARN
On Mon, Jun 14, 2010 at 10:59 AM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>> Ok, so shouldn't it be
>>>
>>> "The %_SHARED variable and other global state(s?)
>>> within the language *are* public data"
>>>
>>> ?
>> It seems correct to me as-is, but I just work here.
>
> Umm, you don't say "Joe
Simon Riggs writes:
> Should I be downgrading Hot Standby breakages to LOG? That will
> certainly help high availability as well.
If a message is being issued in a non-user-connected session, there
is basically not a lot of point in WARNING or below. It should either
be LOG, or ERROR/FATAL/PANIC
On Mon, Jun 14, 2010 at 10:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 14, 2010 at 10:38 AM, Tom Lane wrote:
>>> That's a different question altogether ;-). I assume you're not
>>> satisfied by the change Heikki committed a couple hours ago?
>>> It will at least try to do someth
Fujii Masao writes:
> On Fri, Jun 11, 2010 at 11:47 PM, Tom Lane wrote:
>> Well, we're already not waiting for fsync, which is the slowest part.
> No, currently walsender waits for fsync.
No, you're mistaken.
> Walsender tries to send WAL up to xlogctl->LogwrtResult.Write. OTOH,
> xlogctl->Log
Robert Haas wrote:
Ok, so shouldn't it be
"The %_SHARED variable and other global state(s?)
within the language *are* public data"
?
It seems correct to me as-is, but I just work here.
Umm, you don't say "Joe and Mary is people." (Or I hope you don't.) So
"are" looks correct here
Robert Haas writes:
> On Mon, Jun 14, 2010 at 10:38 AM, Tom Lane wrote:
>> That's a different question altogether ;-). I assume you're not
>> satisfied by the change Heikki committed a couple hours ago?
>> It will at least try to do something to recover.
> Yeah, I'm not satisfied by that. It's
On Mon, 2010-06-14 at 10:30 -0400, Tom Lane wrote:
> I'm totally unimpressed by the argument that log-filtering
> applications don't know enough to pay attention to LOG messages.
> There are already a lot of those that are quite important to notice.
We have a log level where 1 log entry in a mill
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
...
> what's stored in variables. Off the top of my head, I'm not sure if
> there is anything like that, but I wouldn't bet on there not being
> any...
I'm with Robert: I don't see much of a problem here. I might even
suggest removing the ref
On Mon, Jun 14, 2010 at 10:38 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm willing to buy the above, but nobody has explained to my
>> satisfaction why it's remotely sane to go into an infinite retry loop
>> on an unrecoverable error.
>
> That's a different question altogether ;-). I assume
Robert Haas writes:
> I'm willing to buy the above, but nobody has explained to my
> satisfaction why it's remotely sane to go into an infinite retry loop
> on an unrecoverable error.
That's a different question altogether ;-). I assume you're not
satisfied by the change Heikki committed a coupl
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jun 14, 2010 at 10:08 AM, Tom Lane wrote:
> >> The correct log level for this message is LOG. ?End of discussion.
>
> > Why?
>
> Because it's not being issued in a user's session. The only place it
> can go is to the system log, and if you use
On Mon, Jun 14, 2010 at 10:18 AM, Jehan-Guillaume (ioguix) de Rorthais
wrote:
> On 14/06/2010 14:08, Robert Haas wrote:
>> On Mon, Jun 14, 2010 at 3:48 AM, Jehan-Guillaume (ioguix) de Rorthais
>> wrote:
>>> While translating the plperl page from the manual, I found the following
>>> sentence:
>>>
On Mon, Jun 14, 2010 at 10:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 14, 2010 at 10:08 AM, Tom Lane wrote:
>>> The correct log level for this message is LOG. End of discussion.
>
>> Why?
>
> Because it's not being issued in a user's session. The only place it
> can go is to t
Robert Haas writes:
> On Mon, Jun 14, 2010 at 10:08 AM, Tom Lane wrote:
>> The correct log level for this message is LOG. End of discussion.
> Why?
Because it's not being issued in a user's session. The only place it
can go is to the system log, and if you use a level of WARNING or less,
it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/06/2010 14:08, Robert Haas wrote:
> On Mon, Jun 14, 2010 at 3:48 AM, Jehan-Guillaume (ioguix) de Rorthais
> wrote:
>> While translating the plperl page from the manual, I found the following
>> sentence:
>>
>> The %_SHARED variable and other gl
On Mon, Jun 14, 2010 at 10:08 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Magnus Hagander wrote:
>>> It means that we can't prevent people from configuring their tools to
>>> ignore important warning. We can't prevent them rom ignoring ERROR or
>>> FATAL either...
>
>> My point is that most to
Bruce Momjian writes:
> Magnus Hagander wrote:
>> It means that we can't prevent people from configuring their tools to
>> ignore important warning. We can't prevent them rom ignoring ERROR or
>> FATAL either...
> My point is that most tools are going to look at the tag first to
> determine the s
Robert Haas writes:
> On Mon, Jun 14, 2010 at 6:57 AM, Bruce Momjian wrote:
>> Uh, I thought this was about quoting the identifiers. I am confused
>> about why "integer" is an issue in this case. Can you show an example?
> Sure.
INTEGER is actually a keyword in this context, not an identifier
On Mon, Jun 14, 2010 at 8:41 AM, Fujii Masao wrote:
> On Mon, Jun 14, 2010 at 8:10 PM, Robert Haas wrote:
>> Maybe. That sounds like a pretty enormous foot-gun to me, considering
>> that we have no way of recovering from the situation where the standby
>> gets ahead of the master.
>
> No, we can
On Mon, Jun 14, 2010 at 8:46 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> 2010/6/14 KaiGai Kohei :
>> > It adds makeRangeTblEntry() into makefuncs.c to keep the code more
>> > clean. It shall be also used for the upcoming DML refactor patch.
>> > In this refactoring,
Heikki Linnakangas writes:
> On 14/06/10 13:39, Dimitri Fontaine wrote:
>> I tend to consider it a bug that there's no known way under windows to
>> use the same trick as under Unix by using '/usr/bin/true' as your
>> archive command. And this Unix trick itself does feel like a hack.
>>
>> Also I'
On Mon, Jun 14, 2010 at 8:10 PM, Robert Haas wrote:
> Maybe. That sounds like a pretty enormous foot-gun to me, considering
> that we have no way of recovering from the situation where the standby
> gets ahead of the master.
No, we can do that by reconstructing the standby from the backup.
And,
* Robert Haas (robertmh...@gmail.com) wrote:
> 2010/6/14 KaiGai Kohei :
> > It adds makeRangeTblEntry() into makefuncs.c to keep the code more
> > clean. It shall be also used for the upcoming DML refactor patch.
> > In this refactoring, a common DML permission checker function take
> > a list of R
Simon Riggs writes:
> Cleaning the archive directory, not the pg_xlog directory.
Hence the choice of the directory where to act. I was slow on that,
sorry guys.
I guess my main problem here is that I still picture PostgreSQL has
being able to maintain an archive with no external script in the si
* Robert Haas (robertmh...@gmail.com) wrote:
> This is essentially the same patch that I wrote and posted several
> weeks ago, with changes to the comments and renaming of the
> identifiers. Are you trying to represent it as your own work?
Ehh, I doubt it. He had included your patch in another p
2010/6/14 KaiGai Kohei :
> (2010/06/14 20:01), Stephen Frost wrote:
>> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>>> The attached patch tries to add one more security hook on the
>>> initialization of PostgreSQL instance (InitPostgres()).
>>>
>>> It gives the external security module a chance to
On Mon, Jun 14, 2010 at 3:48 AM, Jehan-Guillaume (ioguix) de Rorthais
wrote:
> While translating the plperl page from the manual, I found the following
> sentence:
>
> The %_SHARED variable and other global state within
> the language is public data.
>
> Should it be :
>
> The %_SHARED variable
2010/6/14 KaiGai Kohei :
> The attached patch was a part of DML refactoring and security hook patches.
>
> It adds makeRangeTblEntry() into makefuncs.c to keep the code more
> clean. It shall be also used for the upcoming DML refactor patch.
> In this refactoring, a common DML permission checker fu
On Mon, 2010-06-14 at 17:39 +0900, Fujii Masao wrote:
> No, currently walsender waits for fsync.
> ...
> But that change would cause the problem that Robert pointed out.
> http://archives.postgresql.org/pgsql-hackers/2010-06/msg00670.php
Presumably this means that if synchronous_commit = off on p
On Mon, 2010-06-14 at 17:39 +0900, Fujii Masao wrote:
> On Fri, Jun 11, 2010 at 11:47 PM, Tom Lane wrote:
> > Stefan Kaltenbrunner writes:
> >> hmm not sure that is what fujii tried to say - I think his point was
> >> that in the original case we would have serialized all the operations
> >> (fir
2010/6/14 KaiGai Kohei :
> I attached three patches for the effort.
> Each patch tries to tackle one theme, so it is not unreasonable.
>
> But the ESP security hook patch (quite tiny) depends on the DML permission
> refactoring patch (relatively larger). So, Robert suggested me to reconsider
> the
On 14/06/10 13:16, Bruce Momjian wrote:
Heikki Linnakangas wrote:
On 12/06/10 04:19, Bruce Momjian wrote:
Robert Haas wrote:
If my streaming replication stops working, I want to know about it as
soon as possible. WARNING just doesn't cut it.
This needs some better thought.
If we PANIC, then
On Mon, Jun 14, 2010 at 5:00 AM, Magnus Hagander wrote:
> 2010/6/14 Greg Smith :
>> Pavel Baros wrote:
>>>
>>> After each INSERT, UPDATE, DELETE statement (transaction)
>>> pg_class.rellastxid would be updated. That should not be time- or memory-
>>> consuming (not so much) since pg_class is cache
On 14/06/10 13:39, Dimitri Fontaine wrote:
I tend to consider it a bug that there's no known way under windows to
use the same trick as under Unix by using '/usr/bin/true' as your
archive command. And this Unix trick itself does feel like a hack.
Also I'd very much like to be able to recommend (
On Mon, Jun 14, 2010 at 7:18 AM, Magnus Hagander wrote:
> On Mon, Jun 14, 2010 at 13:11, Bruce Momjian wrote:
>> Magnus Hagander wrote:
>>> >> Seems like we need something like WARNING that doesn't cause the process
>>> >> to die, but more alarming like ERROR/FATAL/PANIC. Or maybe just adding a
>
Magnus Hagander wrote:
> On Mon, Jun 14, 2010 at 13:11, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> >> Seems like we need something like WARNING that doesn't cause the process
> >> >> to die, but more alarming like ERROR/FATAL/PANIC. Or maybe just adding a
> >> >> hint to the warning will
On Sat, 2010-06-12 at 03:29 +0200, Rafael Martinez wrote:
> What I didn't expect was such a serious consequence. Postgres crashed
> in the standby node and it refused to start until the directory needed
> by the tablespace was created also in the standby.
> I suppose there is not an easy way of fi
On Mon, 2010-06-14 at 12:21 +0200, Dimitri Fontaine wrote:
> Fujii Masao writes:
> > In SR, WAL files in the pg_xlog directory on the standby are recycled
> > by every restartpoints. So your proposed function seems not to be helpful
> > even if hot_standby = on.
>
> Then I guess I'm at a loss her
On Mon, 2010-06-14 at 12:39 +0200, Dimitri Fontaine wrote:
> I tend to consider it a bug that there's no known way under windows to
> use the same trick as under Unix by using '/usr/bin/true' as your
> archive command. And this Unix trick itself does feel like a hack.
>
> Also I'd very much like
On Mon, Jun 14, 2010 at 13:11, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> >> Seems like we need something like WARNING that doesn't cause the process
>> >> to die, but more alarming like ERROR/FATAL/PANIC. Or maybe just adding a
>> >> hint to the warning will do. How about
>> >>
>> >> WARNIN
1 - 100 of 121 matches
Mail list logo
