On Sep 5, 2008, at 9:06 AM, D'Arcy J.M. Cain wrote:
...etc. Would it be OK if I went in and added .cvsignore files to
keep
the noise level down? I guess I could have my daily script filter
them
out but there may be times when there really is an unexpected file and
I want to follow up on it.
On Sep 5, 2008, at 9:43 PM, Bruce Momjian wrote:
Fortunately there's an easy fix for that. If we optimize
RecordAndGetPageWithFreeSpace so that it will always return the next
page if it has enough space, we'll be doing sequential I/O again.
That's
trivial as long as the next heap page is on th
Ron Mayer <[EMAIL PROTECTED]> writes:
> Cool. I think I have it pretty much working with a new
> GUC "intervalstyle" that can take values of
> "sql_standard" that I think will output SQL standard
> interval literals when given a sql
> standard interval.
> "iso_860
It's been three months since our last release set, and in view of the
recent discovery of a potential-data-loss issue in 8.3, it seems that
we should get moving on another one. Accordingly, core has decided that
we will freeze a set of update releases next Thursday (9/18) for public
announcement M
Tom Lane wrote:
I think all
you need is 'yyy-mm dd hh:mm:ss' where you omit yyy-mm if
zeroes, omit dd if zero, omit hh:mm:ss if zeroes (but maybe
only if dd is also 0? otherwise your output is just dd which
is uncomfortably ambiguous).
Cool. I think I have it pretty much working with a new
GU
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> I was intending to do it the other way, actually. An extra field in
> HashPath hardly costs anything. The other reason for it is that there
> are other possible uses for knowing whether a hash will be
multi-batch.
> (For example, if we were prepared to
Ron Mayer wrote:
Tom Lane wrote:
you need is 'yyy-mm dd hh:mm:ss' where you omit yyy-mm if
zeroes, omit dd if zero, omit hh:mm:ss if zeroes (but maybe
only if dd is also 0? otherwise your output is just dd which
is uncomfortably ambiguous).
Oh, and if both parts are 0, I guess we desire
the (
Tom Lane wrote:
The reason it's not SQL-standard is the data value isn't.
So not a problem. Someone conforming to the spec limits on
what he puts in will see spec-compliant output. I think all
you need is 'yyy-mm dd hh:mm:ss' where you omit yyy-mm if
zeroes, omit dd if zero, omit hh:mm:ss if ze
Ron Mayer <[EMAIL PROTECTED]> writes:
> Trying to do the SQL-standard output now, and have a question
> of what to do in the SQL-standard mode when trying to output
> an interval that as both a YEAR and a DAY component.
> AFAICT the SQL standard doesn't let you have both, so the
> "SQL-standard" o
Tom Lane wrote:
somewhat SQL-compliant on interval input, a GUC that selected
PG traditional, SQL-standard, or ISO 8601 interval output format seems
like it could be a good idea.
Trying to do the SQL-standard output now, and have a question
of what to do in the SQL-standard mode when trying to
Hannu Krosing escribió:
> On Fri, 2008-09-12 at 17:45 +0100, Simon Riggs wrote:
> > On Fri, 2008-09-12 at 17:11 +0200, Csaba Nagy wrote:
> >
> > > Why not have a design where the slave is in control for it's own data ?
> > > I mean the slave...
> >
> > The slave only exists because it is a copy o
On Fri, 2008-09-12 at 17:45 +0100, Simon Riggs wrote:
> On Fri, 2008-09-12 at 17:11 +0200, Csaba Nagy wrote:
>
> > Why not have a design where the slave is in control for it's own data ?
> > I mean the slave...
>
> The slave only exists because it is a copy of the master. If you try to
> "startup
David E. Wheeler escribió:
> On Sep 12, 2008, at 11:35, David E. Wheeler wrote:
>
>> I've got another patch I'm working on adding support for "char" (and
>> tests for char). Just to fill out a gap I saw in the casting coverage.
>> I'm trying to get it done now. With that, AFAIK, citext will work
Tom Lane wrote:
Ron Mayer <[EMAIL PROTECTED]> writes:
... ISO 8601 intervals ...
On the output side, seems like a GUC variable
is the standard precedent here. I'd still vote against overloading
DateStyle --- it does too much already --- but a separate variable for
interval style wouldn't both
On Sep 12, 2008, at 11:35, David E. Wheeler wrote:
I've got another patch I'm working on adding support for "char" (and
tests for char). Just to fill out a gap I saw in the casting
coverage. I'm trying to get it done now. With that, AFAIK, citext
will work just like text.
Looks like the I
On Sep 12, 2008, at 11:34, Tom Lane wrote:
CREATE OR REPLACE FUNCTION int8(citext)
RETURNS int8
AS 'SELECT int8( $1::text )'
LANGUAGE SQL IMMUTABLE STRICT;
Yeah, those are all replaced by the CoerceViaIO mechanism
Okay, thanks for the sanity check. The SQL versions are fine for me in
8.3.
On Sep 12, 2008, at 11:31, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
Oh, and text_name seems to give me this error:
ERROR: compressed data is corrupt
That's when I have this cast:
CREATE OR REPLACE FUNCTION citext(name)
RETURNS citext
AS 'text_name'
LANGUAGE
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Pity. Looks like there were only a few I wasn't using, text_char,
> char_text, text_name, and texttoxml. Do I really need to keep all my
> other casts like these in 8.3?
> CREATE OR REPLACE FUNCTION int8(citext)
> RETURNS int8
> AS 'SELECT int8(
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Oh, and text_name seems to give me this error:
> ERROR: compressed data is corrupt
> That's when I have this cast:
> CREATE OR REPLACE FUNCTION citext(name)
> RETURNS citext
> AS 'text_name'
> LANGUAGE internal IMMUTABLE STRICT;
I thin
On Sep 12, 2008, at 11:14, David E. Wheeler wrote:
Pity. Looks like there were only a few I wasn't using, text_char,
char_text, text_name, and texttoxml.
Oh, and text_name seems to give me this error:
ERROR: compressed data is corrupt
That's when I have this cast:
CREATE OR REPLACE FUNC
On Sep 12, 2008, at 11:06, David E. Wheeler wrote:
Er, look into pg_cast and then pg_proc? For instance
select oid::regprocedure, prosrc from pg_proc
where oid in (select castfunc from pg_cast);
That looks like *exactly* what I need. Thanks!
Pity. Looks like there were only a few I wasn't
On Sep 12, 2008, at 10:58, Tom Lane wrote:
1. Did I neglect to include the documentation patch? I've attached it
here. It's necessary because of the addition of the new functions.
Maybe it got left out of the later patch iterations? Anyway,
will take care of it.
Great, thank you.
2. Many
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> 1. Did I neglect to include the documentation patch? I've attached it
> here. It's necessary because of the addition of the new functions.
Maybe it got left out of the later patch iterations? Anyway,
will take care of it.
> 2. Many thanks for sw
On Fri, Sep 12, 2008 at 01:14:36PM -0400, Alvaro Herrera wrote:
> Marko Kreen escribió:
> > Currently dblink allows regular users to initiate libpq connection
> > to user-provided connection string. This breaks the default
> > policy that normal users should not be allowed to freely interact
> > w
Marko Kreen escribió:
> Currently dblink allows regular users to initiate libpq connection
> to user-provided connection string. This breaks the default
> policy that normal users should not be allowed to freely interact
> with outside environment.
Since people is now working on implementing the
On Sep 5, 2008, at 11:33, David E. Wheeler wrote:
On Sep 5, 2008, at 11:30, Tom Lane wrote:
Thanks for reviewing. I've committed this with your suggestions and
one additional non-cosmetic change: schema-qualify names in the
bodies of the SQL functions so that they are not search_path
depend
David Fetter wrote:
On Fri, Sep 12, 2008 at 12:30:12PM -0400, Alvaro Herrera wrote:
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
The only thing I would say here is that you point the URL to
current which will be wrong in one release. Perhaps something
that pulls the pgversion macro?
We
On Fri, 2008-09-12 at 17:11 +0200, Csaba Nagy wrote:
> Why not have a design where the slave is in control for it's own data ?
> I mean the slave...
The slave only exists because it is a copy of the master. If you try to
"startup" a slave without first having taken a copy, how would you
bootstra
On Fri, Sep 12, 2008 at 12:30:12PM -0400, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> > Heikki Linnakangas wrote:
> >
> >>> The only thing I would say here is that you point the URL to
> >>> current which will be wrong in one release. Perhaps something
> >>> that pulls the pgversion macro?
>
Joshua D. Drake wrote:
> Heikki Linnakangas wrote:
>
>>> The only thing I would say here is that you point the URL to current
>>> which will be wrong in one release. Perhaps something that pulls the
>>> pgversion macro?
>>
>> We don't put URLs in error messages. The hint needs to be a real sent
Heikki Linnakangas wrote:
The only thing I would say here is that you point the URL to current
which will be wrong in one release. Perhaps something that pulls the
pgversion macro?
We don't put URLs in error messages. The hint needs to be a real sentence.
Which is exactly why its the first
Hi,
Andrew Dunstan wrote:
If this were a nice pluggable library I'd agree, but AFAIK it's not, and
I don't see great value in reinventing the wheel.
I certainly agree.
However, I thought of it more like the archive_command, as proposed by
Hannu. That way we don't need to reinvent any wheel a
Csaba Nagy wrote:
Why not have a design where the slave is in control for it's own data ?
I mean the slave could ask for the base files (possibly through a
special function deployed on the master), then ask for the WAL stream
and so on. That would easily let a slave cascade too, as it could relay
Heikki Linnakangas wrote:
Simon Riggs wrote:
Built-in? Why? I mean make base backup using rsync. That way only
changed data blocks need be migrated, so much faster.
Yes, what I meant is that it would be cool to have that functionality
built-in, so that you wouldn't need to configure extra r
Peter Eisentraut wrote:
> Alvaro Herrera wrote:
>> However I wonder how much value there really is in the developer's FAQ,
>> considering that some answers seem rather poor. For example the
>> answer on ereport() was wrong, and nobody ever pointed it out. The
>> answer on palloc/pfree is very inc
Simon Riggs wrote:
Built-in? Why? I mean make base backup using rsync. That way only
changed data blocks need be migrated, so much faster.
Yes, what I meant is that it would be cool to have that functionality
built-in, so that you wouldn't need to configure extra rsync scripts and
authenticat
On Fri, Sep 12, 2008 at 10:29:54AM +0300, Peter Eisentraut wrote:
> Alvaro Herrera wrote:
>> However I wonder how much value there really is in the developer's
>> FAQ, considering that some answers seem rather poor. For example
>> the answer on ereport() was wrong, and nobody ever pointed it out.
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Let me describe this test case first:
- The test program calls RecordAndGetPageWithFreeSpace in a tight loop,
with random values.
What's the distribution of the random values, exactly? In particular,
how do the request sizes comp
Zdenek Kotala wrote:
It looks likes that there are lot of lock issues on FSM pages. When
number of FSM pages is increased then number of collisions is lower. It
is probably why 2 clients significantly speed up between 33MB and 333MB.
Yes, that's what I thought as well. With table size under 3
On Fri, 2008-09-12 at 17:24 +0300, Hannu Krosing wrote:
> On Fri, 2008-09-12 at 17:08 +0300, Heikki Linnakangas wrote:
> > Hmm, built-in rsync capability would be cool. Probably not in the first
> > phase, though..
>
> We have it for WAL shipping, in form of GUC "archive_command" :)
>
> Why not
On Fri, 2008-09-12 at 17:08 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> I think we'll need an option to specify a maximum for the number of WAL
> files to keep around. The DBA should set that to the size of the WAL
> drive, minus some safety factor.
>
> > It should be clear that to
On Fri, 2008-09-12 at 15:08 +0300, Hannu Krosing wrote:
> On Fri, 2008-09-12 at 13:54 +0200, Csaba Nagy wrote:
> > > I think that enabling long-running queries this way is both
> > > low-hanging
> > > fruit (or at least medium-height-hanging ;) ) and also consistent to
> > > PostgreSQL philosophy
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I think the appropriate interface would be adding another option to
> > pg_regress called --workdir or --tempdir, which defaults to PWD, and
> > write the converted sql files there, and then look for the sql files to
> > execute
On Fri, 12 Sep 2008 06:53:55 +1000
"Brendan Jurd" <[EMAIL PROTECTED]> wrote:
> Josh has assigned your patch to me for an initial review.
And me.
> First up I'd like to say that this is a really nice upgrade.
> Shielding a running server from reloading a bogus conf file makes a
> whole lot of sens
On Fri, 2008-09-12 at 17:08 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
>
> > It should be clear that to make this work you must run with a base
> > backup that was derived correctly on the current master. You can do that
> > by re-copying everything, or you can do that by just shipping
Simon Riggs wrote:
If we were going to recover from failed-over standby back to original
master just via WAL logs we would need all of the WAL files from the
point of failover. So you'd need to be storing all WAL file just in case
the old master recovers. I can't believe doing that would be the c
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Let me describe this test case first:
> - The test program calls RecordAndGetPageWithFreeSpace in a tight loop,
> with random values.
What's the distribution of the random values, exactly? In particular,
how do the request sizes compare to availab
On Fri, Sep 12, 2008 at 08:53:39AM +0100, Gregory Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Joshua Drake <[EMAIL PROTECTED]> writes:
> >> I think something like:
> >
> >> psql: FATAL: Ident authentication failed for user "root"
> >> HINT: http://www.postgresql.org/docs/8.3/stat
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> I tried to run the test from another directory with this patch
>> installed, and found that it didn't work because it's replacing
>> @abs_builddir@ in the input files improperly (to the current path; it
>> should be using the o
On Fri, Sep 12, 2008 at 10:08:56AM +0200, Markus Schiltknecht wrote:
> Hi,
>
> David Fetter wrote:
>> I'm all for something, and that's a much better something. What we
>> have now--nothing--actively distresses newbies for no good reason.
>>
>> I don't know how many people we've lost right at that
On Fri, 2008-09-12 at 15:08 +0300, Hannu Krosing wrote:
> > * how will the buffers keep 2 different versions of the same page ?
>
> As the FS snapshot is mounted as a different directory, it will have
> it's own buffer pages.
Lack of knowledge about this shows my ignorance about the implementatio
Heikki Linnakangas napsal(a):
Heikki Linnakangas wrote:
I've also been working on a low level benchmark using a C user-defined
function that exercises just the FSM, showing the very raw CPU
performance vs. current implementation. More on that later, but ATM it
looks like the new implementation
On Fri, 2008-09-12 at 13:54 +0200, Csaba Nagy wrote:
> > I think that enabling long-running queries this way is both
> > low-hanging
> > fruit (or at least medium-height-hanging ;) ) and also consistent to
> > PostgreSQL philosophy of not replication effort. As an example we trust
> > OS's file sys
On Fri, 2008-09-12 at 12:25 +0100, Gregory Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > 3. Ignore problem
> > Effects:
> > * Long running queries on standby...
> >Have no effect on primary
> >Do not delay apply of WAL records on standby
> > * Queries on standby give incons
> I think that enabling long-running queries this way is both
> low-hanging
> fruit (or at least medium-height-hanging ;) ) and also consistent to
> PostgreSQL philosophy of not replication effort. As an example we trust
> OS's file system cache and don't try to write our own.
I have again questio
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> BTW, we have the word 'Direct' in ShowBufferUsage().
> Can I keep it as-is?
> ShowBufferUsage()
> ! Shared blocks: ...
> ! Local blocks: ...
> ! Direct blocks: read, written
Good point. Seems like it should be changed, but I am not sure to
On Fri, 2008-09-12 at 12:31 +0100, Richard Huxton wrote:
> There was a suggestion (Simon - from you?) of a transaction voluntarily
> restricting itself to a set of tables.
While thinking about how easy it would be for the DBA to specify the set
of tables a single query is accessing, first I though
On Fri, 2008-09-12 at 12:31 +0300, Hannu Krosing wrote:
> On Fri, 2008-09-12 at 09:45 +0100, Simon Riggs wrote:
> > On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote:
> > > Gregory Stark wrote:
> > > > b) vacuum on the server which cleans up a tuple the slave has in scope
> > > > has to
Gregory Stark wrote:
> In that case the problem is dealing with different usage patterns on different
> tables. There might be a way to solve just that use case such as deferring WAL
> records for those tables. That doesn't guarantee inter-table data consistency
> if there were other queries which
Simon Riggs <[EMAIL PROTECTED]> writes:
> 3. Ignore problem
> Effects:
> * Long running queries on standby...
>Have no effect on primary
>Do not delay apply of WAL records on standby
> * Queries on standby give inconsistent answers in some cases, though
> doesn't generate any messages to s
On Fri, 2008-09-12 at 13:53 +0300, Hannu Krosing wrote:
> 4. Slave keeps copies of removed pages or rows when WAL apply removes
> old versions .
>
> Possible ways to do this
>
> * inside Slave - have some backup store tied to OldestXmin intervals
>
> * variant 1 - have one global store, acce
On Fri, 2008-09-12 at 00:03 +0900, Fujii Masao wrote:
> In my procedure, old WAL files are copyed by admin using scp, rsync
> or other external tool. So, I don't think that my procedure makes a
> problem more difficult. Since there are many setup cases, we should
> not leave all procedures to pos
On Fri, 2008-09-12 at 11:19 +0100, Simon Riggs wrote:
> On Thu, 2008-09-11 at 01:07 +0100, Simon Riggs wrote:
> > Transaction snapshots is probably the most difficult problem for Hot
> > Standby to resolve.
>
> In summary of thread so far:
>
> When queries on standby run for significantly longer
On Thu, 2008-09-11 at 12:18 +0100, Gregory Stark wrote:
> Is there any middle ground or brilliant ways to get the best of both worlds?
Possibly. Nobody has commented yet on the other ideas on the post
itself.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Supp
On Thu, 2008-09-11 at 18:17 +0300, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > I think that this case would often happen. So, we should establish a certain
> > solution or procedure to the case where TLI of the master doesn't match
> > TLI of the slave. If we only allow the case where TLI o
Tom Lane <[EMAIL PROTECTED]> wrote:
> * Let's rename them BufFileReadCount and BufFileWriteCount to reflect
> their actual purpose.
It looks good. No one uses NDirectFileRead/Write variables now,
so we can rename it freely.
BTW, we have the word 'Direct' in ShowBufferUsage().
Can I keep it as-i
On Thu, 2008-09-11 at 01:07 +0100, Simon Riggs wrote:
> Transaction snapshots is probably the most difficult problem for Hot
> Standby to resolve.
In summary of thread so far:
When queries on standby run for significantly longer than longest
queries on primary, some problems can occur. Various
On Thu, 2008-09-11 at 17:04 +0300, Heikki Linnakangas wrote:
> Csaba Nagy wrote:
> > and that means in fact that if you have
> > continuously overlapping small transactions, the "blocking horizon"
> > could be even blocked forever, as there'll always be a query running,
> > and the new queries wil
On Thu, 2008-09-11 at 15:17 +0200, Jochem van Dieten wrote:
> On Thu, Sep 11, 2008 at 2:07 AM, Simon Riggs wrote:
> > Transaction snapshots is probably the most difficult problem for Hot
> > Standby to resolve.
>
> > * remotely from primary node
> > * locally on the standby node
> >
> >
Josh Berkus wrote:
Hackers,
At this point, almost all patches have been assigned to reviewers. If
you submitted a patch and don't get feedback by Saturday, take a look at
who's in the "reviewers" column and send them a query. Since I have no
way to track when patches are assigned to reviewe
Heikki Linnakangas wrote:
I've also been working on a low level benchmark using a C user-defined
function that exercises just the FSM, showing the very raw CPU
performance vs. current implementation. More on that later, but ATM it
looks like the new implementation can be faster or slower than t
On Fri, 2008-09-12 at 09:45 +0100, Simon Riggs wrote:
> On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote:
> > Gregory Stark wrote:
> > > b) vacuum on the server which cleans up a tuple the slave has in scope
> > > has to
> > >block WAL reply on the slave (which I suppose defeats the
On Fri, 2008-09-12 at 11:21 +0200, Csaba Nagy wrote:
> On Fri, 2008-09-12 at 09:38 +0100, Simon Riggs wrote:
> > If you request a block, we check to see whether there is a lookaside
> > copy of it prior to the tuple removals. We then redirect the block
> > request to a viewpoint relation's block. E
Brendan Jurd wrote:
> Hi Magnus,
>
> Josh has assigned your patch to me for an initial review.
>
> First up I'd like to say that this is a really nice upgrade.
> Shielding a running server from reloading a bogus conf file makes a
> whole lot of sense.
Hi!
Thanks for your review.
> The patch do
Hello,
The latest SE-PostgreSQL patches are updated here:
[1/4]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1005.patch
[2/4]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1005.patch
[3/4]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8
On Fri, 2008-09-12 at 09:38 +0100, Simon Riggs wrote:
> If you request a block, we check to see whether there is a lookaside
> copy of it prior to the tuple removals. We then redirect the block
> request to a viewpoint relation's block. Each viewpoint gets a separate
> relfilenode. We do the switch
Alvaro Herrera wrote:
Jorgen Austvik - Sun Norway wrote:
The attached patch makes pg_regress write converted files to
/sql and /expected, which is one way to make it read
and write to the same directory. Tested on Solaris x86 with pgsql "make
check" and standalone.
Okay, so this patch do
On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote:
> Gregory Stark wrote:
> > b) vacuum on the server which cleans up a tuple the slave has in scope has
> > to
> >block WAL reply on the slave (which I suppose defeats the purpose of
> > having
> >a live standby for users concern
Tom Lane wrote:
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
At 2008-09-02 15:10:23 +0300, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] sgml]$ make man
As Alvaro noted recently, you need to use "make man D2MDIR=/some/path".
I see it's been like that for quite some time, but still it seems p
On Thu, 2008-09-11 at 11:38 +0300, Hannu Krosing wrote:
> On Thu, 2008-09-11 at 09:24 +0300, Heikki Linnakangas wrote:
>
> > I like the idea of acquiring snapshots locally in the slave much more.
> > As you mentioned, the options there are to defer applying WAL, or cancel
> > queries.
>
> Mor
On Thu, 2008-09-11 at 17:58 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > So part of the handshake between
> > primary and standby must be "what is your recentxmin?". The primary will
> > then use the lower/earliest of the two.
>
> Even then, the master might already have vacuumed awa
Tom Lane wrote:
> I wrote:
>> Are people satisfied that the Windows part of the patch is okay?
>
> I went ahead and applied this patch after some trivial stylistic fixes.
> The buildfarm will soon tell us if the WIN32 part of the patch compiles,
> but not whether it works --- would someone double-
Hi,
David Fetter wrote:
I'm all for something, and that's a much better something. What we
have now--nothing--actively distresses newbies for no good reason.
I don't know how many people we've lost right at that point, but the
number has to be high, as most people don't just hop into IRC with
Tom Lane <[EMAIL PROTECTED]> writes:
> Joshua Drake <[EMAIL PROTECTED]> writes:
>> I think something like:
>
>> psql: FATAL: Ident authentication failed for user "root"
>> HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
>
>> Would be nice.
...
>
> Or to put it even mor
Alvaro Herrera wrote:
However I wonder how much value there really is in the developer's FAQ,
considering that some answers seem rather poor. For example the
answer on ereport() was wrong, and nobody ever pointed it out. The
answer on palloc/pfree is very incomplete too.
I think the developer
85 matches
Mail list logo
