On 03/09/10 09:36, Simon Riggs wrote:
On Fri, 2010-09-03 at 12:50 +0900, Fujii Masao wrote:
That design would affect what the standby should reply. If we choose
async/recv/fsync/replay on a per-transaction basis, the standby
should send multiple LSNs and the master needs to decide when
replicati
On Thu, Sep 2, 2010 at 7:24 PM, Fujii Masao wrote:
>> I propose a configuration file standbys.conf, in the master:
>>
>> # STANDBY NAME SYNCHRONOUS TIMEOUT
>> importantreplica yes 100ms
>> tempcopy no 10s
>
> Seems good. In fact, instead of yes/no, async/recv/fs
On Fri, 2010-09-03 at 12:50 +0900, Fujii Masao wrote:
> On Thu, Sep 2, 2010 at 11:32 PM, Heikki Linnakangas
> wrote:
> > I understand what you're after, the idea of being able to set
> > synchronization level on a per-transaction basis is cool. But I haven't seen
> > a satisfactory design for it.
On Fri, Sep 3, 2010 at 11:08 AM, Tom Lane wrote:
> Fujii Masao writes:
>>> + * XXX: Is it safe to elog(ERROR) in a signal handler?
>>>
>>> No, it isn't.
>
>> We should use elog(FATAL) or check proc_exit_inprogress, instead?
>
> elog(FATAL) is *certainly* not a better idea. I think
On Thu, Sep 2, 2010 at 11:32 PM, Heikki Linnakangas
wrote:
> I understand what you're after, the idea of being able to set
> synchronization level on a per-transaction basis is cool. But I haven't seen
> a satisfactory design for it. I don't understand how it would work in
> practice. Even though
Max Bowsher wrote:
> On 02/09/10 16:44, Michael Haggerty wrote:
>> My understanding was that the problem is not that the branches are
>> created, but that they are created from a non-optimal starting point,
>> making it necessary for each of them to be doctored using a fixup
>> commit. Since the t
On 02/09/10 16:44, Michael Haggerty wrote:
> Max Bowsher wrote:
>> On 02/09/10 14:40, Michael Haggerty wrote:
>>> Robert Haas wrote:
On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty
wrote:
> What weirdness, exactly, are you discussing now? I've lost track of
> which problem(s)
Fujii Masao writes:
>> + * XXX: Is it safe to elog(ERROR) in a signal handler?
>>
>> No, it isn't.
> We should use elog(FATAL) or check proc_exit_inprogress, instead?
elog(FATAL) is *certainly* not a better idea. I think there's really
nothing that can be done, you just have to s
On Fri, Sep 3, 2010 at 5:13 AM, Tom Lane wrote:
> Does ReleaseLatch() have any actual use-case, and if so what would it be?
> I think we could do without it.
In Unix, probably we can live without that. But in Windows, we need to
free SharedEventHandles slot for upcoming process using a latch when
Excerpts from John Adams's message of jue sep 02 18:25:45 -0400 2010:
> I noticed in postgres you cannot return multiple result sets from a stored
> procedure (surprisingly as it looks like a very good dbms).
If you're really intent about doing this, you can emulate it by
returning a set of refc
I noticed in postgres you cannot return multiple result sets from a stored
procedure (surprisingly as it looks like a very good dbms).
I would like to suggest adding this feature.
- It is very usefull
- It is supported by all other dbmss I have worked with.
- makes porting applications to postg
Peter Eisentraut writes:
> On lör, 2010-08-21 at 15:30 -0400, Tom Lane wrote:
>> The only thing that seems like it might need discussion is the name
>> to give the datatype. My first instinct was pg_expr or pg_expression,
>> but there are some cases where this doesn't exactly fit. In
>> particu
Awhile back I ranted about replacing the planner's concept of inner
indexscans with a more generalized notion of "parameterized paths":
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00994.php
The executor fixes for that are done, and now I'm grappling with getting
the planner to do somet
On Mon, Aug 30, 2010 at 11:12 AM, wrote:
> Can anyone explain this ?
>
> My question is -
> What is lnext:; , lreplace:; in postgres code ?
> I found lnext:; in 1501 and lreplace:; in 2065 in execMain.c file.
It's a label.
http://www.lysator.liu.se/c/bwk-tutor.html#goto
--
Robert Haas
Enterpr
Heikki Linnakangas writes:
> Ok, here's an updated patch with WaitLatchOrSocket that let's you do that.
Minor code review items:
s/There is three/There are three/ in unix_latch.c header comment
The header comment points out the correct usage of ResetLatch, but I
think it should also emphasize t
Can anyone explain this ?
My question is -
What is lnext:; , lreplace:; in postgres code ?
I found lnext:; in 1501 and lreplace:; in 2065 in execMain.c file.
--
Thank You,
Subham Roy.
CSE,
IIT Bombay.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Tom Lane wrote:
> +1 for adding parens; we might want to make a function of it
> someday.
Makes sense; will do.
> I don't much like the "XactUses..." aspect of it; that's just
> about meaningless, because almost everything in PG could be said
> to be "used" by a transaction. How about
> Iso
"Kevin Grittner" writes:
> Robert Haas wrote:
>> XactUsesPerXactSnapshot()?
> That seems unambiguous. I think I prefer it to
> IsXactIsoLevelXactSnapshotBased, so if there are no objections, I'll
> switch to XactUsesPerXactSnapshot. The current code uses a macro
> without parentheses; are you
On 02/09/10 06:46, Fujii Masao wrote:
On Wed, Sep 1, 2010 at 4:11 PM, Heikki Linnakangas
wrote:
The obvious next question is how to wait for multiple sockets and a latch at
the same time? Perhaps we should have a select()-like interface where you
can pass multiple file descriptors. Then again,
Robert Haas wrote:
> The current definition is:
>
> #define IsXactIsoLevelSerializable (XactIsoLevel >=
> XACT_REPEATABLE_READ)
>
> ...which is certainly a bit odd, since you'd think it would be
> comparing against XACT_SERIALIZABLE given the name.
Precisely why I want to rename it. ;-)
>
On Thu, Sep 2, 2010 at 11:41 AM, Kevin Grittner
wrote:
>> How about IsXactIsoLevelSnapshot? Just to be a bit shorter.
>
> I need two macros -- one which has the same definition as the
> current IsXactIsoLevelSerializable, to be used everywhere the old
> macro name currently is used, which conveys
Tom Lane wrote:
> You're pulling from that broken git repository, aren't you?
I'm pulling from git, so apparently it's a broken repository.
I guess I'll give up on the installcheck-world target until we have
a working git repository.
Thanks,
-Kevin
--
Sent via pgsql-hackers mailing lis
Peter Eisentraut writes:
>>> And what about 9.1alpha1?
>>
>> Peter muttered something about doing that this week.
> The major blocker is preparing the release notes. If someone has time
> for that ...
Done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
"Kevin Grittner" writes:
> I just started trying out the new make targets with "world" in the name.
> `make world` and `make install-world` seem to work (unless I'm missing
> something), but `make installcheck-world` ends with "Error 2".
You're pulling from that broken git repository, aren't you
I just started trying out the new make targets with "world" in the name.
`make world` and `make install-world` seem to work (unless I'm missing
something), but `make installcheck-world` ends with "Error 2". The
relevant bits seem to be:
make[2]: Entering directory
`/home/kgrittn/git/postgresql/
On Wed, Sep 01, 2010 at 04:53:38PM +0900, Fujii Masao wrote:
> - down
> When that situation occurs, the master shuts down immediately.
> Though this is unsafe for the system requiring high availability,
> as far as I recall, some people wanted this mode in the previous
> discussion.
Oracle
Max Bowsher wrote:
> On 02/09/10 14:40, Michael Haggerty wrote:
>> Robert Haas wrote:
>>> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty
>>> wrote:
What weirdness, exactly, are you discussing now? I've lost track of
which problem(s) are still unresolved.
>>> Lots of commits that look
Robert Haas wrote:
>> I could knock out a couple other files from the main patch if
>> people considered it acceptable to enable the SHMQueueIsDetached
>> function now, which the patch uses in several places within
>> asserts. I would remove the #ifdef NOT_USED from around the
>> (very short)
On 02/09/10 17:06, Simon Riggs wrote:
On Thu, 2010-09-02 at 08:59 -0400, Robert Haas wrote:
On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggs wrote:
"All standbys" has no meaning without registration. It is not a question
that needs an answer.
Tell that to the DBA. I bet s/he knows what "all stan
On 02/09/10 14:40, Michael Haggerty wrote:
> Robert Haas wrote:
>> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty
>> wrote:
>>> What weirdness, exactly, are you discussing now? I've lost track of
>>> which problem(s) are still unresolved.
>>
>> Lots of commits that look like this:
>>
>> commit
On Thu, Sep 2, 2010 at 10:06 AM, Simon Riggs wrote:
> On Thu, 2010-09-02 at 08:59 -0400, Robert Haas wrote:
>> On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggs wrote:
>> > "All standbys" has no meaning without registration. It is not a question
>> > that needs an answer.
>>
>> Tell that to the DBA. I
On Thu, 2010-09-02 at 08:59 -0400, Robert Haas wrote:
> On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggs wrote:
> > "All standbys" has no meaning without registration. It is not a question
> > that needs an answer.
>
> Tell that to the DBA. I bet s/he knows what "all standbys" means.
> The fact that
Robert Haas writes:
> Tell that to the DBA. I bet s/he knows what "all standbys" means.
> The fact that the system doesn't know something doesn't make it
> unimportant.
Well as a DBA I think I'd much prefer to attribute "votes" to each
standby so that each ack is weighted. Let me explain in more
Robert Haas wrote:
> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty wrote:
>> What weirdness, exactly, are you discussing now? I've lost track of
>> which problem(s) are still unresolved.
>
> Lots of commits that look like this:
>
> commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb
> Author: Po
Jeff Davis writes:
> I think I see how this fixes the problem, but I still don't completely
> understand.
> Why can't we just make a real copy of the tuple descriptor for the type
> cache entry, rather than sharing it between the relcache and the type
> cache?
The issue isn't really about whethe
On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty wrote:
> Robert Haas wrote:
>> On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander wrote:
That definitely didn't fix it, although I'm not quite sure why. Can
you throw the modified CVS you ran this off of up somewhere I can
rsync it?
>>
On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggs wrote:
> "All standbys" has no meaning without registration. It is not a question
> that needs an answer.
Tell that to the DBA. I bet s/he knows what "all standbys" means.
The fact that the system doesn't know something doesn't make it
unimportant.
I
On Thu, 2010-09-02 at 15:15 +0300, Heikki Linnakangas wrote:
> On 02/09/10 15:03, Simon Riggs wrote:
> > On Thu, 2010-09-02 at 19:24 +0900, Fujii Masao wrote:
> >> On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
> >> wrote:
> >>> That requirement falls out from the handling of disconnected sta
On 02/09/10 15:03, Simon Riggs wrote:
On Thu, 2010-09-02 at 19:24 +0900, Fujii Masao wrote:
On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
wrote:
That requirement falls out from the handling of disconnected standbys. If a
standby is not connected, what does the master do with commits? If
Robert Haas wrote:
> On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander wrote:
>>> That definitely didn't fix it, although I'm not quite sure why. Can
>>> you throw the modified CVS you ran this off of up somewhere I can
>>> rsync it?
>> no rsync server on that box, but I put up a tarball for you at
On Thu, 2010-09-02 at 19:24 +0900, Fujii Masao wrote:
> On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
> wrote:
> > That requirement falls out from the handling of disconnected standbys. If a
> > standby is not connected, what does the master do with commits? If the
> > answer is anything else
On Thu, Sep 2, 2010 at 7:54 PM, Dimitri Fontaine wrote:
>> One issue of the base backup function is that the operation will
>> be a long transaction. So, non-transactional special commands,
>> as like as VACUUM, would be better in terms of performance.
>> For example, CREATE or ALTER REPLICATION.
Itagaki Takahiro writes:
>> http://github.com/dimitri/pg_basebackup
>>
>>> There's been some talk of being able to stream a base backup over the
>>> replication connection too, which would be extremely handy.
>>
>> Yes please ! :)
>
> One issue of the base backup function is that the operation wi
On 30 August 2010 13:14, Fujii Masao wrote:
> I think that the advantage of registering standbys is that we can
> specify which WAL files the master has to keep for the upcoming
> standby. IMO, it's usually called together with pg_start_backup
> as follows:
>
> SELECT register_standby('foo', pg
On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
wrote:
> That requirement falls out from the handling of disconnected standbys. If a
> standby is not connected, what does the master do with commits? If the
> answer is anything else than acknowledge them to the client immediately, as
> if the st
On Thu, Sep 2, 2010 at 6:41 PM, Dimitri Fontaine wrote:
> In fact you don't need shell access here, it's rather easy to stream the
> base backup from the libpq connection, as implemented here :
>
> http://github.com/dimitri/pg_basebackup
>
>> There's been some talk of being able to stream a base
"David E. Wheeler" writes:
> On Sep 1, 2010, at 10:52 AM, Thom Brown wrote:
>
ould appreciate the recipe for removing the NULLs.
>>>
>>> WHERE clause :P
>>
>> There may be cases where that's undesirable, such as there being more
>> than one aggregate in the SELECT list, or the column being
Heikki Linnakangas writes:
> Hmm, that's clever. I was thinking that you'd initialize the standby from an
> existing backup, and in that context the standby would not need to connect
> to the master except via the replication connection. To take a base backup,
> you'll need not only that but also
On Thu, Sep 2, 2010 at 05:13, Robert Haas wrote:
> On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander wrote:
>>> That definitely didn't fix it, although I'm not quite sure why. Can
>>> you throw the modified CVS you ran this off of up somewhere I can
>>> rsync it?
>>
>> no rsync server on that box,
(2010/09/02 13:30), KaiGai Kohei wrote:
> (2010/09/02 12:38), Robert Haas wrote:
>> 2010/9/1 KaiGai Kohei:
>>> (2010/09/02 11:57), Robert Haas wrote:
2010/9/1 KaiGai Kohei:
> Right now, it stands on a strict assumption that considers operators
> implemented with built-in functions are
50 matches
Mail list logo
