> Rule it out. Note you should be looking at pg_am.amcanorder, not
> hardwiring knowledge of particular index types.
Sorry, I replied "ok" too fast...
I can look at pg_am.amcanorder, but I would still need the ScanKey to be used
by tuplesort; and I can't find any other way of doing it than ca
On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sat, 2010-01-23 at 21:40 +, Greg Stark wrote:
> >> On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs wrote:
> >>> What is your proposed way of handling buffer pin deadlocks? That will be
> >>> acceptable and wo
On Mon, 2010-01-25 at 09:08 +0200, Peter Eisentraut wrote:
> On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote:
> > Why do we have a parameter called "default_do_language" when we don't
> > have a parameter called "default_language"?
>
> According to the SQL standard, the default language for C
Simon Riggs wrote:
> On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote:
>> Would this simple scheme work:
>>
>> When the startup process has waited for a short while (ie
>> deadlock_timeout), it sends the signal "please check if you're holding a
>> pin on buffer X" to all backends. When a
Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote:
>>> Would this simple scheme work:
>>>
>>> When the startup process has waited for a short while (ie
>>> deadlock_timeout), it sends the signal "please check if you're holding a
>>> pin on
On Mon, 2010-01-25 at 10:59 +0200, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > Simon Riggs wrote:
> >> On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote:
> >>> Would this simple scheme work:
> >>>
> >>> When the startup process has waited for a short while (ie
> >>> deadlock
Thanks for the review! And, sorry for the delay.
On Thu, Jan 21, 2010 at 11:10 PM, Heikki Linnakangas
wrote:
> I don't think we should do the check XLogWrite(). There's really no
> reason to kill the standby connections before the next checkpoint, when
> the old WAL files are recycled. XLogWrite(
On sön, 2010-01-24 at 21:29 -0800, Scott Bailey wrote:
> I think listagg or string_agg would be the most appropriate names. Oh
> and before Oracle had wm_concat, Tom Kyte wrote a function called
> stragg that was pretty popular.
Well,
xmlagg -> concatenates values to form xml datum
array_agg ->
2010/1/25 Peter Eisentraut :
> On sön, 2010-01-24 at 21:29 -0800, Scott Bailey wrote:
>> I think listagg or string_agg would be the most appropriate names. Oh
>> and before Oracle had wm_concat, Tom Kyte wrote a function called
>> stragg that was pretty popular.
>
> Well,
>
> xmlagg -> concatenates
On 23/01/2010 5:30 AM, Radu Ilie wrote:
On a Windows server under heavy load of NOTIFY events, entries in
pg_listener table for some events are deleted. It is like UNLISTEN was
called.
This has been reported on -general, then -bugs, now -hackers, and seems
to just get ignored. The poster has d
Hello
I hope, so this version is more readable and more clean. I removed
some not necessary checks.
regards
Pavel
2010/1/22 Robert Haas :
> On Fri, Jan 22, 2010 at 7:19 AM, Pavel Stehule
> wrote:
>> here is new variant. Add scan_state flag "valid" and enhance
>> protection against execution b
Craig Ringer wrote:
On 23/01/2010 5:30 AM, Radu Ilie wrote:
On a Windows server under heavy load of NOTIFY events, entries in
pg_listener table for some events are deleted. It is like UNLISTEN was
called.
This has been reported on -general, then -bugs, now -hackers, and seems
to just get igno
Pavel Stehule writes:
> 2010/1/25 Peter Eisentraut :
>> xmlagg -> concatenates values to form xml datum
>> array_agg -> concatenates values to form array datum
>> ??? -> concatenates values to form string datum
>>
>> So it's pretty clear that listagg does not fit into this scheme.
> when you def
Given this thread on pgsql-general I wonder if we should have
something like 1 in every 1,000 CHECK_FOR_INTERRUPTS check if the
client socket is still open.
This has come up in the past and the concern was that syscalls would
be way too slow to put in critical loops but perhaps if it's only done
o
2010/1/25 Tom Lane :
> Pavel Stehule writes:
>> 2010/1/25 Peter Eisentraut :
>>> xmlagg -> concatenates values to form xml datum
>>> array_agg -> concatenates values to form array datum
>>> ??? -> concatenates values to form string datum
>>>
>>> So it's pretty clear that listagg does not fit into
Simon Riggs wrote:
> It's clearly a
> lower priority than other code based upon feedback from the Hot Standby
> user group.
What's the "the Hot Standby user group"?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On Mon, 2010-01-25 at 16:22 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > It's clearly a
> > lower priority than other code based upon feedback from the Hot Standby
> > user group.
>
> What's the "the Hot Standby user group"?
A group of people who have an interest in using Hot Stand
On Mon, Jan 25, 2010 at 3:55 AM, Simon Riggs wrote:
> On Mon, 2010-01-25 at 09:08 +0200, Peter Eisentraut wrote:
>> On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote:
>> > Why do we have a parameter called "default_do_language" when we don't
>> > have a parameter called "default_language"?
>>
>
On Mon, 2010-01-25 at 09:30 -0500, Robert Haas wrote:
> +1 for removing default_do_language, too.
+1 for removing default_do_language OR adding default_language.
I prefer a hard-wired default of PLpgSQL, so a missing language
statement on a DO block is always interpreted the same.
--
Simon Ri
--On 25. Januar 2010 09:30:56 -0500 Robert Haas
wrote:
This will turn into
another setting like search_path and standard_conforming_strings that
can break working code if the actual value doesn't match the
anticipated value. I can't figure out why someone would want to use
this even if we
On Monday, January 25, 2010, Stefan Kaltenbrunner
wrote:
> Craig Ringer wrote:
>
> On 23/01/2010 5:30 AM, Radu Ilie wrote:
>
> On a Windows server under heavy load of NOTIFY events, entries in
> pg_listener table for some events are deleted. It is like UNLISTEN was
> called.
>
>
> This has been re
2010/1/25 Tom Lane :
> Pavel Stehule writes:
>> 2010/1/25 Peter Eisentraut :
>>> xmlagg -> concatenates values to form xml datum
>>> array_agg -> concatenates values to form array datum
>>> ??? -> concatenates values to form string datum
>>>
>>> So it's pretty clear that listagg does not fit into
2010/1/24 Tom Lane :
> Simon Riggs writes:
>> On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
>>> No performance issues
>
>> ISTM that this class of function is inherently dangerous performance
>> wise.
>
>> * It looks incredibly easy to construct enormous lists. We should test
>> the ex
2010/1/25 Baron Schwartz :
> Hi Cédric,
>
> On Sun, Jan 24, 2010 at 5:11 PM, Cédric Villemain
> wrote:
>> 'psql --help mysql' (or 'psql --tips mysql' ) might be good to call a
>> special helper : I don't see the point to introduce that kind of
>> things when it is useless for most of our users.
>
Hello
I can't to create module on pgfoundry. It is probably access denied
problem. Can somebody help me with this?
[pa...@nemesis pstcoll]$ cvs -d
:ext:ok...@cvs.pgfoundry.org:/cvsroot/pstcollection import pstcoll
no-vendor initial-release
Password:
Cannot access /cvsroot/pstcollection/CVSROOT
On Sun, Jan 24, 2010 at 9:16 PM, Takahiro Itagaki
wrote:
> I found a couple of incomplete syntax when I was adjusting psql
> automatic tab completion for HEAD.
So, I'm slightly confused about whether you want to fix tab completion
or behavior, but...
> 1. We cannot specify tablespace options on
2010/1/25 KaiGai Kohei :
> Or, are you saying to test diamond-inheritance cases?
Please go back and read the test case that I already proposed.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On Sat, Jan 23, 2010 at 06:40:03PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 23, 2010 at 16:16, Tim Bunce wrote:
> > On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
> >> On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
> >> I'd vote for use warnings; as well.
> >
> > I would to, but
If this option is designed to help people's transition - basically to
get to them before they've got to most of the manual - having to turn
it on will be pointless. It needs to be active by default. A way to
avoid it being a default option in psql may be setting an alias as
part of package installa
Tim Bunce wrote:
FYI I've an updated patch ready but I'll wait till the commitfest has
got 'closer' as there's a fair chance a further update will be needed
anyway to make a patch that applies cleanly.
I want to deal with this today or tomorrow, so don't sit on it, please.
cheers
andr
--On 25. Januar 2010 11:39:21 +0900 KaiGai Kohei
wrote:
(echo "CREATE TABLE t (a int);"
for i in `seq 0 9`; do
echo "CREATE TABLE s$i (b int) INHERITS(t);"
for j in `seq 0 9`; do
echo "CREATE TABLE v$i$j (c int) INHERITS(s$i);"
for k in `seq 0 9`; do
* Alastair Bell Turner [100125 11:07]:
> If this option is designed to help people's transition - basically to
> get to them before they've got to most of the manual - having to turn
> it on will be pointless. It needs to be active by default. A way to
> avoid it being a default option in psql may
Alastair "Bell" Turner wrote:
If this option is designed to help people's transition - basically to
get to them before they've got to most of the manual - having to turn
it on will be pointless. It needs to be active by default.
My problem with this whole idea is that it seems to be very
M
On Mon, Jan 25, 2010 at 6:14 PM, Andrew Dunstan wrote:
>
> My problem with this whole idea is that it seems to be very MySQL-specific.
> Why aren't we providing help for users migrating from Oracle, Sybase,
> Informix, Ingres, DB2, SQLServer and Firebird, to name but a few? And if we
> turn all th
Folks,
When sending a patch, please frame and describe it with a simple
declarative sentence, or at most a short paragraph. If English is not
your preferred language, I can edit what you send. In extreme cases,
I can get it translated.
For examples of this kind of clear message, please refer to
On Mon, Jan 25, 2010 at 11:14 AM, Andrew Dunstan wrote:
> Alastair "Bell" Turner wrote:
>>
>> If this option is designed to help people's transition - basically to
>> get to them before they've got to most of the manual - having to turn
>> it on will be pointless. It needs to be active by default.
On Mon, Jan 25, 2010 at 06:06:53PM +0200, Alastair Bell Turner wrote:
<..>
> without having to add a switch to their command lines. It's not going
> to have anything to say to experienced psql users anyway so it would
> probably not bug anyone enough to turn it off.
I would so use this feature goi
Tom Lane wrote:
> It might be better to try a test case with lighter-weight objects,
> say 5 million simple functions.
A dump of that quickly settled into running a series of these:
SELECT proretset, prosrc, probin,
pg_catalog.pg_get_function_arguments(oid) AS funcargs,
pg_catalog.pg_get_fun
On Mon, Jan 25, 2010 at 10:49:55AM -0600, Ross J. Reedstrom wrote:
> On Mon, Jan 25, 2010 at 06:06:53PM +0200, Alastair Bell Turner wrote:
> <..>
> > without having to add a switch to their command lines. It's not going
> > to have anything to say to experienced psql users anyway so it would
> > pr
Kevin Grittner wrote:
Other posts have suggested that "review fests" might be helpful in
this period. Again, it sounds to me, from other posts on this
thread, as though the primary risk is that people working on the
release could see something they couldn't resist getting drawn into
-- taking th
Ross J. Reedstrom wrote:
So a quick mapping of most-needed commands, and a pointer to the docs for the
full
ramifications and subtle differences seems to fit the existing
documentation module.
And that's been done at least twice already:
http://blog.endpoint.com/2009/12/mysql-and-postgres-
Ross J. Reedstrom wrote:
> On Mon, Jan 25, 2010 at 06:06:53PM +0200, Alastair Bell Turner wrote:
> <..>
> > without having to add a switch to their command lines. It's not going
> > to have anything to say to experienced psql users anyway so it would
> > probably not bug anyone enough to turn it of
Greg Smith wrote:
> Kevin Grittner wrote:
>> Other posts have suggested that "review fests" might be helpful
>> in this period. Again, it sounds to me, from other posts on this
>> thread, as though the primary risk is that people working on the
>> release could see something they couldn't resist
Hi!
I poked around a little at pg_standby because of some 'cp: file does
not exist' errors that were cropping up as pg_standby searched around
for .history files.
I added a stat that still outputs debugging information but now we
don't get cp failures, and then added a 'progress' mode. It was a b
Hi Robert,
On Mon, Jan 25, 2010 at 11:41 AM, Robert Haas wrote:
> Maybe instead of (or in addition to) providing MySQL-specific help, we
> should find a way to emphasize the "\d" and "\d table" commands,
Right, it's like "cd" and "ls" at the shell prompt. It's like walking
into a dark room and
Tom Lane wrote:
> It might be better to try a test case with lighter-weight objects,
> say 5 million simple functions.
Said dump ran in about 45 minutes with no obvious stalls or
problems. The 2.2 GB database dumped to a 1.1 GB text file, which
was a little bit of a surprise.
-Kevin
--
S
On Sun, Jan 24, 2010 at 07:25:24PM +0100, Boszormenyi Zoltan wrote:
> The problem that popped up first was that adjust_informix()
> didn't properly deal with structs, remember? I tried some
Yes, that's what made me wondering.
> i.e. IIRC in some cases adjust_informix() was bypassed
> and the stru
On Mon, Jan 25, 2010 at 1:05 PM, Baron Schwartz wrote:
> Hi Robert,
>
> On Mon, Jan 25, 2010 at 11:41 AM, Robert Haas wrote:
>> Maybe instead of (or in addition to) providing MySQL-specific help, we
>> should find a way to emphasize the "\d" and "\d table" commands,
>
> Right, it's like "cd" and
"Kevin Grittner" writes:
> Tom Lane wrote:
>> It might be better to try a test case with lighter-weight objects,
>> say 5 million simple functions.
> Said dump ran in about 45 minutes with no obvious stalls or
> problems. The 2.2 GB database dumped to a 1.1 GB text file, which
> was a little
Greg Stark writes:
> Given this thread on pgsql-general I wonder if we should have
> something like 1 in every 1,000 CHECK_FOR_INTERRUPTS check if the
> client socket is still open.
... and do what? If so, why?
regards, tom lane
--
Sent via pgsql-hackers mailing list (
Robert Haas writes:
> I don't think we can change this because "ALTER COLUMN SET STATISTICS"
> is not new in 8.5. We added (and then removed) "ALTER COLUMN SET
> STATISTICS DISTINCT", but that's not the same thing.
> What we COULD do is add a column option called statistics_target and
> then mak
On 1/25/10 9:45 AM, Selena Deckelmann wrote:
> Hi!
>
> I poked around a little at pg_standby because of some 'cp: file does
> not exist' errors that were cropping up as pg_standby searched around
> for .history files.
>
> I added a stat that still outputs debugging information but now we
> don't
On 1/25/10 7:47 AM, Pavel Stehule wrote:
> Hello
>
> I can't to create module on pgfoundry. It is probably access denied
> problem. Can somebody help me with this?
>
> [pa...@nemesis pstcoll]$ cvs -d
> :ext:ok...@cvs.pgfoundry.org:/cvsroot/pstcollection import pstcoll
> no-vendor initial-releas
Robert Haas wrote:
> Issues that are discussed and resolved in that forum will very
> possibly get brought up again on -hackers and reach a different
> conclusion the second time around. Now if people are OK with
> that, maybe it's OK
I would expect that. Heck, people get that to some degree
2010/1/25 Josh Berkus :
> On 1/25/10 7:47 AM, Pavel Stehule wrote:
>> Hello
>>
>> I can't to create module on pgfoundry. It is probably access denied
>> problem. Can somebody help me with this?
>>
>> [pa...@nemesis pstcoll]$ cvs -d
>> :ext:ok...@cvs.pgfoundry.org:/cvsroot/pstcollection import pst
Tom Lane wrote:
> Did you happen to notice anything about pg_dump's memory
> consumption?
Not directly, but I was running 'vmstat 1' throughout. Cache space
dropped about 2.1 GB while it was running and popped back up to the
previous level at the end.
-Kevin
--
Sent via pgsql-hackers mail
>> My problem with this whole idea is that it seems to be very MySQL-specific.
>> Why aren't we providing help for users migrating from Oracle, Sybase,
>> Informix, Ingres, DB2, SQLServer and Firebird, to name but a few? And if we
>> turn all those on by default, we'll have a pretty horrible banne
> A group of people who have an interest in using Hot Standby, as
> advertised on postgresql.org and Weekly News.
There are pg users who won't be using HS/SR? ;-)
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
All,
Please rename this thread. I think that several people to whom it's
relevant aren't replying to it because of the deceptive name. Thanks.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Michael Meskes írta:
> On Sun, Jan 24, 2010 at 07:25:24PM +0100, Boszormenyi Zoltan wrote:
>
>> The problem that popped up first was that adjust_informix()
>> didn't properly deal with structs, remember? I tried some
>>
>
> Yes, that's what made me wondering.
>
>
>> i.e. IIRC in some cas
On 1/23/10 5:00 PM, Brook Milligan wrote:
> It seems that src/Makefile.shlib has special cases for several
> directories that build loadable modules rather than shared libraries.
> The contrib/adminpack is one of the special cases, but none of the
> other contrib directories are. As a result, they
On Mon, 2010-01-25 at 10:50 -0800, Josh Berkus wrote:
> All,
>
> Please rename this thread. I think that several people to whom it's
> relevant aren't replying to it because of the deceptive name. Thanks.
>
Except that it is. This thread was about whether or not, Mammoth would
be considered to
On Mon, Jan 25, 2010 at 07:52:05PM +0100, Boszormenyi Zoltan wrote:
> But considering all the above, we might not need the new
> compat_informix/struct.pgc regression test. I think it was tested
> already in e.g. preproc/array_of_struct.pgc and preproc/type.pgc
> and the new feature (if accepted) i
"Kevin Grittner" wrote:
> Tom Lane wrote:
>
>> Did you happen to notice anything about pg_dump's memory
>> consumption?
>
> Not directly, but I was running 'vmstat 1' throughout. Cache
> space dropped about 2.1 GB while it was running and popped back up
> to the previous level at the end.
On Wed, 2010-01-20 at 19:32 -0700, James William Pye wrote:
> Apologies ahead of time for the lack pretty graphs. =)
>
> I used two different builds/installations of PG to test as the PL names
> conflict. Both were compiled with the following CFLAGS(pg_config output):
>
> -O2 -Wall -Wmissing-p
Michael Meskes írta:
> On Mon, Jan 25, 2010 at 07:52:05PM +0100, Boszormenyi Zoltan wrote:
>
>> But considering all the above, we might not need the new
>> compat_informix/struct.pgc regression test. I think it was tested
>> already in e.g. preproc/array_of_struct.pgc and preproc/type.pgc
>> and
On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
> xmlagg -> concatenates values to form xml datum
> array_agg -> concatenates values to form array datum
> ??? -> concatenates values to form string datum
concat_agg().
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Jan 25, 2010, at 6:12 AM, Pavel Stehule wrote:
> I am not happy, I thing so we do bigger chaos then it is. But it
> hasn't progress. So I agree with name string_agg. In this case isn't a
> problem rename this function if somebody would.
Could you not use CREATE AGGREGATE to create an alias nam
On Mon, Jan 25, 2010 at 11:09:12AM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
> >
> >FYI I've an updated patch ready but I'll wait till the commitfest has
> >got 'closer' as there's a fair chance a further update will be needed
> >anyway to make a patch that applies cleanly.
>
> I want to
"Kevin Grittner" writes:
> "Kevin Grittner" wrote:
>> Tom Lane wrote:
>>> Did you happen to notice anything about pg_dump's memory
>>> consumption?
> I took a closer look, and there's some bad news, I think. The above
> numbers were from the ends of the range. I've gone back over and
> found
I'm having a hard time trying to understand how everything should be
done in C extensions.
Now I'm trying to understand how and when I should accept/return
cstring vs text and if and how I should take care of any encoding.
I'm trying to output the content of a tsvector as a set of record
pos, wei
On tis, 2010-01-19 at 01:01 +0900, Hitoshi Harada wrote:
> I reviewed this patch today.
Thank you for this very thorough and helpful review. Comments below and
a new patch attached.
> * in namespace.c
> I didn't see why this file has been changed.
> case 0:
>
On Fri, Jan 15, 2010 at 04:02:02AM +, Tim Bunce wrote:
> This is the final plperl patch in the series from me.
>
> Changes in this patch:
>
> - Moved internal functions out of main:: namespace
> into PostgreSQL::InServer and PostgreSQL::InServer::safe
>
> - Restructured Safe compartment
On Mon, Jan 25, 2010 at 2:27 PM, David E. Wheeler wrote:
> On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
>> xmlagg -> concatenates values to form xml datum
>> array_agg -> concatenates values to form array datum
>> ??? -> concatenates values to form string datum
>
> concat_agg().
I like th
When editing pg_hba.conf, I often instinctively try to use tabs, only to
be slightly annoyed because that barely doesn't work out relative to the
default entries, because those are aligned at column 0, 8, 20, 32, 54:
# TYPE DATABASEUSERCIDR-ADDRESS METHOD
hostall
Joshua D. Drake wrote:
My suggestion would be to start a new thread entirely.
And mine would be to drop this whole topic altogether until after the
CommitFest is over, and instead focus on the replication features
already committed that need work before beta can even start. Only
reason I
"Kevin Grittner" writes:
> Leonardo F wrote:
>> New version of the patch, let me know if I can fix/change something
>> else.
> All issues addressed, with one tiny nit-pick -- the get_bit and
> set_bit methods are not part of the SQL standard. I took the liberty
> of removing "SQL-standard" from t
2010/1/25 Peter Eisentraut :
> When editing pg_hba.conf, I often instinctively try to use tabs, only to
> be slightly annoyed because that barely doesn't work out relative to the
> default entries, because those are aligned at column 0, 8, 20, 32, 54:
>
> # TYPE DATABASE USER CIDR-ADDRES
2010/1/25 KaiGai Kohei :
> (2010/01/24 23:29), Magnus Hagander wrote:
>> There is one more option here - use OpenSSL if available. It has
>> functions for secure random number generations
>> (http://www.openssl.org/docs/crypto/RAND_bytes.html). That seems easy
>> enough when OpenSSL is available.
Josh Berkus wrote:
We discussed this issue at LCA where I encountered these bogus error
messages when I was doing the demo of HS. I consider Selena's patch to
be a bug-fix for beta of 9.0, not a feature. Currently the database
reports a lot of false error messages when running in standby mode,
On 1/25/10 1:24 PM, Magnus Hagander wrote:
> 2010/1/25 Peter Eisentraut :
>> When editing pg_hba.conf, I often instinctively try to use tabs, only to
>> be slightly annoyed because that barely doesn't work out relative to the
>> default entries, because those are aligned at column 0, 8, 20, 32, 54:
Greg Sabino Mullane recently shared a script to split schema-only dump
files into a table creation file and a trigger/index/constraint file, for
restore performance reasons.
(http://blog.endpoint.com/2010/01/splitting-postgres-pgdump-into-pre-and.html)
Would it be possible and worthwhile to add fu
On Mon, Jan 25, 2010 at 12:01 PM, Greg Smith wrote:
> I think it's completely reasonable to say that someone could organize
> pgsql-rrreviewers (as an initial working area, maybe another list
> eventually) for periodic ReviewFest during periods where those patches won't
> be considered for commit,
Hi!
On Mon, Jan 25, 2010 at 1:34 PM, Greg Smith wrote:
> Josh Berkus wrote:
>>
>> We discussed this issue at LCA where I encountered these bogus error
>> messages when I was doing the demo of HS. I consider Selena's patch to
>> be a bug-fix for beta of 9.0, not a feature. Currently the database
Selena Deckelmann wrote:
I can scan through the code tonight and look for other cases where
this might be an issue. The main thing I'm looking for is to
distinguish between harmful and non-harmful errors.
Where I think this is going toward is where every line that comes out of
this program
Josh Berkus wrote:
> On 1/25/10 1:24 PM, Magnus Hagander wrote:
> > 2010/1/25 Peter Eisentraut :
> >> When editing pg_hba.conf, I often instinctively try to use tabs, only to
> >> be slightly annoyed because that barely doesn't work out relative to the
> >> default entries, because those are aligne
Ivan Sergio Borgonovo wrote:
The README files might be a good place to start, then browse code.
> Is there any part of the code from where I could learn about:
> - memory allocation for both cstring and text
src/backend/utils/mmgr/README
> - example of returning text (especially if size of
I'm reviewing the patch posted here:
http://archives.postgresql.org/pgsql-hackers/2010-01/msg01579.php
for this commitfest item:
https://commitfest.postgresql.org/action/patch_view?id=259
Patch attached - a few minor changes:
-
1) Updated to apply cleanly ag
Le 26/01/2010 00:04, Joe Conway a écrit :
> I'm reviewing the patch posted here:
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01579.php
> for this commitfest item:
> https://commitfest.postgresql.org/action/patch_view?id=259
>
First, thanks for reviewing my patch.
> Patch attach
(2010/01/26 6:30), Magnus Hagander wrote:
> 2010/1/25 KaiGai Kohei:
>> (2010/01/24 23:29), Magnus Hagander wrote:
>>> There is one more option here - use OpenSSL if available. It has
>>> functions for secure random number generations
>>> (http://www.openssl.org/docs/crypto/RAND_bytes.html). That s
writes:
> Would it be possible and worthwhile to add functionality to pg_restore so
> that with one switch triggers/indexes/constraints could be ignored, and
> with another switch only triggers/indexes/constraints would be restored?
You should probably go back and look at the archives from the la
On Mon, 2010-01-25 at 16:34 -0500, Greg Smith wrote:
> Josh Berkus wrote:
> > We discussed this issue at LCA where I encountered these bogus error
> > messages when I was doing the demo of HS. I consider Selena's patch to
> > be a bug-fix for beta of 9.0, not a feature. Currently the database
> >
Greg Smith writes:
> [ Greg and Selena discuss filing some rough edges off pg_standby ]
Maybe I'm missing something, but I thought pg_standby would be mostly
dead once SR hits the streets. Is it worth spending lots of time on?
The ideas all sound good, I'm just wondering if it's useful effort
a
On 1/25/10 4:09 PM, Tom Lane wrote:
> Greg Smith writes:
>> [ Greg and Selena discuss filing some rough edges off pg_standby ]
>
> Maybe I'm missing something, but I thought pg_standby would be mostly
> dead once SR hits the streets. Is it worth spending lots of time on?
>
> The ideas all sound
Tom Lane wrote:
Maybe I'm missing something, but I thought pg_standby would be mostly
dead once SR hits the streets. Is it worth spending lots of time on?
I have to do the work I outlined regardless, to support installs on
earlier versions (luckily there's few backport issues for this code
(2010/01/26 1:11), Bernd Helmle wrote:
>
>
> --On 25. Januar 2010 11:39:21 +0900 KaiGai Kohei
> wrote:
>
>> (echo "CREATE TABLE t (a int);"
>> for i in `seq 0 9`; do
>> echo "CREATE TABLE s$i (b int) INHERITS(t);"
>> for j in `seq 0 9`; do
>> echo "CREATE TABLE v$i$j (c int) INHERITS(s$i);"
>>
Leonardo F writes:
>> Rule it out. Note you should be looking at pg_am.amcanorder, not
>> hardwiring knowledge of particular index types.
> I can look at pg_am.amcanorder, but I would still need the ScanKey to be used
> by tuplesort; and I can't find any other way of doing it than calling
> _b
Simon Riggs writes:
> On Mon, 2010-01-25 at 09:30 -0500, Robert Haas wrote:
>> +1 for removing default_do_language, too.
> +1 for removing default_do_language OR adding default_language.
> I prefer a hard-wired default of PLpgSQL, so a missing language
> statement on a DO block is always interpr
Tom Lane wrote:
writes:
Would it be possible and worthwhile to add functionality to pg_restore so
that with one switch triggers/indexes/constraints could be ignored, and
with another switch only triggers/indexes/constraints would be restored?
You should probably go back and look at
On Tue, Jan 26, 2010 at 9:08 AM, Simon Riggs wrote:
> Just committed a fix: the server no longer requests 01.history
> at start of archive recovery.
Good.
And I think that writeTimeLineHistory() should also skip the request
of 01.history. Here is the patch to do so. Comments?
Re
1 - 100 of 111 matches
Mail list logo
