Hi,
I see the ExecInitExpr says something like this:
case T_Var:
state = (ExprState *) makeNode(ExprState);
state->evalfunc = ExecEvalVar;
---
But the ExecEvalVar function definition says:
Var*variable = (Var *) e
On 28.03.2011 10:02, Vaibhav Kaushal wrote:
Hi,
I see the ExecInitExpr says something like this:
case T_Var:
state = (ExprState *) makeNode(ExprState);
state->evalfunc = ExecEvalVar;
---
But the ExecEvalVar function definition says:
---
Thanks for the confirmation. I am happy to have understood some basics of
PG.
Also, I think the similar stands for the Const, Param,
CoerceToDomain and CaseTest nodes, right? They too cast the pointer to
another type.
Thanks for the help Heikki. (I could better call you HL, if you dont mind :P
)
On 28.03.2011 10:44, Vaibhav Kaushal wrote:
Also, I think the similar stands for the Const, Param,
CoerceToDomain and CaseTest nodes, right? They too cast the pointer to
another type.
Yep.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing l
YAMAMOTO Takashi wrote:
> this psql session was the only activity to the server at this
> point.
> [no residual SIReadLock]
>> Right, that's because we were using HASH_ENTER instead of
>> HASH_ENTER_NULL. I've posted a patch which should correct that.
> sure, with your patch it seems that
On Sun, Mar 27, 2011 at 11:27 PM, Robert Haas wrote:
> On Sun, Mar 27, 2011 at 5:45 PM, Simon Riggs wrote:
>> I was hoping to fine tune/tweak Sync Rep after feedback during beta,
>> but my understanding of current consensus is that that will be too
>> late to make user visible changes. So I'm pro
On Sun, Mar 27, 2011 at 11:55 PM, Greg Stark wrote:
> Also, for what it's worth I prefer thinking of
> synchronous_commit/synchronous_replication as one big multi-way
> variable:
>
> synchronous_commit = memory | disk | replica-memory | replica-disk |
> replica-visible
That's close enough to my
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs wrote:
>
> You have no basis on which to prevent this.
It's also already on the Open Items list, put there by you.
Why is this even a discussion point?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Supp
On 28/03/11 04:31, Tom Lane wrote:
> David Fetter writes:
>> On Sun, Mar 27, 2011 at 04:51:13PM +, Tom Lane wrote:
>>> Fix plpgsql to release SPI plans when a function or DO block is freed.
>
>> Do the other PLs we ship need similar fixes?
>
> Offhand I think the other PLs leave management o
On 24.03.2011 15:24, Fujii Masao wrote:
On Wed, Mar 23, 2011 at 7:33 PM, Heikki Linnakangas
wrote:
I don't much like the API for this. Walsender shouldn't need to know about
the details of the FE/BE protocol, pq_putbytes_if_available() seems too low
level to be useful.
I think a better API wo
SUBHAM ROY writes:
> I want to know how can we measure the execution time of a query in Postgres
> (Explain analyze will not do). Also is there any tools available in Linux
> for measuring the performance of queries of databases such as Oracle 11g,
> Postgres, etc.
> Any suggestions will be very h
On 28.03.2011 13:14, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs wrote:
You have no basis on which to prevent this.
It's also already on the Open Items list, put there by you.
Why is this even a discussion point?
FWIW, I agree this is an additional feature that we sho
Hi,
I notice that none of the system tables or columns thereof bear any
comments. Is this intentional, or an oversight? I would have thought
comments would be useful since the column names aren't exactly always
self-explanatory.
Thanks
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ix
--On 26. März 2011 21:59:18 -0400 Robert Haas
wrote:
But I think we can just call pg_table_size() regardless in 9.0+; I
believe it'll return the same results as pg_relation_size() on
non-tables. Anyone see a problem with that?
Hmm yeah, seems i was thinking too complicated...here is a cl
On Mon, Mar 28, 2011 at 6:14 AM, Simon Riggs wrote:
> On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs wrote:
>>
>> You have no basis on which to prevent this.
>
> It's also already on the Open Items list, put there by you.
Huh? There is an open item about whether we should merge
synchronous_commi
On Mon, Mar 28, 2011 at 12:48 AM, Fujii Masao wrote:
> If you want to take hot backup from the standby, you need to do the procedure
> explained in
> http://wiki.postgresql.org/wiki/Incrementally_Updated_Backups
It'd be nice to improve this in 9.2. Relying on users to get this
just right seems b
On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
> In 9.0, recovery doesn't read a backup history file. That FATAL error happens
> if recovery ends before it reads the WAL record which was generated by
> pg_stop_backup(). IOW, recovery gets the recovery ending location from WAL
> record
On Mon, Mar 28, 2011 at 12:05 PM, Heikki Linnakangas
wrote:
> On 28.03.2011 13:14, Simon Riggs wrote:
>>
>> On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs
>> wrote:
>>>
>>> You have no basis on which to prevent this.
>>
>> It's also already on the Open Items list, put there by you.
>>
>> Why is th
On Mon, Mar 28, 2011 at 10:59 AM, Simon Riggs wrote:
> On Sun, Mar 27, 2011 at 11:55 PM, Greg Stark wrote:
>
>> Also, for what it's worth I prefer thinking of
>> synchronous_commit/synchronous_replication as one big multi-way
>> variable:
>>
>> synchronous_commit = memory | disk | replica-memory
On 28.03.2011 15:34, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 12:05 PM, Heikki Linnakangas
wrote:
On 28.03.2011 13:14, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs
wrote:
You have no basis on which to prevent this.
It's also already on the Open Items list, put the
On Mon, Mar 28, 2011 at 1:14 PM, Robert Haas wrote:
> but there is certainly no
> open item for adding additional sync rep modes.
In your opinion.
We will have to live with the UI for a long time, yes. I'm trying to
get it right, whether that includes adding an obvious/easy omission or
renamin
On Mon, Mar 28, 2011 at 8:54 AM, Simon Riggs wrote:
> On Mon, Mar 28, 2011 at 1:14 PM, Robert Haas wrote:
>
>> but there is certainly no
>> open item for adding additional sync rep modes.
>
> In your opinion.
Well, as you just pointed out yourself a few minutes ago, I did write
the open item in
On 28.03.2011 15:54, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 1:14 PM, Robert Haas wrote:
but there is certainly no
open item for adding additional sync rep modes.
In your opinion.
Huh? First you say that Robert added an open item about this to the
list, he says that the open item wasn'
On Mon, Mar 28, 2011 at 1:51 PM, Heikki Linnakangas
wrote:
>>> The 'apply' mode would be quite interesting, it would make it easier to
>>> build load-balancing clusters. But the patch isn't up to the task on that
>>> yet - the 'apply' status report is only sent after
>>> wal_receiver_status_inter
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
wrote:
> It would feel at least as logical to control this in the standby.
Now you are being ridiculous. You've spoken strongly against this at
every single step of this journey.
We're well passed the stage of putting anything in that could do
On Sat, Mar 26, 2011 at 9:41 PM, Robert Haas wrote:
> Per previous discussion, I'm going to wrap alpha5 Monday morning
> Eastern time, barring objections.
It seems that the 'make distcheck' build is broken. Apparently we
don't have any automated testing of this? Anyone know what to fix
here?
o
Robert Haas writes:
> On Sat, Mar 26, 2011 at 9:41 PM, Robert Haas wrote:
>> Per previous discussion, I'm going to wrap alpha5 Monday morning
>> Eastern time, barring objections.
> It seems that the 'make distcheck' build is broken. Apparently we
> don't have any automated testing of this? Any
Excerpts from Tom Lane's message of lun mar 28 10:26:59 -0300 2011:
> Robert Haas writes:
> > On Sat, Mar 26, 2011 at 9:41 PM, Robert Haas wrote:
> >> Per previous discussion, I'm going to wrap alpha5 Monday morning
> >> Eastern time, barring objections.
>
> > It seems that the 'make distcheck'
On Mon, Mar 28, 2011 at 9:26 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Mar 26, 2011 at 9:41 PM, Robert Haas wrote:
>>> Per previous discussion, I'm going to wrap alpha5 Monday morning
>>> Eastern time, barring objections.
>
>> It seems that the 'make distcheck' build is broken. Appar
I wrote:
> Robert Haas writes:
>> It seems that the 'make distcheck' build is broken. Apparently we
>> don't have any automated testing of this? Anyone know what to fix
>> here?
> Bruce keeps trying to put cross-references where they mustn't go ...
Quick hack applied. I think there's a better
On Fri, Mar 25, 2011 at 3:18 PM, Robert Haas wrote:
> On Fri, Mar 25, 2011 at 3:32 PM, Heikki Linnakangas
> wrote:
>> On 25.03.2011 16:52, Merlin Moncure wrote:
>>>
>>> Without this bit, the only way to set hint bits going during bufmgr
>>> eviction is to do a visibility check on every tuple, whi
On Mon, Mar 28, 2011 at 9:36 AM, Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> It seems that the 'make distcheck' build is broken. Apparently we
>>> don't have any automated testing of this? Anyone know what to fix
>>> here?
>
>> Bruce keeps trying to put cross-references where they mus
On Mon, Mar 28, 2011 at 9:48 AM, Merlin Moncure wrote:
> I'd like to experiment on this and see what comes out.
Great!
> If the
> bgwriter was to be granted the ability to inspect buffers and set
> hints, it needs to be able to peek in and inspect the buffer itself
> which it currently doesn't d
On 28.03.2011 16:11, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
wrote:
It would feel at least as logical to control this in the standby.
Now you are being ridiculous. You've spoken strongly against this at
every single step of this journey.
I was thinking spec
Robert Haas writes:
> On Mon, Mar 28, 2011 at 9:48 AM, Merlin Moncure wrote:
>> I was thinking about setting a
>> flag in the buffer (BM_HEAP) that gets set by the loader which flags
>> the buffer for later inspection. Is there a simpler way to do this?
> Hmm. That's slightly crufty, but it mi
Hi,
Is there a way to create triggers on system catalog tables like
pg_class, pg_attribute etc...?
Thanks,
Shridhar
Hi,
Is there a way to create triggers on system catalog tables like pg_class,
pg_attribute etc...?
Thanks,
Shridhar
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Triggers-on-system-catalog-tp4267669p4267669.html
Sent from the PostgreSQL - hackers mailing list archive
Tom Lane wrote:
> The major problem with all of this is that the bgwriter has no
> idea which buffers contain heap pages. And I'm not convinced it's
> a good idea to try to let it know that. If we get to the point
> where bgwriter is trying to do catalog accesses, we are in for a
> world of pa
On 03/28/2011 09:25 AM, Robert Haas wrote:
On Sat, Mar 26, 2011 at 9:41 PM, Robert Haas wrote:
Per previous discussion, I'm going to wrap alpha5 Monday morning
Eastern time, barring objections.
It seems that the 'make distcheck' build is broken. Apparently we
don't have any automated testin
On Mon, Mar 28, 2011 at 10:19 AM, Shridhar Polas wrote:
> Hi,
>
> Is there a way to create triggers on system catalog tables like
> pg_class, pg_attribute etc...?
>
No, Postgres does not support triggers on system catalogs; we do not have
DDL triggers either, if that's what you were trying to ach
On Mon, Mar 28, 2011 at 10:11 AM, Heikki Linnakangas
wrote:
> On 28.03.2011 16:11, Simon Riggs wrote:
>>
>> On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
>> wrote:
>>>
>>> It would feel at least as logical to control this in the standby.
>>
>> Now you are being ridiculous. You've spoken s
On Mon, Mar 28, 2011 at 10:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 28, 2011 at 9:48 AM, Merlin Moncure wrote:
>>> I was thinking about setting a
>>> flag in the buffer (BM_HEAP) that gets set by the loader which flags
>>> the buffer for later inspection. Is there a simpler w
Em 28-03-2011 08:14, Thom Brown escreveu:
I notice that none of the system tables or columns thereof bear any
comments. Is this intentional, or an oversight? I would have thought
comments would be useful since the column names aren't exactly always
self-explanatory.
It could be useful in some
Bug #5950 proposes the following test case:
create table t ();
alter table t add childs t;
alter table t add id serial not null primary key;
Most of the back branches dump core because CheckAttributeType() goes
into infinite recursion. That doesn't happen in HEAD, but so far as I
can see that's
On Mon, Mar 28, 2011 at 9:29 AM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> The major problem with all of this is that the bgwriter has no
>> idea which buffers contain heap pages. And I'm not convinced it's
>> a good idea to try to let it know that. If we get to the point
>> where bgwriter i
On Mon, Mar 28, 2011 at 10:47 AM, Tom Lane wrote:
> Bug #5950 proposes the following test case:
>
> create table t ();
> alter table t add childs t;
> alter table t add id serial not null primary key;
>
> Most of the back branches dump core because CheckAttributeType() goes
> into infinite recursi
On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane wrote:
> Bug #5950 proposes the following test case:
>
> create table t ();
> alter table t add childs t;
> alter table t add id serial not null primary key;
>
> Most of the back branches dump core because CheckAttributeType() goes
> into infinite recursio
On Mon, Mar 28, 2011 at 3:11 PM, Heikki Linnakangas
wrote:
> On 28.03.2011 16:11, Simon Riggs wrote:
>>
>> On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
>> wrote:
>>>
>>> It would feel at least as logical to control this in the standby.
>>
>> Now you are being ridiculous. You've spoken st
Robert Haas wrote:
> We also need to consider the issue raised elsewhere - that a naive
> implementation of this could allow the commit to become visible on
> the standby before it becomes visible on the master. That would
> be expensive to prevent, because you'd need an additional set of
> mas
On Mon, Mar 28, 2011 at 9:54 AM, Merlin Moncure wrote:
> On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane wrote:
>> Bug #5950 proposes the following test case:
>>
>> create table t ();
>> alter table t add childs t;
>> alter table t add id serial not null primary key;
>>
>> Most of the back branches dum
Excerpts from Thom Brown's message of lun mar 28 08:14:07 -0300 2011:
> Hi,
>
> I notice that none of the system tables or columns thereof bear any
> comments. Is this intentional, or an oversight? I would have thought
> comments would be useful since the column names aren't exactly always
> sel
On Mon, Mar 28, 2011 at 10:47 AM, Tom Lane wrote:
Bug #5950 proposes the following test case:
create table t ();
alter table t add childs t;
alter table t add id serial not null primary key;
Most of the back branches dump core because CheckAttributeType() goes
into infinite recursion. That do
On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
> In 9.0, recovery doesn't read a backup history file. That FATAL error happens
> if recovery ends before it reads the WAL record which was generated by
> pg_stop_backup(). IOW, recovery gets the recovery ending location from WAL
> record
Merlin Moncure writes:
>> On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane wrote:
>>> I think the most straightforward and reliable fix for this would be to
>>> forbid recursive containment of a rowtype in itself --- ie, the first
>>> ALTER should have been rejected. Can anyone think of a situation whe
On Mon, Mar 28, 2011 at 10:58 AM, Simon Riggs wrote:
> This is a simple patch, containing functionality already discussed and
> agreed and for which code was submitted in this CF.
These statements are simply not accurate. It isn't a simple patch,
the details of how the write and apply modes shou
On Fri, Mar 25, 2011 at 1:32 PM, Alexander Korotkov
wrote:
> I would like to ask you about currency of the work above. I propose to
> develop functionality of GIN and GiST q-gram indexes with following
> features:
> 1) Handle edit distance (e.g. levenshtein distance) and LIKE/ILIKE
> queries(using
* Jan Urbański (wulc...@wulczer.org) wrote:
> On 28/03/11 04:31, Tom Lane wrote:
> >> Do the other PLs we ship need similar fixes?
> >
> > Offhand I think the other PLs leave management of prepared plans to the
> > user. If there are any places where they cache plans behind the scenes,
> > maybe
Robert Haas writes:
> On Fri, Mar 25, 2011 at 1:32 PM, Alexander Korotkov
> wrote:
>> I would like to ask you about currency of the work above. I propose to
>> develop functionality of GIN and GiST q-gram indexes with following
>> features:
> I'm afraid I don't know this code well enough to give
On 03/28/2011 11:14 AM, Tom Lane wrote:
Merlin Moncure writes:
On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane wrote:
I think the most straightforward and reliable fix for this would be to
forbid recursive containment of a rowtype in itself --- ie, the first
ALTER should have been rejected. Can
On Mon, Mar 28, 2011 at 3:42 PM, Robert Haas wrote:
> It might not be dangerous, but the standby currently sends write,
> flush, and apply positions back separately, so the master must decide
> which of those to pay attention to, unless we rework the whole design.
> I actually think the current d
Andrew Dunstan writes:
> On 03/28/2011 11:14 AM, Tom Lane wrote:
>>> I think the most straightforward and reliable fix for this would be to
>>> forbid recursive containment of a rowtype in itself --- ie, the first
>>> ALTER should have been rejected. Can anyone think of a situation where
>>> it w
On 3/27/2011 9:51 PM, Robert Haas wrote:
On Sun, Mar 27, 2011 at 9:41 PM, Jan Wieck wrote:
On 3/27/2011 6:21 PM, Robert Haas wrote:
On Sun, Mar 27, 2011 at 3:25 PM, Jan Wieckwrote:
Since we are talking about stable releases, I think just releasing and
reacquiring the exclusive l
On 3/27/2011 10:43 PM, Tom Lane wrote:
In particular, I thought the direction Jan was headed was to release and
reacquire the lock between truncating off limited-size chunks of the
file. If we do that, we probably *don't* want or need to allow autovac
to be booted off the lock more quickly.
T
On Mon, Mar 28, 2011 at 4:15 PM, Robert Haas wrote:
> On Mon, Mar 28, 2011 at 10:58 AM, Simon Riggs wrote:
>> This is a simple patch, containing functionality already discussed and
>> agreed and for which code was submitted in this CF.
>
> These statements are simply not accurate.
Then you are m
On Mon, Mar 28, 2011 at 1:21 PM, Joseph Adams
wrote:
> Attached is a patch that adds a 'json' contrib module. Although we
> may want a built-in JSON data type in the near future, making it a
> module (for the time being) has a couple advantages:
Is this something you'd hope to get committed at s
On Mon, Mar 28, 2011 at 1:48 PM, Robert Haas wrote:
> On Mon, Mar 28, 2011 at 1:21 PM, Joseph Adams
> wrote:
>> Attached is a patch that adds a 'json' contrib module. Although we
>> may want a built-in JSON data type in the near future, making it a
>> module (for the time being) has a couple adv
On Mon, Mar 28, 2011 at 2:03 PM, Joseph Adams
wrote:
> On Mon, Mar 28, 2011 at 1:48 PM, Robert Haas wrote:
>> On Mon, Mar 28, 2011 at 1:21 PM, Joseph Adams
>> wrote:
>>> Attached is a patch that adds a 'json' contrib module. Although we
>>> may want a built-in JSON data type in the near future,
On Mon, Mar 28, 2011 at 7:27 PM, Tom Lane wrote:
> Robert Haas writes:
> > I'm afraid I don't know this code well enough to give you any
> > meaningful feedback, but I hope someone will.
>
> Really Oleg and Teodor are the only people well-qualified to comment on
> such stuff. (It sounds reasona
hi,
>>> (6) Does the application continue to run relatively sanely, or
>>> does it fall over at this point?
>>
>> my application just exits on the error.
>>
>> if i re-run the application without rebooting postgres, it seems
>> that i will get the error sooner than the first run. (but it might
>
On Thu, Mar 24, 2011 at 11:53 AM, Fujii Masao wrote:
> On Thu, Mar 24, 2011 at 8:34 PM, Simon Riggs wrote:
>> On Thu, Mar 24, 2011 at 11:17 AM, Fujii Masao wrote:
>>> On Wed, Mar 23, 2011 at 5:53 PM, Fujii Masao wrote:
>> Do you still want to work up a patch for this? If so, I can review.
On Sun, Mar 27, 2011 at 10:45 PM, Simon Riggs wrote:
I was hoping to fine tune/tweak Sync Rep after feedback during beta,
but my understanding of current consensus is that that will be too
late to make user visible changes. So I'm proposing this change now,
before Beta, rather than during Beta.
On tor, 2011-03-24 at 16:05 -0400, Peter Eisentraut wrote:
> Anyway, here is a small patch that changes the duplicate_oids script
> to return a nonzero exit status in case of a problem, and then creates
> a global maintainer-check target that checks that and the SGML syntax
> and the NLS thing. Ot
On mån, 2011-03-28 at 09:35 -0400, Robert Haas wrote:
> Actually those are all my fault. Sorry, I'm still learning the ropes.
> I didn't realize xref couldn't be used in the release notes; it looks
> like Bruce used rather than for the things I used
> for.
>
> This is the sort of thing for wh
On mån, 2011-03-28 at 09:54 -0500, Merlin Moncure wrote:
> Well, maybe. In fact, probably. That's like asking in C if it's sane
> to have a structure to contain a pointer back to itself, which of
> course it is.
But this is not a pointer, it's containment. SQL has pointers, too
(reference types)
On Mon, Mar 28, 2011 at 10:56:39PM +0300, Peter Eisentraut wrote:
> On tor, 2011-03-24 at 16:05 -0400, Peter Eisentraut wrote:
> > Anyway, here is a small patch that changes the duplicate_oids script
> > to return a nonzero exit status in case of a problem, and then creates
> > a global maintainer-
On lör, 2011-03-26 at 09:41 -0400, Robert Haas wrote:
> You can't be guaranteed that they won't standardize something
> incompatible no matter what we do. We could choose to do it as you've
> proposed and they could then standardize some weird syntax - the => is
> a fairly relevant example of exac
On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
> * RI triggers should insert COLLATE clauses in generated queries to
> satisfy SQL2008 9.13 SR 4a, which says that RI comparisons use the
> referenced column's collation. Right now you may get either table's
> collation depending on which query t
On sön, 2011-03-27 at 00:20 -0400, Tom Lane wrote:
> but we haven't bumped the protocol version number since 7.4,
> and so I have no faith that clients will behave sensibly
So we will never change the minor protocol version, because we've never
done it and don't know whether it works?
Perhaps the
hubert depesz lubaczewski wrote:
> how come that I can use this backup to make standalone pg, and it
> starts without any problem, but when I start it as sr slave, let
> it run for some time, and then promote to standalone, it breaks?
We need more detail to make much of a guess about that.
-
On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski wrote:
>
> > how come that I can use this backup to make standalone pg, and it
> > starts without any problem, but when I start it as sr slave, let
> > it run for some time, and then promote to standalone
hubert depesz lubaczewski wrote:
> On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
>> hubert depesz lubaczewski wrote:
>>
>>> how come that I can use this backup to make standalone pg, and
<<< it starts without any problem, but when I start it as sr slave,
>>> let it run for som
On Mon, Mar 28, 2011 at 04:53:37PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski wrote:
> > On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
> >> hubert depesz lubaczewski wrote:
> >>
> >>> how come that I can use this backup to make standalone pg, and
> <<< it starts
hubert depesz lubaczewski wrote:
> have you seen this mail -
> http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
Ah, OK.
I have a theory. Can you try it in what would be the failure case,
but run an explicit a CHECKPOINT on the master, wait for
pg_controldata to show that ch
hubert depesz lubaczewski wrote:
> have you seen this mail -
> http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
One more thing: Am I correct in understanding that you are trying to
do a PITR-style backup without using pg_start_backup() and
pg_stop_backup()? If so, why?
-Kev
On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski wrote:
>
> > have you seen this mail -
> > http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
>
> Ah, OK.
>
> I have a theory. Can you try it in what would be the failure case,
> but r
On Mon, Mar 28, 2011 at 05:43:15PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski wrote:
>
> > have you seen this mail -
> > http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
>
> One more thing: Am I correct in understanding that you are trying to
> do a PITR-style ba
Peter Eisentraut writes:
> On sön, 2011-03-27 at 00:20 -0400, Tom Lane wrote:
>> but we haven't bumped the protocol version number since 7.4,
>> and so I have no faith that clients will behave sensibly
> So we will never change the minor protocol version, because we've never
> done it and don't
On 3/28/11 10:21 AM, Joseph Adams wrote:
> Currently, there are no functions for converting to/from PostgreSQL
> values or getting/setting sub-values (e.g. JSONPath). However, I did
> adapt the json_stringify function written by Itagaki Takahiro in his
> patch ( http://archives.postgresql.org/pgsq
I wrote:
> Now if we had a track record showing that we could tweak the protocol
> version without causing problems, it'd be fine with me to do it for this
> usage. But we don't, and this particular case doesn't seem like the
> place to start.
And, btw, a moment's study of the protocol version ch
Peter Eisentraut writes:
> On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
>> * It'd sure be nice if we had some nontrivial test cases that work in
>> encodings besides UTF8. I'm still bothered that the committed patch
>> failed to cover single-byte-encoding cases in upper/lower/initcap.
> W
Excerpts from Tom Lane's message of lun mar 28 21:02:40 -0300 2011:
> Peter Eisentraut writes:
> > On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
> >> * It'd sure be nice if we had some nontrivial test cases that work in
> >> encodings besides UTF8. I'm still bothered that the committed patch
On Mon, Mar 28, 2011 at 9:19 PM, hubert depesz lubaczewski
wrote:
> On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
>> In 9.0, recovery doesn't read a backup history file. That FATAL error happens
>> if recovery ends before it reads the WAL record which was generated by
>> pg_stop_bac
On Tue, Mar 29, 2011 at 12:11 AM, hubert depesz lubaczewski
wrote:
> On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
>> In 9.0, recovery doesn't read a backup history file. That FATAL error happens
>> if recovery ends before it reads the WAL record which was generated by
>> pg_stop_ba
Em 28-03-2011 22:27, Alvaro Herrera escreveu:
Excerpts from Tom Lane's message of lun mar 28 21:02:40 -0300 2011:
I tried. The upper/lower test cases require Turkish characters that
aren't in Latin1. I'm not sure if we can readily produce test cases
that cover both sorting changes and case-fol
On Mon, Mar 28, 2011 at 7:49 PM, Heikki Linnakangas
wrote:
>> pq_flush_if_writable() calls internal_flush() without using PG_TRY block.
>> This seems unsafe because for example pgwin32_waitforsinglesocket()
>> called by secure_write() can throw ERROR.
>
> Perhaps it's time to give up on the assump
A few years ago, this list had a brief conversation on $SUBJECT:
http://archives.postgresql.org/message-id/1215443493.4051.600.ca...@ebony.site
What is notable/surprising about the behavior when two backends have different
values for deadlock_timeout? After sleeping to acquire a lock, each backen
On Mon, Mar 28, 2011 at 08:02:40PM -0400, Tom Lane wrote:
> One thing I noticed but didn't push to committing is that the test case
> has a largely-unnecessary assumption about how the local system's locale
> names spell "utf8". We could eliminate that by having it use the
> trimmed locale names c
97 matches
Mail list logo
