On Tue, 2008-10-28 at 22:37 -0300, Alvaro Herrera wrote:
Hannu Krosing wrote:
On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
The two obvious problems with the existing MCP architecture is:
1. Single point of failure
For async replication there is always SPoF, at least
Hello
I am not sure, it's probably bug.
postgres=# create function t1(smallint) returns smallint as $$select
$1$$ language sql;
CREATE FUNCTION
postgres=# create function t2(bigint) returns bigint as $$select $1$$
language sql;
CREATE FUNCTION
postgres=# select t1(10);
ERROR: function
It could be useful to have a command that returns the table definition
(like pg_dump -st) from within the query interface. This could be
particularly useful if one doesn't have access to or prefers not to
manipulate results coming from a shell. If I have an API from which to
query the
On Tue, 2008-10-28 at 14:21 +0200, Heikki Linnakangas wrote:
1. You should avoid useless posix_fadvise() calls. In the naive
implementation, where you simply call posix_fadvise() for every page
referenced in every WAL record, you'll do 1-2 posix_fadvise() syscalls
per WAL record, and
I've updated my patches, these are ready for CommitFest:Nov.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1155.patch
[3/6]
On Wed, 2008-10-29 at 09:55 +0900, Koichi Suzuki wrote:
I'd like to hear some more about these. I'm more than happy to write
all the code inside PG core to avoid overhead to create another
process.
Having an external program can help earlier releases also, so I think
this is the right
On Tue, 2008-10-28 at 22:16 -0700, Joshua D. Drake wrote:
Alvaro Herrera wrote:
Hannu Krosing wrote:
On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
Will there be an helper application for setting up and configuring
changes in replication. or will it all be done using added SQL
Le mardi 28 octobre 2008, Pavel Stehule a écrit :
2008/10/28 Dimitri Fontaine [EMAIL PROTECTED]:
Hi,
In the python language, functions that lazily return collections are
called generators and use the yield keyword instead of return.
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
As far as the ugliness in XLogRecordPageWithFreeSpace goes: couldn't you
just call XLogReadBufferWithFork with init = true, and then initialize
the page if PageIsNew?
With init=true, we don't even try to read the
2008/10/29 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
I am not sure, it's probably bug.
postgres=# create function t1(smallint) returns smallint as $$select
$1$$ language sql;
CREATE FUNCTION
postgres=# select t1(10);
ERROR: function t1(integer) does not exist
Pavel Stehule [EMAIL PROTECTED] writes:
I am not sure, it's probably bug.
postgres=# create function t1(smallint) returns smallint as $$select
$1$$ language sql;
CREATE FUNCTION
postgres=# select t1(10);
ERROR: function t1(integer) does not exist
That's not unknown to smallint, that's
Heikki Linnakangas [EMAIL PROTECTED] writes:
The FSM would be perfectly happy to just initialize torn or otherwise
damaged pages, so I think we should add yet another mode to ReadBuffer()
to allow that. We could also treat read() errors as merely warnings in
that mode, effectively the same
Pavel Stehule [EMAIL PROTECTED] writes:
I understand. So every smallint should be call with casting?
A long time ago we tried to make small integer literals be interpreted
as int2 initially, instead of int4, and the attempt failed rather
spectacularly. (It broke most of the regression tests,
2008/10/29 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
I understand. So every smallint should be call with casting?
A long time ago we tried to make small integer literals be interpreted
as int2 initially, instead of int4, and the attempt failed rather
spectacularly.
So my idea would be to have the SQL function behavior choose to return values
either via tuplestore or via value-per-call, depending on the user
setting generator or lazy.
Done this way, the user could also choose for the function to be lazy or to
use a tuplestore whatever the language in
Buffer ReadBuffer(Relation reln, BlockNumber blockNum);
Buffer ReadBufferExt(Relation reln, ForkNumber forkNum, BlockNumber
blockNum, BufferAccessStrategy strategy, ReadBufferMode mode);
Buffer ReadBufferWithoutRelcache(RelFileNode rnode, bool isTemp, ForkNumber
forkNum, BlockNumber blockNum,
On Wed, Oct 29, 2008 at 12:02:20PM +0200, Hannu Krosing wrote:
A good goal. But why would anybody _need_ 50 slaves ?
They might have a contractual responsibility for extremely wide
geographic distribution. Or they might be building an application
that needs extremely wide network-topological
Dimitri Fontaine [EMAIL PROTECTED] writes:
Done this way, the user could also choose for the function to be lazy or to
use a tuplestore whatever the language in which it's written.
The odds of this ever happening for any of the PLs are not
distinguishable from zero. It might be nice to have,
Le mercredi 29 octobre 2008, Tom Lane a écrit :
So the fact that it's possible for SQL-language functions is an
idiosyncrasy of that language, not something we should cram into the
general CREATE FUNCTION syntax in the vain hope that having syntax
might cause an implementation to appear
Attached is my latest parallel restore patch. I think it's functionally
complete for Unix.
Many bugs have been fixed since the last patch, and the hardcoded
limitation to two table dependencies is removed. It seems fairly robust
in my recent testing.
Remaining to be done:
. code cleanup
Dimitri Fontaine [EMAIL PROTECTED] writes:
Le mercredi 29 octobre 2008, Tom Lane a écrit :
So the fact that it's possible for SQL-language functions is an
idiosyncrasy of that language, not something we should cram into the
general CREATE FUNCTION syntax in the vain hope that having syntax
Le mercredi 29 octobre 2008, Tom Lane a écrit :
Well, call-per-value is *necessary* for lazy evaluation, but it's not
*sufficient*. You need a function implementation that can suspend and
resume execution, and that's difficult in general.
Ok, I think I begin to understand how things are tied
Dimitri Fontaine [EMAIL PROTECTED] writes:
And I fail to see how the user would control which behavior will get chosen,
Oh, I'm sorry, I didn't realize you misunderstood my syntax example.
I was suggesting that the SQL function manager recognize some optional
non-SQL keywords at the start of a
On Wed, 2008-10-29 at 12:02 +0200, Hannu Krosing wrote:
On Tue, 2008-10-28 at 22:16 -0700, Joshua D. Drake wrote:
Alvaro Herrera wrote:
Case in point. To replicate a table currently you do this:
ALTER TABLE foo ENABLE REPLICATION;
ALTER TABLE foo ENABLE REPLICATION ON SLAVE 0;
How
On Wed, 2008-10-29 at 09:54 +0200, Hannu Krosing wrote:
On Tue, 2008-10-28 at 22:37 -0300, Alvaro Herrera wrote:
Hannu Krosing wrote:
On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
it was in subsection mcp_server mysteriously dies
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not sure how best to get it working, but I'd
like to see this as part of 8.4, as SQL/MED is just way too ambitious
given the
Le mercredi 29 octobre 2008, Tom Lane a écrit :
Now of course the bigger problem with either this syntax or yours is
that attaching such a property to a function is arguably the Wrong Thing
in the first place. Which one is the best way is likely to depend on
the calling query more than it
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter [EMAIL PROTECTED] wrote:
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not sure how best to get it working, but I'd
like to see
On Wed, 2008-10-29 at 09:01 -0700, Joshua D. Drake wrote:
On Wed, 2008-10-29 at 12:02 +0200, Hannu Krosing wrote:
On Tue, 2008-10-28 at 22:16 -0700, Joshua D. Drake wrote:
Alvaro Herrera wrote:
Case in point. To replicate a table currently you do this:
ALTER TABLE foo ENABLE
Dimitri Fontaine [EMAIL PROTECTED] writes:
Le mercredi 29 octobre 2008, Tom Lane a écrit :
However, I see no
solution to that problem except function inlining; and if the function
gets inlined then all this discussion is moot anyhow.
How to inline PLs functions?
All of this is
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not sure how best to get it working, but I'd
like to see this as
On Wed, 2008-10-29 at 11:58 -0400, Tom Lane wrote:
Dimitri Fontaine [EMAIL PROTECTED] writes:
And I fail to see how the user would control which behavior will get
chosen,
Oh, I'm sorry, I didn't realize you misunderstood my syntax example.
I was suggesting that the SQL function manager
On Wed, 2008-10-29 at 19:17 +0200, Hannu Krosing wrote:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not
On Wed, 2008-10-29 at 19:15 +0200, Hannu Krosing wrote:
SLAVE 0 is defined by a GUC on the slave, replication_slave_no I think.
( I would have to check the docs)
And the only other GUC slave needs for replication is MCP/Slave connect
info ?
Hi Simon,
He is going to do some investigation in the methods and
write down the possibilities and then he is going to implement
something from that for PostgreSQL.
When will this work be complete? We are days away from completing main
work on 8.4, so you won't get much discussion on
Hi Simon,
He is going to do some investigation in the methods and
write down the possibilities and then he is going to implement
something from that for PostgreSQL.
When will this work be complete? We are days away from completing main
work on 8.4, so you won't get much discussion on this for a
Simon Riggs wrote:
But perhaps writing a single WAL record if you scan whole page and set
all bits at once. Then it makes sense in some cases.
So this is what I ended up doing; attached.
There are some gotchas in this patch:
1. it does not consider hint bits other than the ones defined in
Hello,
I have a table (accounts) with 600,000,000 rows. A heavy high-concurrent
workload that makes mostly updates on this table generates a lot of dead
tuples in its run, which is expected due to MVCC.
The problem is that even though autovacuum is enabled, the autovacuum worker
does not vacuum
I'm posting on hackers because I think that there is a problem in one
of three places, and I'm not sure which:
(1) The documentation needs clarification.
(2) A LOG message needs clarification.
(3) There is a bug in recovery. (unlikely)
This issue was previously posted here with no
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter [EMAIL PROTECTED] wrote:
Also, PL/Perl shouldn't be the only language to have this capability.
How might we add similar capabilities to PL/PythonU and PL/Tcl? To
the rest of the PLs? Would it make any sense to have it in SQL
language functions?
Noah Freire escribió:
please check the first log message: the vacuum threshold is 6,000,050 rows
and the number of dead tuples is 16,697,969. Even though the number of
dead_tuples is greater than the threshold the autovacuum is not being
triggered for this table. So, besides this condition
Alvaro Herrera wrote:
So this is what I ended up doing; attached.
Oh, another thing. The contents for the WAL log message here is very
simplistic; just store all the t_infomask and t_infomask2 relevant bits,
for all the tuples in the table. A possible optimization to reduce the
WAL traffic is
Kenneth Marshall wrote:
On Wed, Oct 22, 2008 at 06:05:26PM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
Minimal really fails to convey the point here IMHO. How about
something like
Noah Freire escribió:
datid | datname | procpid | usesysid | usename | current_query | waiting |
xact_start | query_start | backend_start | client_addr | client_port
Andrew Dunstan wrote:
Kenneth Marshall wrote:
On Wed, Oct 22, 2008 at 06:05:26PM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
Minimal really fails to convey the point here IMHO. How about
Hi Alvaro,
On Wed, Oct 29, 2008 at 3:46 PM, Alvaro Herrera
[EMAIL PROTECTED]wrote:
Noah Freire escribió:
please check the first log message: the vacuum threshold is 6,000,050
rows
and the number of dead tuples is 16,697,969. Even though the number of
dead_tuples is greater than the
Andrew Dunstan escribió:
+ /* make sure it's called as a trigger */
+ if (!CALLED_AS_TRIGGER(fcinfo))
+ elog(ERROR, suppress_redundant_updates_trigger: must be called as
trigger);
Shouldn't these all be ereport()?
--
Alvaro Herrera
Hi,
There is a nice little feature within MSSQL where it is possible to
enumerate all MSSQL servers on the local network.
I wonder how this can be made possible with PG. Pinging every IP:PGPORT
within the current subnet is one of the options but I guess that would be
just a bad solution. Any
Gevik Babakhani wrote:
Hi,
There is a nice little feature within MSSQL where it is possible to
enumerate all MSSQL servers on the local network.
I wonder how this can be made possible with PG. Pinging every IP:PGPORT
within the current subnet is one of the options but I guess that would be
Alvaro Herrera wrote:
Andrew Dunstan escribió:
+ /* make sure it's called as a trigger */
+ if (!CALLED_AS_TRIGGER(fcinfo))
+ elog(ERROR, suppress_redundant_updates_trigger: must be called as
trigger);
Shouldn't these all be ereport()?
Good point.
I'll fix
Gevik Babakhani wrote:
Hi,
There is a nice little feature within MSSQL where it is possible to
enumerate all MSSQL servers on the local network.
I wonder how this can be made possible with PG. Pinging every IP:PGPORT
within the current subnet is one of the options but I guess that would be
Alvaro Herrera wrote:
There are some gotchas in this patch:
1. it does not consider hint bits other than the ones defined in htup.h.
Some index AMs use hint bits to kill tuples (LP_DEAD mostly, I think).
This means that CRCs will be broken for such pages when pages are torn.
The other hint
If I am not mistaken, it only works fine on OSX environments. (I might be
very wrong here)
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2008 8:47 PM
To: Gevik Babakhani
Cc: 'PGSQL Hackers'
Subject: Re: [HACKERS] PostgreSQL network
I asked this question because I have a situation where a service like this
would be very useful. If such a functionality would be accepted by the core
team, I am willing to work on it.
-Original Message-
From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2008
On Wed, Oct 29, 2008 at 03:48:09PM -0400, Andrew Dunstan wrote:
+ /* make sure it's called as a trigger */
+ if (!CALLED_AS_TRIGGER(fcinfo))
+ elog(ERROR, suppress_redundant_updates_trigger: must be called
as trigger);
Shouldn't these all be ereport()?
Good point.
I'll
David Fetter wrote:
Maybe we should fix our C sample trigger, from which this was taken.
Yes :)
Does the attached have the right error code?
-elog(ERROR, trigf: not called by trigger manager);
+ereport(ERROR,
+(error(TRIGGERED_DATA_CHANGE_VIOLATION),
+
On Wed, 2008-10-29 at 17:42 +0900, KaiGai Kohei wrote:
I've updated my patches, these are ready for CommitFest:Nov.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1155.patch
Andrew Dunstan wrote:
David Fetter wrote:
Maybe we should fix our C sample trigger, from which this was taken.
Yes :)
Does the attached have the right error code?
-elog(ERROR, trigf: not called by trigger manager);
+ereport(ERROR,
+
Gevik Babakhani [EMAIL PROTECTED] writes:
I asked this question because I have a situation where a service like this
would be very useful. If such a functionality would be accepted by the core
team, I am willing to work on it.
The existing code uses APIs that Apple has deprecated, so it's
Alvaro Herrera wrote:
3. the bgwriter is seen writing WAL entries at checkpoint. At shutdown,
this might cause an error to be reported on how there was not supposed
to be activity on the log. I didn't save the exact error report and I
can't find it in the source :-(
LOG: received fast
On Tue, 2008-10-28 at 23:45 -0400, Robert Haas wrote:
One concern that I have about this approach is that the situation in
which people are probably most concerned about COPY performance is
restoring a dump. In that case, the COPY will be the only thing
running, and using a
On Wed, 2008-10-29 at 10:33 -0700, Joshua D. Drake wrote:
On Wed, 2008-10-29 at 19:17 +0200, Hannu Krosing wrote:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in
Patch submitters,
Please make sure your patches are on the November CommitFest wiki page, with
correct and updated links.
http://wiki.postgresql.org/wiki/CommitFest_2008-11
--
Josh Berkus
PostgreSQL
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
All of this is pie-in-the-sky for PL functions, and I think properly so:
the whole reason for supporting PLs is to enable doing things that SQL
does poorly or not at all. So expecting SQL to interoperate very
closely with them seems impossible, or at least unreasonably limiting.
The real
I'm not sure if blocks reffered from all WAL records in single WAL
segment can fit kernel cache. This is why current pg_readahead
returns the last LSN and require starting LSN. So far, with FPW, it
seems that we can prefetch all the pages in a WAL segment. So it
will be okay for archive log
Hi,
2008/10/29 Simon Riggs [EMAIL PROTECTED]:
On Tue, 2008-10-28 at 14:21 +0200, Heikki Linnakangas wrote:
1. You should avoid useless posix_fadvise() calls. In the naive
implementation, where you simply call posix_fadvise() for every page
referenced in every WAL record, you'll do 1-2
On Thu, 2008-10-30 at 09:46 +0900, Koichi Suzuki wrote:
I'm not sure if blocks reffered from all WAL records in single WAL
segment can fit kernel cache. This is why current pg_readahead
returns the last LSN and require starting LSN. So far, with FPW, it
seems that we can prefetch all the
If you say its a loss you should publish timings to support that. Using
a BAS for VACUUM was a performance gain, not a loss.
Well, I can dig up and publish the timings from my laptop, but I'm not
sure where that will get us. Trust me, the numbers were higher with
BAS, otherwise I wouldn't be
I wonder if we should consider:
(1) moving all of the patches committed prior to 11/1 to a separate
section or page
(2) sorting the pending patches by complexity or subject matter
...Robert
On Wed, Oct 29, 2008 at 5:26 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Patch submitters,
Please make
On Wed, 2008-10-29 at 21:58 -0400, Robert Haas wrote:
If you say its a loss you should publish timings to support that. Using
a BAS for VACUUM was a performance gain, not a loss.
Well, I can dig up and publish the timings from my laptop, but I'm not
sure where that will get us. Trust me,
Hannu Krosing [EMAIL PROTECTED] writes:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Also, PL/Perl shouldn't be the only language to have this capability.
How might we add similar capabilities to PL/PythonU
I'll look at adding this to pl/pythonu.
I would argue that it's already
Robert,
(1) moving all of the patches committed prior to 11/1 to a separate
section or page
Why?
(2) sorting the pending patches by complexity or subject matter
Sorting them by complexity would be great, if I thought I could do it. I'm
not sure I can.
--
Josh Berkus
PostgreSQL
San
Andrew Dunstan [EMAIL PROTECTED] writes:
Not sure that's appropriate, but I can't see anything else that is
very appropriate either.
The plpgsql code uses errcode(ERRCODE_FEATURE_NOT_SUPPORTED) for this
situation, so I guess we should be consistent with that.
Simon Riggs wrote:
On Wed, 2008-10-29 at 17:42 +0900, KaiGai Kohei wrote:
I've updated my patches, these are ready for CommitFest:Nov.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
[2/6]
Josh Berkus [EMAIL PROTECTED] writes:
(2) sorting the pending patches by complexity or subject matter
Sorting them by complexity would be great, if I thought I could do it. I'm
not sure I can.
We organized them by subject matter (or code area, really) in a couple
of the earlier fests. I
Andrew Dunstan [EMAIL PROTECTED] writes:
I think I like this best of all the suggestions -
suppress_redundant_updates_trigger() is what I have now.
If there's no further discussion, I'll go ahead and commit this in a day
or two.
The documentation seems a bit lacking: it gives neither a
David Blewett [EMAIL PROTECTED] writes:
Here's a vote for allowing this in plain SQL.
I use the tablefunc contrib module as a way to build a view of a
specific questionnaire's responses (using Elein's nice model here
[1]). Currently, if I then write queries against these views that
include
On Wednesday 29 October 2008 20:12, Tom Lane wrote:
Earlier today I had a different thought about how to sort things early
in the fest. I think that there is a strong temptation to finish off
the simple patches quickly so as to reduce the size of the list ---
I know I've done that and I think
Kevin Grittner [EMAIL PROTECTED] writes:
Regarding the LOG message, it is confusing to have a recovery.conf
file which contains this:
recovery_target_time = '2008-10-16 17:00:00.0'
and see this in the log:
[2008-10-16 23:04:26.006 CDT] 19951 LOG: last completed transaction
was at log time
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Also, PL/Perl shouldn't be the only language to have this
capability. How might we add similar capabilities to PL/PythonU
I'll look
2008/10/30 Robert Haas [EMAIL PROTECTED]:
All of this is pie-in-the-sky for PL functions, and I think properly so:
the whole reason for supporting PLs is to enable doing things that SQL
does poorly or not at all. So expecting SQL to interoperate very
closely with them seems impossible, or at
81 matches
Mail list logo
