Le 26/03/2011 02:43, Tomas Vondra a écrit :
Dne 26.3.2011 02:05, Joshua Berkus napsal(a):
Tomas,
I spoke to a teacher from a local university last week, mainly as we
were looking for a place where a local PUG could meet regularly. I
realized this could be a good opportunity to head-hunt some
Hello
2011/3/28 David Fetter da...@fetter.org:
On Sun, Mar 27, 2011 at 03:21:18PM +0200, Pavel Stehule wrote:
Hello
Is there some simple possibility to check a rights from stored procedure?
Well, there's the catalog lookup method:
SELECT EXISTS (SELECT 1 FROM pg_catalog.pg_roles WHERE
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 *)
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
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 they
On Sun, Mar 27, 2011 at 11:27 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Mar 27, 2011 at 5:45 PM, Simon Riggs si...@2ndquadrant.com 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
On Sun, Mar 27, 2011 at 11:55 PM, Greg Stark gsst...@mit.edu 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
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs si...@2ndquadrant.com 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
On 28/03/11 04:31, Tom Lane wrote:
David Fetter da...@fetter.org 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
On 24.03.2011 15:24, Fujii Masao wrote:
On Wed, Mar 23, 2011 at 7:33 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
SUBHAM ROY subham@gmail.com 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
On 28.03.2011 13:14, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggssi...@2ndquadrant.com 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
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):
--On 26. März 2011 21:59:18 -0400 Robert Haas robertmh...@gmail.com
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
On Mon, Mar 28, 2011 at 6:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs si...@2ndquadrant.com 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
On Mon, Mar 28, 2011 at 12:48 AM, Fujii Masao masao.fu...@gmail.com 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
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
heikki.linnakan...@enterprisedb.com wrote:
On 28.03.2011 13:14, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggssi...@2ndquadrant.com
wrote:
You have no basis on which to prevent this.
It's also already on the Open Items
On Mon, Mar 28, 2011 at 10:59 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, Mar 27, 2011 at 11:55 PM, Greg Stark gsst...@mit.edu wrote:
Also, for what it's worth I prefer thinking of
synchronous_commit/synchronous_replication as one big multi-way
variable:
synchronous_commit =
On 28.03.2011 15:34, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 12:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.03.2011 13:14, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggssi...@2ndquadrant.com
wrote:
You have no basis on which to prevent
On Mon, Mar 28, 2011 at 1:14 PM, Robert Haas robertmh...@gmail.com 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
On Mon, Mar 28, 2011 at 8:54 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Mar 28, 2011 at 1:14 PM, Robert Haas robertmh...@gmail.com 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
On 28.03.2011 15:54, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 1:14 PM, Robert Haasrobertmh...@gmail.com 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
On Mon, Mar 28, 2011 at 1:51 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Sat, Mar 26, 2011 at 9:41 PM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 26, 2011 at 9:41 PM, Robert Haas robertmh...@gmail.com 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
Excerpts from Tom Lane's message of lun mar 28 10:26:59 -0300 2011:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 26, 2011 at 9:41 PM, Robert Haas robertmh...@gmail.com wrote:
Per previous discussion, I'm going to wrap alpha5 Monday morning
Eastern time, barring objections.
It
On Mon, Mar 28, 2011 at 9:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 26, 2011 at 9:41 PM, Robert Haas robertmh...@gmail.com wrote:
Per previous discussion, I'm going to wrap alpha5 Monday morning
Eastern time, barring objections.
It seems
I wrote:
Robert Haas robertmh...@gmail.com 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
On Fri, Mar 25, 2011 at 3:18 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 25, 2011 at 3:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, Mar 28, 2011 at 9:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Robert Haas robertmh...@gmail.com 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
On Mon, Mar 28, 2011 at 9:48 AM, Merlin Moncure mmonc...@gmail.com 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
On 28.03.2011 16:11, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 28, 2011 at 9:48 AM, Merlin Moncure mmonc...@gmail.com 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.
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 t...@sss.pgh.pa.us 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
On 03/28/2011 09:25 AM, Robert Haas wrote:
On Sat, Mar 26, 2011 at 9:41 PM, Robert Haasrobertmh...@gmail.com 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
On Mon, Mar 28, 2011 at 10:19 AM, Shridhar Polas shridharpo...@gmail.comwrote:
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
On Mon, Mar 28, 2011 at 10:11 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.03.2011 16:11, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It would feel at least as logical to control this in the
On Mon, Mar 28, 2011 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 28, 2011 at 9:48 AM, Merlin Moncure mmonc...@gmail.com wrote:
I was thinking about setting a
flag in the buffer (BM_HEAP) that gets set by the loader which flags
the
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
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us 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
On Mon, Mar 28, 2011 at 10:47 AM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Mar 28, 2011 at 3:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.03.2011 16:11, Simon Riggs wrote:
On Mon, Mar 28, 2011 at 2:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It would feel at least as logical to control this in the
Robert Haas robertmh...@gmail.com 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
On Mon, Mar 28, 2011 at 9:54 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane t...@sss.pgh.pa.us 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
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
On Mon, Mar 28, 2011 at 10:47 AM, Tom Lanet...@sss.pgh.pa.us 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
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 mmonc...@gmail.com writes:
On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane t...@sss.pgh.pa.us 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 10:58 AM, Simon Riggs si...@2ndquadrant.com 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
On Fri, Mar 25, 2011 at 1:32 PM, Alexander Korotkov
aekorot...@gmail.com 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
* 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 a similar
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 25, 2011 at 1:32 PM, Alexander Korotkov
aekorot...@gmail.com 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
On 03/28/2011 11:14 AM, Tom Lane wrote:
Merlin Moncuremmonc...@gmail.com writes:
On Mon, Mar 28, 2011 at 9:47 AM, Tom Lanet...@sss.pgh.pa.us 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
On Mon, Mar 28, 2011 at 3:42 PM, Robert Haas robertmh...@gmail.com 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
Andrew Dunstan and...@dunslane.net 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
On 3/27/2011 9:51 PM, Robert Haas wrote:
On Sun, Mar 27, 2011 at 9:41 PM, Jan Wieckjanwi...@yahoo.com wrote:
On 3/27/2011 6:21 PM, Robert Haas wrote:
On Sun, Mar 27, 2011 at 3:25 PM, Jan Wieckjanwi...@yahoo.comwrote:
Since we are talking about stable releases, I think just
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.
On Mon, Mar 28, 2011 at 4:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 28, 2011 at 10:58 AM, Simon Riggs si...@2ndquadrant.com wrote:
This is a simple patch, containing functionality already discussed and
agreed and for which code was submitted in this CF.
These statements are
On Mon, Mar 28, 2011 at 1:21 PM, Joseph Adams
joeyadams3.14...@gmail.com 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
On Mon, Mar 28, 2011 at 1:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 28, 2011 at 1:21 PM, Joseph Adams
joeyadams3.14...@gmail.com 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
On Mon, Mar 28, 2011 at 2:03 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
On Mon, Mar 28, 2011 at 1:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 28, 2011 at 1:21 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
Attached is a patch that adds a 'json' contrib module.
On Mon, Mar 28, 2011 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
be just a
On Thu, Mar 24, 2011 at 11:53 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Mar 24, 2011 at 8:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Mar 24, 2011 at 11:17 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Mar 23, 2011 at 5:53 PM, Fujii Masao masao.fu...@gmail.com
On Sun, Mar 27, 2011 at 10:45 PM, Simon Riggssi...@2ndquadrant.com 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,
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. Other
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 link rather than xref for the things I used xref
for.
This is the sort of thing
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-check
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 exactly
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 type
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 dep...@depesz.com 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
On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com 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
hubert depesz lubaczewski dep...@depesz.com wrote:
On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com 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
On Mon, Mar 28, 2011 at 04:53:37PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com wrote:
On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com wrote:
how come that I can use this backup to make standalone
hubert depesz lubaczewski dep...@depesz.com 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
hubert depesz lubaczewski dep...@depesz.com 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
On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com 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,
On Mon, Mar 28, 2011 at 05:43:15PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com 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
Peter Eisentraut pete...@gmx.net 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
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 (
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
Peter Eisentraut pete...@gmx.net 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
Excerpts from Tom Lane's message of lun mar 28 21:02:40 -0300 2011:
Peter Eisentraut pete...@gmx.net 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
On Mon, Mar 28, 2011 at 9:19 PM, hubert depesz lubaczewski
dep...@depesz.com 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
On Tue, Mar 29, 2011 at 12:11 AM, hubert depesz lubaczewski
dep...@depesz.com 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
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
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
97 matches
Mail list logo
