Guys,
A configuration wizard would be nice, but it would be a good start to
add a section to the manual on how to do the basic tuning. AFAICS we
don't have one. Clear instructions on how to set the few most important
settings like shared_buffers and checkpoint_timeout/segments would
probably
Tom Lane wrote:
* How much "overhead" disk space are you willing to let Postgres use?
... The third one is a bit weird but
I don't see any other good way to set the checkpoint parameters.
The way I think about the checkpoint settings is:
1. Set checkpoint_timeout to the max. time you're willi
On Thu, Jun 5, 2008 at 2:18 AM, Mayuresh Nirhali
<[EMAIL PROTECTED]> wrote:
>> Most C compilers don't like that either. The standard locution is
>> something like
>>
>> char data[1]; /* VARIABLE LENGTH ARRAY */
>>
>
> So, this is the only issue with Sun Studio compilatio
Tom Lane wrote:
Most C compilers don't like that either. The standard locution is
something like
char data[1]; /* VARIABLE LENGTH ARRAY */
Yes, I tried this already and forgot to mention earlier that with such
patch, I do not see any other errors.
So, this is t
pg_dump restore times can be high when they include many ALTER TABLE ADD
FORIEGN KEY statements, since each statement checks the data to see if
it is fully valid in all cases.
I've been asked "why we run that at all?", since if we dumped the tables
together, we already know they match.
If we had
Mayuresh Nirhali <[EMAIL PROTECTED]> writes:
> Sun Studio does not like array declarations with null as dimenstion.
> So, In pipe.c we have,
> typedef struct
> {
> LWLockId shmem_lock;
> pipe *pipes;
> alert_event *events;
> alert_lock *locks;
> size_t size;
Hello hackers,
During the Oracle migration tutorial by peter at PGCon, I took an action
item for myself to try orafce on Solaris/OpenSolaris.
As pg binaries are bundled with Solaris now (using Sun Studio compiler),
I decided to try out building orafce against the same bundled binaries
(with US
On Wed, 2008-06-04 at 22:18 -0400, Tom Lane wrote:
> [ redirecting thread from -performance to -hackers ]
>
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I've got a test case which shows something related and weird, though not
> > the exact case.
>
> > The queries shown here have significantly d
If the version of the master and the slave is different and we'd still
like to allow log shipping replication, we need a negotiation if WAL
format for the two is compatible. I hope it is not in our scope
and I'm worrying too much.
2008/6/5 Tom Lane <[EMAIL PROTECTED]>:
> "Koichi Suzuki" <[EMA
2008/6/5 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> postgres=# select array_fill('p',array[4,4]);
>> ERROR: could not determine polymorphic type because input has type "unknown"
>
> [ shrug... ] I don't really see a problem with that.
you have t cast in most
On Wed, 4 Jun 2008, Aidan Van Dyk wrote:
I'd love a tool that helped me "analyze" my current running PG database
(and yes, that includes getting *current* settings), and "suggest"
config changes
Fine. To demonstrate why the overhaul is needed, let's start designing a
simple tool whose sole
Robert Treat wrote:
If you are calling pg_dump with different flags, it seems likely your breaking
diff equality anyway so I'm not sure how valid that is.
What about different users? Different connection options will result in
the same file but it breaks diff-dump tools. I don't see the point o
* Greg Smith <[EMAIL PROTECTED]> [080604 22:14]:
> So everything you mentioned is either recently added/documented or being
> actively worked on somewhere, and the first two were things I worked on
> myself after noticing they were missing. Believe me, I feel the items
> that still aren't ther
[ redirecting thread from -performance to -hackers ]
Simon Riggs <[EMAIL PROTECTED]> writes:
> I've got a test case which shows something related and weird, though not
> the exact case.
> The queries shown here have significantly different costs, depending
> upon whether we use tables a or b in t
On Wed, 4 Jun 2008, Aidan Van Dyk wrote:
* Are backends always writing out dirty buffers because there are no free
ones? This might mean tweaking settings affecting bgwriter.
What you mean on the first one is "are backends always writing out dirty
buffers becuase there are no *clean* ones";
On Jun 4, 2008, at 6:28 PM, Greg Smith wrote:
Josh Berkus pointed out that he already had the "expert system" part
of this problem solved pretty well with a spreadsheet:
http://pgfoundry.org/docman/view.php/1000106/84/calcfactors.sxc
(that's in the OpenOffice Calc format if you don't kno
On Wed, 4 Jun 2008, Andrew Dunstan wrote:
Tom Lane wrote:
* Can we build a "configuration wizard" to tell newbies what settings
they need to tweak?
That would trump all the other suggestions conclusively. Anyone good at
expert systems?
Sigh. I guess we need to start over again.
Last year
On Jun 4, 2008, at 5:23 PM, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
* Can we build a "configuration wizard" to tell newbies what
settings
they need to tweak?
That would trump all the other suggestions conclusively. Anyone
good at
expert systems?
How
* Tom Lane <[EMAIL PROTECTED]> [080604 20:46]:
> If those aren't enough questions, what else must we ask? Or maybe they
> aren't the right questions at all --- maybe we should ask "is this a
> dedicated machine or not" and try to extrapolate everything else from
> what we (hopefully) can find ou
"Koichi Suzuki" <[EMAIL PROTECTED]> writes:
> Well, WAL format doesn't only depend on WAL itself, but also depend on
> each resource manager. If we introduce WAL format version
> identification, ISTM that we have to take care of the matching of
> resource manager in the master and the slave as we
Greg Smith <[EMAIL PROTECTED]> writes:
> On Wed, 4 Jun 2008, Tom Lane wrote:
>> The real problem we need to solve is how to allow newbies to have the
>> system auto-configured to something that more or less solves their
>> problems. Putting the config settings in XML does not accomplish that,
>> a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * Can we build a "configuration wizard" to tell newbies what settings
>> they need to tweak?
> That would trump all the other suggestions conclusively. Anyone good at
> expert systems?
How far could we get with the answers to just t
On Tue, 3 Jun 2008, Tom Lane wrote:
Well, the stuff included into the dump by pg_dump -v is informative,
too. But we stopped doing that by default because of complaints.
I remain unconvinced that this proposal won't suffer the same fate.
I think it would be reasonable to only include the list
On Wed, 4 Jun 2008, Tom Lane wrote:
The real problem we need to solve is how to allow newbies to have the
system auto-configured to something that more or less solves their
problems. Putting the config settings in XML does not accomplish that,
and neither does putting them inside the database.
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * Can we build a "configuration wizard" to tell newbies what settings
>> they need to tweak?
> It's certainly one thing to create an initial postgresql.conf from
> scratch after some inquiry, but a different level of problems to deal
>
Well, WAL format doesn't only depend on WAL itself, but also depend on
each resource manager. If we introduce WAL format version
identification, ISTM that we have to take care of the matching of
resource manager in the master and the slave as well.
2008/6/4 Heikki Linnakangas <[EMAIL PROTECTED]>
Tom Lane wrote:
* Can we build a "configuration wizard" to tell newbies what settings
they need to tweak?
That would trump all the other suggestions conclusively. Anyone good at
expert systems?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Tom Lane wrote:
>
> * Can we present the config options in a more helpful way (this is 99%
> a documentation problem, not a code problem)?
>
> * Can we build a "configuration wizard" to tell newbies what settings
> they need to tweak?
It's certainly one thing to create an initial postgresql.co
"Pavel Stehule" wrote:
>2008/6/4 David E. Wheeler <[EMAIL PROTECTED]>:
>>
>> Exactly. The issue is that application developers, who are not DBAs, have no
>> idea how to tune PostgreSQL, and postgresql.conf is daunting and confusing.
>> So they use a different database that's "faster".
>
>do you th
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> postgres=# select array_fill('p',array[4,4]);
> ERROR: could not determine polymorphic type because input has type "unknown"
[ shrug... ] I don't really see a problem with that.
> I can use hack:
> CREATE OR REPLACE FUNCTION array_fill(dv text, dim
On Jun 4, 2008, at 13:57, Tom Lane wrote:
So I think we should stop worrying about the file format and think
about
these two problems:
* Can we present the config options in a more helpful way (this is 99%
a documentation problem, not a code problem)?
* Can we build a "configuration wizard"
If I can add my 2 cents as the end user, IMHO having the configuration
file
in the xml format is unnecessary and only makes it less user-friendly.
Thanks,
Michael.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Wednesday, June 04, 2008 4:5
2008/6/4 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> idealized code:
>
>> a = array_set(array[10,10]); // untyped null array
>> a[10,10] = 'text'; -- now array is typed
>
> And how did you declare 'a'? This seems like a solution in search of a
> problem.
>
you ha
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> idealized code:
> a = array_set(array[10,10]); // untyped null array
> a[10,10] = 'text'; -- now array is typed
And how did you declare 'a'? This seems like a solution in search of a
problem.
regards, tom lane
--
Sent via p
2008/6/4 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/6/4 Tom Lane <[EMAIL PROTECTED]>:
>>> If you mean an array of nulls, it still has to have an element type.
>
>> I know it - but there was discus about untyped array for empty arrays
>> like ARRAY[]
>
> Wha
On Jun 4, 2008, at 1:57 PM, Tom Lane wrote:
* Can we build a "configuration wizard" to tell newbies what settings
they need to tweak?
Probably. Given the demographics of a lot of the newbies is
Windows this likely needs to be a pointy-clicky sort of thing
if it's going to be widely useful.
D
On Wed, 2008-06-04 at 16:33 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > We have
> > * relhasindex (bool) set by CREATE INDEX but not unset by DROP INDEX
> > * relhasrules (bool)
> > * reltriggers (int2) set by CREATE and DROP, since its an integer
>
> Right.
>
> > If CR
Greg Smith <[EMAIL PROTECTED]> writes:
> On Wed, 4 Jun 2008, Andreas Pflug wrote:
>> IMHO the best compromise in machine and human readability is an XML format.
> If the primary PostgreSQL configuration file becomes XML I will quit
> working with the project. I'm not kidding.
I have no particul
On Jun 4, 2008, at 13:12, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
I'm not much into MySQL, but in the work I've done with it, I've had
to create /etc/my.cnf myself. There *is* no configuration file
configuring MySQL until that file is created, is there? So there is
no
On Jun 4, 2008, at 13:31, Pavel Stehule wrote:
do you thing, so any better config can help? It's not possible. And
you can't tune database without well knowledge of applications that
use database. Any automatic tools are joy for child. But some default
PostgreSQL parameters are not optimal.
A
On Wed, 4 Jun 2008, Andreas Pflug wrote:
When reading this thread, I'm wondering if anybody ever saw a config file for
a complex software product that was easily editable and understandable.
I would recommend Apache's httpd.conf as an example of something that's
easy to edit and follow. Like
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/6/4 Tom Lane <[EMAIL PROTECTED]>:
>> If you mean an array of nulls, it still has to have an element type.
> I know it - but there was discus about untyped array for empty arrays
> like ARRAY[]
What's that have to do with array_init? It will not
Tom Lane wrote:
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
2008/6/4 Tom Lane <[EMAIL PROTECTED]>:
Huh? That's completely nonsensical ... where will you determine the
type of the array, if you don't have a sample element?
it is nonsens in current postgres. But null array
2008/6/4 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/6/4 Tom Lane <[EMAIL PROTECTED]>:
>>> Huh? That's completely nonsensical ... where will you determine the
>>> type of the array, if you don't have a sample element?
>
>> it is nonsens in current postgres.
Simon Riggs <[EMAIL PROTECTED]> writes:
> We have
> * relhasindex (bool) set by CREATE INDEX but not unset by DROP INDEX
> * relhasrules (bool)
> * reltriggers (int2) set by CREATE and DROP, since its an integer
Right.
> If CREATE INDEX can take a Share lock and can update pg_class, why would
>
2008/6/4 David E. Wheeler <[EMAIL PROTECTED]>:
> On Jun 3, 2008, at 20:48, Greg Smith wrote:
>
>> Correct, but completely off-topic regardless. One problem to be solved
>> here is to take PostgreSQL tuning from zero to, say, 50% automatic. Wander
>> the user lists for a few months; the number of c
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/6/4 Tom Lane <[EMAIL PROTECTED]>:
>> Huh? That's completely nonsensical ... where will you determine the
>> type of the array, if you don't have a sample element?
> it is nonsens in current postgres. But null array is castable to anyarray no?
If
On Wed, 2008-06-04 at 10:59 -0400, Tom Lane wrote:
> Decibel! <[EMAIL PROTECTED]> writes:
> > Ok, I'll take a stab at such a list. Can anyone think of any reasons
> > why CREATE TRIGGER couldn't get by with ShareLock?
>
> pg_class.reltriggers.
ISTM that we do this in many ways on pg_class, if
2008/6/4 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I put fill value on end, because it is like default value:
>
>> array_set(array[2,2]);
>> array_set(array[2,2], 0);
>
> Huh? That's completely nonsensical ... where will you determine the
> type of the array, i
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> I'm not much into MySQL, but in the work I've done with it, I've had
> to create /etc/my.cnf myself. There *is* no configuration file
> configuring MySQL until that file is created, is there? So there is no
> configuration to learn at first.
P
On Jun 4, 2008, at 12:48, Andrew Dunstan wrote:
I'm not much into MySQL, but in the work I've done with it, I've
had to create /etc/my.cnf myself. There *is* no configuration file
configuring MySQL until that file is created, is there? So there is
no configuration to learn at first. I'm not
David E. Wheeler wrote:
On Jun 4, 2008, at 11:22, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
Exactly. The issue is that application developers, who are not DBAs,
have no idea how to tune PostgreSQL, and postgresql.conf is daunting
and confusing. So they use a different da
On Jun 4, 2008, at 11:22, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
Exactly. The issue is that application developers, who are not DBAs,
have no idea how to tune PostgreSQL, and postgresql.conf is daunting
and confusing. So they use a different database that's "faster".
I
On Wed, Jun 4, 2008 at 11:31 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > I have a need to find out the meaning of a backend exiting unexpectedly
> with
> > exit code 2. Leafing through the source of 8.1 I can't really find it.
>
> But are you running
"Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> I have a need to find out the meaning of a backend exiting unexpectedly with
> exit code 2. Leafing through the source of 8.1 I can't really find it.
But are you running 8.1? In 8.2 and up this is the expected result from
SIGQUIT.
On Wed, 2008-06-04 at 14:23 -0400, Tom Lane wrote:
> That is covered by pg_control, at least to the extent of forcing the
> same value of LC_COLLATE.
But the same LC_COLLATE means different things on different systems.
Even "en_US" means something different on Mac versus Linux.
Regards,
J
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Wed, 2008-06-04 at 14:17 +0300, Heikki Linnakangas wrote:
>> These are already covered by the information in pg_control.
> Another thing that can change between systems is the collation behavior,
> which can corrupt indexes (and other bad things).
That
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Exactly. The issue is that application developers, who are not DBAs,
> have no idea how to tune PostgreSQL, and postgresql.conf is daunting
> and confusing. So they use a different database that's "faster".
I take it you haven't looked at mysql'
I have a need to find out the meaning of a backend exiting unexpectedly with
exit code 2. Leafing through the source of 8.1 I can't really find it.
Is there anything in postgres which would exit with code 2, or should I be
looking at libraries and junk dragged in by languages?
On Wed, 2008-06-04 at 14:17 +0300, Heikki Linnakangas wrote:
> > Would that also cover possible differences in page size, 32bit OS vs.
> > 64bit OS, different timestamp flavour, etc. issues ? AFAIR, all these
> > things can have an influence on how the data is written and possibly
> > make the WAL
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Exactly. The issue is that application developers, who are not DBAs,
> have no idea how to tune PostgreSQL, and postgresql.conf is daunting
> and confusing. So they use a different database that's "faster".
Changing some of our defaults would
On Jun 4, 2008, at 07:19, Andreas Pflug wrote:
IMHO the best compromise in machine and human readability is an XML
format. It's easily decorateable with comments, easily interpreted
and a pg_settings view could enhance it with even more comments, so
an editor using pgsql functions (to read
On Jun 3, 2008, at 20:48, Greg Smith wrote:
Correct, but completely off-topic regardless. One problem to be
solved here is to take PostgreSQL tuning from zero to, say, 50%
automatic. Wander the user lists for a few months; the number of
completely misconfigured systems out there is conside
On Wed, 2008-06-04 at 11:37 -0400, Tom Lane wrote:
> This thread is getting out of hand, actually.
Agreed. We should start new threads for specific things. Please.
> However, since by definition pg_control doesn't change in a minor
> upgrade, there isn't any easy way to enforce a rule like "sla
It might depend on the tokens..
Are ">=", "++" etc single tokens ?
On Wednesday 04 June 2008 17:06:44 Tom Lane wrote:
> Mike Aubury <[EMAIL PROTECTED]> writes:
> > On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
> >> There is some small magic to know when to have blanks in between and
Mike Aubury <[EMAIL PROTECTED]> writes:
> On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
>> There is some small magic to know when to have blanks in between and
>> when not, but that should be doable.
> I wouldn't mind having a stab at this if you can expand on the 'magic'
> required.
I wouldn't mind having a stab at this if you can expand on the 'magic'
required.
(I'm interested because I might be able to use the same logic to roll a third
version of the .y for Aubit4GL outside of the Postgresql tree)
On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
> On Wed, Jun
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Well I'm an XML evangelist either. But the usual "commenting out a
> parameter will reset it to default on reload, no?" caveat isn't funny
> either, or duplicate parameter settings scattered throughout your file.
Surely everyone who is opining on this
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Wed, 2008-06-04 at 10:40 -0400, Tom Lane wrote:
>> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Hmm, WAL version compatibility is an interesting question. Most minor
> releases hasn't changed the WAL format, and it would be nice to allow
> runn
On Wed, 2008-06-04 at 10:40 -0400, Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> > Hmm, WAL version compatibility is an interesting question. Most minor
> > releases hasn't changed the WAL format, and it would be nice to allow
> > running different minor versions in the mas
On Wed, Jun 04, 2008 at 10:21:19AM -0400, Tom Lane wrote:
> Ugh :-(.
This is why I didn't want to go that route. :-)
> I have not spent much time looking at the ecpg grammar, so feel free to
> laugh this off, but I had the impression that all the rules derived from
> the backend grammar have boil
Aidan Van Dyk wrote:
* Andreas Pflug <[EMAIL PROTECTED]> [080604 10:20]:
Hiding the storage of config parameters opaquely behind an API is
something I've been hating for a long time on win32.
;-)
When reading this thread, I'm wondering if anybody ever saw a config
file for a comp
Decibel! <[EMAIL PROTECTED]> writes:
> Ok, I'll take a stab at such a list. Can anyone think of any reasons
> why CREATE TRIGGER couldn't get by with ShareLock?
pg_class.reltriggers.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I put fill value on end, because it is like default value:
> array_set(array[2,2]);
> array_set(array[2,2], 0);
Huh? That's completely nonsensical ... where will you determine the
type of the array, if you don't have a sample element?
The fact that
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Hmm, WAL version compatibility is an interesting question. Most minor
> releases hasn't changed the WAL format, and it would be nice to allow
> running different minor versions in the master and slave in those cases.
> But it's certainly not unh
On Wed, Jun 04, 2008 at 09:24:20AM +0200, Markus Schiltknecht wrote:
>
> Are the slides of your PgCon talk available for download somewhere?
There weren't any slides, really (there were 4 that I put up in case
the cases I was discussing needed back-references, but they didn't).
Joshua tells me tha
* Andreas Pflug <[EMAIL PROTECTED]> [080604 10:20]:
> Hiding the storage of config parameters opaquely behind an API is
> something I've been hating for a long time on win32.
;-)
> When reading this thread, I'm wondering if anybody ever saw a config
> file for a complex software product that w
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Tue, May 27, 2008 at 09:44:02AM -0400, Tom Lane wrote:
>> If we were going to do that, I'd want it to go all the way and somehow
>> generate the common parts of the two .y files from a single source.
> Any idea how to make this happen? We could of co
Decibel! wrote:
There's no reason that the server has to deal with a text file. I
completely agree that there must be a method to change settings even if
the database isn't running, but that method does not necessarily need to
be a text file. If we can come up with a standard API for reading and
On Jun 3, 2008, at 5:04 PM, Simon Riggs wrote:
On Tue, 2008-06-03 at 16:48 -0500, Decibel! wrote:
On May 30, 2008, at 9:51 AM, Simon Riggs wrote:
On Thu, 2008-05-29 at 19:18 -0500, Decibel! wrote:
Is there a reason that we can't add a trigger to a table while a
select is running? This is a ser
On Mon, Jun 02, 2008 at 02:06:57PM -0700, Josh Berkus wrote:
> Robert,
>
> > Anyone see any issues with this? Should there be other information taken
> > into account? Does this need to be an option itself, or can we just do
> > it in all cases?
>
> +1 to do it in all cases.
+1. I've definitely
On Mon, Jun 02, 2008 at 10:12:06AM -0400, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > Joshua has been banging a drum for a while now that all this data needs to
> > get pushing into the database itself.
>
> This is, very simply, not going to happen. Shall we go over the reasons
On Tue, May 27, 2008 at 09:44:02AM -0400, Tom Lane wrote:
> If we were going to do that, I'd want it to go all the way and somehow
> generate the common parts of the two .y files from a single source.
> That'd be enough of a step forward that it would be worth whatever
> ugliness is needed to make
On Sat, May 31, 2008 at 08:36:54PM +0100, Gregory Stark wrote:
> > 4) By shifting from a model where postgresql.conf is document-formatted and
> > hand-edited to one where it's machine generated, it becomes vastly easier
> > to
> > write simple utilities to manage these settings. Right now, the
2008/6/4 Decibel! <[EMAIL PROTECTED]>:
> On Jun 2, 2008, at 11:46 AM, Tom Lane wrote:
>>
>> * Should the fill value be the first parameter instead of the last?
>
>
> +1. The other way just seems weird, at least to me.
can you write reason?
I put fill value on end, because it is like default value
On Jun 2, 2008, at 11:46 AM, Tom Lane wrote:
* Should the fill value be the first parameter instead of the last?
+1. The other way just seems weird, at least to me.
--
Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Tea
On Jun 3, 2008, at 9:03 AM, David Fetter wrote:
On Tue, Jun 03, 2008 at 03:36:44PM +0200, Pavel Stehule wrote:
Hello David
http://www.postgresql.org/docs/faqs.TODO.html
Consider using hash buckets to do DISTINCT, rather than sorting This
would be beneficial when there are few distinct values.
On May 29, 2008, at 1:57 AM, Hannu Krosing wrote:
On Wed, 2008-05-28 at 19:11 -0400, Mike wrote:
Can somebody point to the most logical place in the code to intercept
the WAL writes? (just a rough direction would be enough)- or if this
doesn’t make sense at all, another suggestion on where to
dvs wrote:
Hello,
I need to use query like:
select (insert into test (a) values (x) returning b),c from anytable
where condition
but it say
ERROR: syntax error at or near "into"
Is this a bug?
No, it's a known limitation.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprise
Teodor Sigaev wrote:
Is it possible to use catalog version number as WAL version?
No, because we don't change the catalog version number in minor
releases, even though we might change WAL format.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
Csaba Nagy wrote:
On Wed, 2008-06-04 at 11:13 +0300, Heikki Linnakangas wrote:
Hmm, WAL version compatibility is an interesting question. Most minor
releases hasn't changed the WAL format, and it would be nice to allow
running different minor versions in the master and slave in those cases.
Bu
On Wed, 2008-06-04 at 11:13 +0300, Heikki Linnakangas wrote:
> Hmm, WAL version compatibility is an interesting question. Most minor
> releases hasn't changed the WAL format, and it would be nice to allow
> running different minor versions in the master and slave in those cases.
> But it's certa
Hmm, WAL version compatibility is an interesting question. Most minor
releases hasn't changed the WAL format, and it would be nice to allow
As I remember, high minor version should read all WALs from lowers, but it isn't
true for opposite case and between different major versions.
running di
Stephen Denne wrote:
Hannu Krosing wrote:
The simplest form of synchronous wal shipping would not even need
postgresql running on slave, just a small daemon which
reports when wal
blocks are a) received and b) synced to disk.
While that does sound simple, I'd presume that most people would w
Hello Andrew,
Andrew Sullivan wrote:
Yes. And silent as ever. :-)
Are the slides of your PgCon talk available for download somewhere?
BTW: up until recently, there was yet another mailing list:
[EMAIL PROTECTED] It was less focused on hooks
and got at least some traffic. :-) Are those mail
95 matches
Mail list logo
