Joshua D. Drake wrote:
David Fetter wrote:
On Thu, Sep 11, 2008 at 11:28:36PM -0400, Tom Lane wrote:
Joshua Drake [EMAIL PROTECTED] writes:
I think something like:
psql: FATAL: Ident authentication failed for user root
HINT:
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
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 more baldly: this is
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 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-check
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 away tuples
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.
More exotic
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
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 concerned more
Alvaro Herrera wrote:
Jorgen Austvik - Sun Norway wrote:
The attached patch makes pg_regress write converted files to
inputdir/sql and inputdir/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,
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]
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 purpose of
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
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 will always
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
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
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
If we derive
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. Each
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
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 doesn't
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 of both
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
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 than
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
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-is?
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, accessed
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 show
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
block
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 thought
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: R read, W written
Good point. Seems like it should be changed, but I am not sure to what.
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 questions
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 system cache
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 implementation
of
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 point,
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 output dir
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:
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
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 inconsistent answers
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 available
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
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 changed
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 sense.
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 in
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 of 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 make
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 add
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
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
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.
The
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
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 incomplete
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
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
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
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
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 sentence.
Which
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 don't put
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
bootstrap
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?
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
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 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
with
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
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
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
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
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 think you've
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( $1::text
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
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: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 IO
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
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 just
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 a slave
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 of the master.
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
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 output
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
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
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
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
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
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_8601 that will
84 matches
Mail list logo
