2010/4/24 Robert Haas :
> A couple of recent threads made got me thinking again about the idea
> of global temporary tables. There seem to be two principal issues:
>
> 1. What is a global temporary table?
>
> 2. How could we implement that?
>
> Despite rereading the "idea: global temp tables" thre
On Fri, Apr 23, 2010 at 11:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 11:11 PM, Tom Lane wrote:
>>> I also kind of wonder what is supposed to happen if someone DROPs or
>>> ALTERs the temp table definition ...
>
>> ...not so much. Here you REALLY want a DROP attempt
Is there any particular reason why the citext module doesn't have
citext_pattern_ops operator family?
Specifically, I wish to index for this type of query:
... WHERE citext_column LIKE 'Foo%';
This, of course, is equivalent to ILIKE 'Foo%' which does not appear
to be indexable without using a fu
Robert Haas writes:
> On Fri, Apr 23, 2010 at 11:11 PM, Tom Lane wrote:
>> I also kind of wonder what is supposed to happen if someone DROPs or
>> ALTERs the temp table definition ...
> ...not so much. Here you REALLY want a DROP attempt to acquire an
> AccessExclusiveLock that will conflict wi
On Fri, Apr 23, 2010 at 11:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> A couple of recent threads made got me thinking again about the idea
>> of global temporary tables. There seem to be two principal issues:
>
>> 1. What is a global temporary table?
>
>> 2. How could we implement that?
>
>
Robert Haas writes:
> A couple of recent threads made got me thinking again about the idea
> of global temporary tables. There seem to be two principal issues:
> 1. What is a global temporary table?
> 2. How could we implement that?
> Despite rereading the "idea: global temp tables" thread fro
A couple of recent threads made got me thinking again about the idea
of global temporary tables. There seem to be two principal issues:
1. What is a global temporary table?
2. How could we implement that?
Despite rereading the "idea: global temp tables" thread from April
2009 in some detail, I
Xiong He wrote:
Thanks.
In my test, it fails during the vcregress.bat check startup.
It's a Debug Assertion Error. File: dbgheap.c Line: 1252.
E:\learn\db_research\postgreSQL\cvsroot\pgsql.latest\src\tools\msvc>vcregress.ba
t check
No test can run. I used VS2005 for the build.
Ple
Thanks.
In my test, it fails during the vcregress.bat check startup.
It's a Debug Assertion Error. File: dbgheap.c Line: 1252.
E:\learn\db_research\postgreSQL\cvsroot\pgsql.latest\src\tools\msvc>vcregress.ba
t check
No test can run. I used VS2005 for the build.
Xiong He
2010-04-24 08:15:
On Fri, Apr 23, 2010 at 8:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 7:28 PM, Tom Lane wrote:
>>> I would expect that they'll get an error message that makes it clear
>>> enough what to do ;-). In any case, changing the name is hardly going
>>> to fix things so that
Xiong He wrote:
When I build the debug version of PostgreSQL (latest code), I found
that I always failed to
run the vcregress.bat check. It always pops up the following error.
The release version can pass the test without any error.
Anyone met such error?
[graphic deleted]
Please don
Robert Haas writes:
> On Fri, Apr 23, 2010 at 7:28 PM, Tom Lane wrote:
>> I would expect that they'll get an error message that makes it clear
>> enough what to do ;-). In any case, changing the name is hardly going
>> to fix things so that 8.4 settings will still work, so why are you
>> giving
On Fri, Apr 23, 2010 at 7:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 7:12 PM, Tom Lane wrote:
>>> I think from the user's point of view it does what it did before.
>>> The fact that the actual content of WAL changed was an implementation
>>> detail that users weren't
Robert Haas writes:
> On Fri, Apr 23, 2010 at 7:12 PM, Tom Lane wrote:
>> I think from the user's point of view it does what it did before.
>> The fact that the actual content of WAL changed was an implementation
>> detail that users weren't aware of. Now that we have two interacting
>> features
On Fri, Apr 23, 2010 at 7:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 7:07 PM, Tom Lane wrote:
>>> Well, there is another variable that they'll have to adjust as well,
>>> but ISTM that archive_mode still does what it did before, ie, determine
>>> whether we attempt t
On Sat, April 24, 2010 00:39, Simon Riggs wrote:
> On Fri, 2010-04-23 at 11:32 -0400, Robert Haas wrote:
>> >
>> > 99% of transactions happen in similar times between primary and standby,
>> > everything dragged down by rare but severe spikes.
>> >
>> > We're looking for something that would delay
Robert Haas writes:
> On Fri, Apr 23, 2010 at 7:07 PM, Tom Lane wrote:
>> Well, there is another variable that they'll have to adjust as well,
>> but ISTM that archive_mode still does what it did before, ie, determine
>> whether we attempt to archive WAL segments.
> But it doesn't do EVERYTHING
On Fri, Apr 23, 2010 at 7:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane wrote:
>>> Agreed on the general point, but AFAICS that proposal keeps the meaning
>>> of archive_mode the same as it was.
>
>> Well, clearly it doesn't. Someone who thinks they c
Robert Haas writes:
> On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane wrote:
>> Agreed on the general point, but AFAICS that proposal keeps the meaning
>> of archive_mode the same as it was.
> Well, clearly it doesn't. Someone who thinks they can simply turn
> archive_mode=on and set archive_command
On Fri, Apr 23, 2010 at 6:39 PM, Simon Riggs wrote:
> On Fri, 2010-04-23 at 11:32 -0400, Robert Haas wrote:
>> >
>> > 99% of transactions happen in similar times between primary and standby,
>> > everything dragged down by rare but severe spikes.
>> >
>> > We're looking for something that would de
On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
>> wrote:
>>> So my proposal would be:
>>>
>>> wal_mode=crash/archive/standby
>>> archive_mode=on/off # if on, wal_mode must be >= 'archive'
>>> archive_comma
On Fri, Apr 23, 2010 at 6:55 PM, Tom Lane wrote:
> sri...@postgresql.org (Simon Riggs) writes:
>> Log Message:
>> ---
>> Add missing optimizer hooks for function cost and number of rows.
>> Closely follow design of other optimizer hooks: if hook exists
>> retrieve value from plugin; if sti
sri...@postgresql.org (Simon Riggs) writes:
> Log Message:
> ---
> Add missing optimizer hooks for function cost and number of rows.
> Closely follow design of other optimizer hooks: if hook exists
> retrieve value from plugin; if still not set then get from cache.
What exactly are we doin
Simon Riggs writes:
> We don't need *both* wal_mode and archive_mode, since archive_mode
> exists only to ensure that full WAL is written even when archive_command
> = '' momentarily.
No, you missed the point of the upthread discussion: archive_mode
controls whether to start the archiver *and whe
On Fri, 2010-04-23 at 11:32 -0400, Robert Haas wrote:
> >
> > 99% of transactions happen in similar times between primary and standby,
> > everything dragged down by rare but severe spikes.
> >
> > We're looking for something that would delay something that normally
> > takes <0.1ms into something
Simon Riggs writes:
> In my understanding this means that archive_mode does completely and the
> max_wal_senders does not affect WAL contents?
I think we'd concluded that we have to keep archive_mode as a separate
boolean. (Or we could use Heikki's idea of a max number of unarchived
segments to
Robert Haas writes:
> On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
> wrote:
>> So my proposal would be:
>>
>> wal_mode=crash/archive/standby
>> archive_mode=on/off # if on, wal_mode must be >= 'archive'
>> archive_command='command'
>> max_wal_senders= # if > 0, wal_mode
Robert Haas writes:
> On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane wrote:
>> A design that might work is
>> (1) store the active value of wal_mode in pg_control (but NOT as part of
>> the last-checkpoint-record image).
>> (2) invent a new WAL record type that is transmitted when we change
>> wal_mod
On Fri, 2010-04-23 at 17:43 -0400, Robert Haas wrote:
> On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
> wrote:
> > So my proposal would be:
> >
> > wal_mode=crash/archive/standby
> > archive_mode=on/off # if on, wal_mode must be >= 'archive'
> > archive_command='command'
> > max_
On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
wrote:
> So my proposal would be:
>
> wal_mode=crash/archive/standby
> archive_mode=on/off # if on, wal_mode must be >= 'archive'
> archive_command='command'
> max_wal_senders= # if > 0, wal_mode must be >= 'archive'
As a gener
On Fri, 2010-04-23 at 17:29 -0400, Robert Haas wrote:
> Possible "crash_recovery" rather than just "crash" where you have
> "mimimal".
Minimal is good because it is a performance option also, which is an
aspect "crash_recovery" does not convey.
(Plus we use the word crash again, which is too sca
On Fri, 2010-04-23 at 16:44 -0400, Tom Lane wrote:
> There's no connection at all between what the GUC state
> was at shutdown and what it might be after starting again.
>
> A design that might work is
> (1) store the active value of wal_mode in pg_control (but NOT as part of
> the last-checkpoin
On Apr 23, 2010, at 11:28 AM, Tom Lane wrote:
> "Ross J. Reedstrom" writes:
>> On Fri, Apr 23, 2010 at 10:58:40AM -0500, Terry Brown wrote:
>>> So the proposal would be:
>>>
>>> \d+ does as it has always done, no change
>>> \d- (new) always behaves like 'old' \d
>>> \d acts as 'old' \d or as \
On Fri, 2010-04-23 at 16:50 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > How about something like
>
> > wal_additional_info = none | archive | connect
>
> "connect" seems like a completely inappropriate word here. It is
> not obviously related to HS slaves and it could be taken to refer
> t
On Fri, Apr 23, 2010 at 4:50 PM, Tom Lane wrote:
> Simon Riggs writes:
>> How about something like
>
>> wal_additional_info = none | archive | connect
>
> "connect" seems like a completely inappropriate word here. It is
> not obviously related to HS slaves and it could be taken to refer
> to ord
On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane wrote:
> Simon Riggs writes:
>> No intention of doing that. This change allows people to see what the
>> dependency actually is once the bug has been fixed. Change needs to
>> start from here, not from where we were before.
>
> Well, actually, now that I'
Simon Riggs writes:
> How about something like
> wal_additional_info = none | archive | connect
"connect" seems like a completely inappropriate word here. It is
not obviously related to HS slaves and it could be taken to refer
to ordinary database connections (sessions).
Personally I agree wit
Simon Riggs wrote:
> On Fri, 2010-04-23 at 23:10 +0300, Heikki Linnakangas wrote:
>> So my proposal would be:
>>
>> wal_mode=crash/archive/standby
> I definitely don't like the word "crash", which may scare and
> confuse people. I don't think I would ever set any parameter to a
> word like "cra
Simon Riggs writes:
> No intention of doing that. This change allows people to see what the
> dependency actually is once the bug has been fixed. Change needs to
> start from here, not from where we were before.
Well, actually, now that I've looked at the patch I think it's starting
from a fundam
On Fri, 2010-04-23 at 23:10 +0300, Heikki Linnakangas wrote:
> So my proposal would be:
>
> wal_mode=crash/archive/standby
OK, I agree to change in this area.
I definitely don't like the word "crash", which may scare and confuse
people. I don't think I would ever set any parameter to a word like
Robert Haas writes:
> Well, I think the real hole is that turning archive_mode=on results in
> WAL never being deleted unless it's successfully archived.
Hm, good point. And at least in principle you could have SR setups
that don't care about having a backing WAL archive.
> But we might be able
On Fri, 2010-04-23 at 16:04 -0400, Tom Lane wrote:
> sri...@postgresql.org (Simon Riggs) writes:
> > Log Message:
> > ---
> > Make CheckRequiredParameterValues() depend upon correct combination
> > of parameters. Fix bug report by Robert Haas that error message and
> > hint was incorrect if
Tom Lane wrote:
> Robert Haas writes:
>> ... I'm still unconvinced of our ability to come
>> up with a solid design in the time we have, but I think it would make
>> sense to listen to proposals people want to make. I poked some holes
>> in Heikki's design from this morning (which was, more or l
On Fri, 2010-04-23 at 14:56 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
>
> > So we're proposing adding parameters to simplify things for users?
>
> I think it's a matter of having parameters which do simple, clear
> things; rather than magically interacting to guess what the user
> want
sri...@postgresql.org (Simon Riggs) writes:
> Log Message:
> ---
> Make CheckRequiredParameterValues() depend upon correct combination
> of parameters. Fix bug report by Robert Haas that error message and
> hint was incorrect if wrong mode parameters specified on master.
> Internal changes
On Fri, Apr 23, 2010 at 3:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I'm still unconvinced of our ability to come
>> up with a solid design in the time we have, but I think it would make
>> sense to listen to proposals people want to make. I poked some holes
>> in Heikki's design from
Simon Riggs writes:
> So we're proposing adding parameters to simplify things for users?
Not so much "simplify" as "make understandable"; although flexibility
is a concern too.
> I'm guessing this conversation has more to do with the situation that
> some very clever people have a little time on
Simon Riggs wrote:
> So we're proposing adding parameters to simplify things for users?
I think it's a matter of having parameters which do simple, clear
things; rather than magically interacting to guess what the user
wants. What do you want to log? How many connections to you want
to allow
On Fri, 2010-04-23 at 15:18 -0400, Robert Haas wrote:
> We're going to need
> a bunch of GUCs any way we slice it. The issue is whether there's a
> way to slice it that involves fewer AND and OR operators that have to
> be understood by users.
So we're proposing adding parameters to simplify thi
Robert Haas writes:
> ... I'm still unconvinced of our ability to come
> up with a solid design in the time we have, but I think it would make
> sense to listen to proposals people want to make. I poked some holes
> in Heikki's design from this morning (which was, more or less, my
> design from
Simon Riggs writes:
> Those confusing things are options and I want them to remain optional,
> not compressed into a potentially too simple model based upon how the
> world looks right now.
What are you arguing is too simple? What *I* think is too simple is
what we have got now, namely a GUC tha
On Fri, Apr 23, 2010 at 3:11 PM, Simon Riggs wrote:
> On Fri, 2010-04-23 at 15:05 -0400, Robert Haas wrote:
>> we have a consensus behind changing it, which it's starting to
>> sound like we do.
>
> I think you misread the +1s from Masao and myself.
>
> Those confusing things are options and I wan
On Fri, 2010-04-23 at 15:05 -0400, Robert Haas wrote:
> we have a consensus behind changing it, which it's starting to
> sound like we do.
I think you misread the +1s from Masao and myself.
Those confusing things are options and I want them to remain optional,
not compressed into a potentially to
On Fri, Apr 23, 2010 at 2:43 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> As a concrete example, there is nothing logically wrong with
>> driving a hot standby slave from WAL records shipped via old-style
>> pg_standby. Or how about wanting to turn off recovery_connections
>> temporarily, bu
On Fri, 2010-04-23 at 13:45 -0400, Robert Haas wrote:
> Archiving and streaming replication are
> just two means of transporting WAL records from point A to point B.
> By definition, any two manners of moving a byte stream around are
> isomorphic and can't possibly affect what that byte stream do
Tom Lane wrote:
> As a concrete example, there is nothing logically wrong with
> driving a hot standby slave from WAL records shipped via old-style
> pg_standby. Or how about wanting to turn off recovery_connections
> temporarily, but not wanting the archived WAL to be unable to
> support HS?
On Fri, Apr 23, 2010 at 2:36 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> We realized some time ago that it was a good idea to separate
>>> archive_mode (what to put in WAL) from archive_command (whether we are
>>> actually archiving right now). If we fail to apply tha
Heikki Linnakangas writes:
> Tom Lane wrote:
>> We realized some time ago that it was a good idea to separate
>> archive_mode (what to put in WAL) from archive_command (whether we are
>> actually archiving right now). If we fail to apply that same principle
>> to Hot Standby, I think we'll come t
"Ross J. Reedstrom" writes:
> On Fri, Apr 23, 2010 at 10:58:40AM -0500, Terry Brown wrote:
>> So the proposal would be:
>>
>> \d+ does as it has always done, no change
>> \d- (new) always behaves like 'old' \d
>> \d acts as 'old' \d or as \d+, depending on the setting of
>> 'verbose_describe',
On 4/23/10, Tom Lane wrote:
> Marko Kreen writes:
> > Um, you have been burned by exactly this on x86 also:
> > http://archives.postgresql.org/pgsql-hackers/2009-03/msg01265.php
>
>
> Yeah, we never did figure out exactly how come you were observing that
> failure on Intel-ish hardware. I
Tom Lane wrote:
> We realized some time ago that it was a good idea to separate
> archive_mode (what to put in WAL) from archive_command (whether we are
> actually archiving right now). If we fail to apply that same principle
> to Hot Standby, I think we'll come to regret it.
The recovery_connect
On Fri, Apr 23, 2010 at 10:58:40AM -0500, Terry Brown wrote:
> I asked on IRC if there was any way to make \d behave like \d+ by default,
> and davidfetter said no but suggest it here.
>
> endpoint_david pointed out you could use \d- to get the old behavior if you
> wanted to temporarily negate
Robert Haas writes:
> On Fri, Apr 23, 2010 at 12:09 PM, Tom Lane wrote:
>> FWIW, I still don't believe that claim, and I think it's complete folly
>> to set the assumption in stone by choosing a user-visible GUC API that
>> depends on it being true.
> Huh? We're clearly talking about two diffe
On Fri, Apr 23, 2010 at 12:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
>> wrote:
>>> Streaming replication needs the same information in the WAL as archiving
>>> does,
>
>> True.
>
> FWIW, I still don't believe that claim, and I think it's
Marko Kreen writes:
> Um, you have been burned by exactly this on x86 also:
> http://archives.postgresql.org/pgsql-hackers/2009-03/msg01265.php
Yeah, we never did figure out exactly how come you were observing that
failure on Intel-ish hardware. I was under the impression that Intel
machines d
On 4/18/10, Simon Riggs wrote:
> On Sat, 2010-04-17 at 16:48 -0400, Tom Lane wrote:
> > There are some places where we suppose that a *single* write into shared
> > memory can safely be done without a lock, if we're not too concerned
> > about how soon other transactions will see the effects.
On Fri, 2010-04-23 at 07:54 -0400, Robert Haas wrote:
> Let's
> revisit it for 9.1, and just improve the error reporting for now.
+1
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
Robert Haas writes:
> On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
> wrote:
>> Streaming replication needs the same information in the WAL as archiving
>> does,
> True.
FWIW, I still don't believe that claim, and I think it's complete folly
to set the assumption in stone by choosing a us
Tom Lane wrote:
> Piyush Newe writes:
>> Please consider the following test case
>
>> CREATE OR REPLACE FUNCTION raisetest() returns void AS $$
>> BEGIN
>>BEGIN
>>RAISE syntax_error;
>>EXCEPTION
>>WHEN syntax_error THEN
>>BEGIN
>>raise notice '
I asked on IRC if there was any way to make \d behave like \d+ by default, and
davidfetter said no but suggest it here.
endpoint_david pointed out you could use \d- to get the old behavior if you
wanted to temporarily negate the setting.
So the proposal would be:
\d+ does as it has always done
Piyush Newe writes:
> Please consider the following test case
> CREATE OR REPLACE FUNCTION raisetest() returns void AS $$
> BEGIN
>BEGIN
>RAISE syntax_error;
>EXCEPTION
>WHEN syntax_error THEN
>BEGIN
>raise notice 'exception thrown in inner blo
Robert Haas writes:
> I think it might be time to think about shipping a beta release. I
> guess this is a -core decision, but I can't argue for it there, so
> I'll argue for it here. It seems like we're about ready, so maybe we
> could plan for a beta, say, a week from now?
A bit of discussion
Registration for PGCon 2010 is open.
http://www.pgcon.org/2010/registration.php
The full list of talks and a preliminary schedule is available here:
http://www.pgcon.org/2010/schedule/
There are still some rooms available on campus but I recommend booking
soon as they always fill up.
--
On Fri, Apr 23, 2010 at 11:14 AM, Simon Riggs wrote:
> On Thu, 2010-04-22 at 23:45 +0100, Simon Riggs wrote:
>> On Thu, 2010-04-22 at 20:39 +0200, Erik Rijkers wrote:
>> > On Sun, April 18, 2010 13:01, Simon Riggs wrote:
>>
>> > any comment is welcome...
>>
>> Please can you re-run with -l and pos
On Thu, 2010-04-22 at 23:45 +0100, Simon Riggs wrote:
> On Thu, 2010-04-22 at 20:39 +0200, Erik Rijkers wrote:
> > On Sun, April 18, 2010 13:01, Simon Riggs wrote:
>
> > any comment is welcome...
>
> Please can you re-run with -l and post me the file of times
Erik has sent me details of a test r
On Fri, Apr 23, 2010 at 8:54 PM, Robert Haas wrote:
> On Fri, Apr 23, 2010 at 7:40 AM, Heikki Linnakangas
> wrote:
>> Ok, that brings us back to square one. We could still add the wal_mode
>> GUC to explicitly control how much WAL is written (replacing
>> recovery_connections in the primary), I t
On Fri, Apr 23, 2010 at 7:40 AM, Heikki Linnakangas
wrote:
> Ok, that brings us back to square one. We could still add the wal_mode
> GUC to explicitly control how much WAL is written (replacing
> recovery_connections in the primary), I think it would still make the
> system easier to explain. But
On Apr 23, 2010, at 13:12 , Heikki Linnakangas wrote:
> Let's have these three settings:
>
> wal_mode = crash/archive/standby (replaces archive_mode)
> archive_command
> max_wal_senders
>
> If wal_mode is set to 'crash', you can't set archive_command or
> max_wal_senders>0. If it's set to 'archi
Robert Haas wrote:
> On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
> wrote:
>> Robert Haas wrote:
>>> On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
>>> wrote:
I quite liked Robert's proposal to add an explicit GUC to control what
extra information is logged
(http://arch
On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
>> wrote:
>>> I quite liked Robert's proposal to add an explicit GUC to control what
>>> extra information is logged
>>> (http://archives.postgresql.org/pgsql-hac
Robert Haas wrote:
> On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
> wrote:
>> I quite liked Robert's proposal to add an explicit GUC to control what
>> extra information is logged
>> (http://archives.postgresql.org/pgsql-hackers/2010-04/msg00509.php). It
>> is quite difficult to explain the
On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas wrote:
>>> One way we could fix this is use 2 bits rather than 1 for
>>> XLogStandbyInfoMode. One bit could indicate that either
>>> archive_mode=on or max_wal_senders>
Hi,
Please consider the following test case
> CREATE OR REPLACE FUNCTION raisetest() returns void AS $$
BEGIN
BEGIN
RAISE syntax_error;
EXCEPTION
WHEN syntax_error THEN
BEGIN
raise notice 'exception thrown in inner block, reraising';
R
Fujii Masao wrote:
> On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas wrote:
>> One way we could fix this is use 2 bits rather than 1 for
>> XLogStandbyInfoMode. One bit could indicate that either
>> archive_mode=on or max_wal_senders>0, and the second bit could
>> indicate that recovery_connections=
84 matches
Mail list logo
