Hi!
I was looking into the postgres error handling mechanism, and the
documentation states that the present mechanism is primitive.
I quote whenever the parser, planner/optimizer or executor decide that a
statement cannot be processed any longer,
the whole transaction gets aborted and the system
Hello
This patch remove redundant rows from PL/pgSQL executor (-89 lines).
Doesn't change a functionality.
Regards
Pavel Stehule
*** ./src/pl/plpgsql/src/pl_exec.c.orig 2010-12-16 10:25:37.0 +0100
--- ./src/pl/plpgsql/src/pl_exec.c 2010-12-17 10:50:31.793623763 +0100
***
***
Firebird
http://mapopa.blogspot.com/2010/10/clang-compiling-successful-experiments.html
Regards
Alexandre Riveira
Tom Lane escreveu:
Gevik Babakhani pg...@xs4all.nl writes:
I was wondering if there has been anyone experimenting to compile PG
using LLVM/clang compiler tools.
There
On 17/12/2010 3:46 PM, Magnus Hagander wrote:
On Dec 17, 2010 8:02 AM, Craig Ringer cr...@postnewspapers.com.au
mailto:cr...@postnewspapers.com.au wrote:
On 16/12/10 21:01, Magnus Hagander wrote:
Found another problem in it: when running with an older version of
dbghelp.dll (which I
On Fri, Dec 17, 2010 at 12:08, Craig Ringer cr...@postnewspapers.com.au wrote:
On 17/12/2010 3:46 PM, Magnus Hagander wrote:
On Dec 17, 2010 8:02 AM, Craig Ringer cr...@postnewspapers.com.au
mailto:cr...@postnewspapers.com.au wrote:
On 16/12/10 21:01, Magnus Hagander wrote:
Found
The limit on max_standby_streaming_delay is currently 35 minutes
(around) - or you have to set it to unlimited. This is because the GUC
is limited to MAX_INT/1000, unit milliseconds.
Is there a reason for the /1000, or is it just an oversight thinking
the unit was in seconds?
If we can get rid
Magnus Hagander wrote:
The limit on max_standby_streaming_delay is currently 35 minutes
(around) - or you have to set it to unlimited. This is because the GUC
is limited to MAX_INT/1000, unit milliseconds.
Is there a reason for the /1000, or is it just an oversight thinking
the unit was in
On Tue, Dec 14, 2010 at 10:54 PM, Fujii Masao masao.fu...@gmail.com wrote:
I found a bug which always prevents SignalSomeChildren with
BACKEND_TYPE_WALSND from sending a signal to walsender.
Though currently SignalSomeChildren with BACKEND_TYPE_WALSND
has not been called anywhere, it's not
On Sun, Dec 12, 2010 at 10:06 PM, Fujii Masao masao.fu...@gmail.com wrote:
But if it annoys you, it seems OK to change it. Don't see a reason to
backpatch though?
I think that It's worth backpatch to prevent users who observe the
occurrence of the query conflicts carefully for testing 9.0
Excerpts from Robert Haas's message of vie dic 17 10:08:04 -0300 2010:
On Tue, Dec 14, 2010 at 10:54 PM, Fujii Masao masao.fu...@gmail.com wrote:
I found a bug which always prevents SignalSomeChildren with
BACKEND_TYPE_WALSND from sending a signal to walsender.
Though currently
On 17.12.2010 11:18, fanng yuan wrote:
Hi!
I was looking into the postgres error handling mechanism, and the
documentation states that the present mechanism is primitive.
I quote whenever the parser, planner/optimizer or executor decide that a
statement cannot be processed any longer,
the whole
On 12/17/2010 04:50 AM, Alexandre Riveira wrote:
Firebird
http://mapopa.blogspot.com/2010/10/clang-compiling-successful-experiments.html
In addition to top-posting this has nothing to do with the original
question, and is seriously off-topic for a Postgres developers mailing list.
Pavel Stehule pavel.steh...@gmail.com writes:
This patch remove redundant rows from PL/pgSQL executor (-89 lines).
Doesn't change a functionality.
I'm not really impressed with this idea: there's no a priori reason
that all those loop types would necessarily have exactly the same
control logic.
I noticed that the fastpath code doesn't update ps_status, which would
be harmless except that it leads to idle in transaction being logged
in log_line_prefix for the command tag.
Are there objections to applying this?
--
Álvaro Herrera alvhe...@alvh.no-ip.org
fastpath-ps.patch
Description:
Excerpts from Pavel Stehule's message of vie dic 17 07:02:00 -0300 2010:
Hello
This patch remove redundant rows from PL/pgSQL executor (-89 lines).
Doesn't change a functionality.
Hmm I'm not sure but I think the new code has some of the result values
inverted. Did you test this thoroughly?
Magnus Hagander mag...@hagander.net writes:
On Fri, Dec 17, 2010 at 12:08, Craig Ringer cr...@postnewspapers.com.au
wrote:
That might be a safer starting point than including the private process
memory, really.
I'm not too happy with having a bunch of switches for it. People
likely to
Greg Smith g...@2ndquadrant.com writes:
Magnus Hagander wrote:
The limit on max_standby_streaming_delay is currently 35 minutes
(around) - or you have to set it to unlimited. This is because the GUC
is limited to MAX_INT/1000, unit milliseconds.
Is there a reason for the /1000, or is it
Excerpts from Pavel Stehule's message of jue dic 16 16:19:17 -0300 2010:
The most performance issue of access to a untoasted array is solved
with other patch.
Was the other patch applied?
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
This patch remove redundant rows from PL/pgSQL executor (-89 lines).
Doesn't change a functionality.
I'm not really impressed with this idea: there's no a priori reason
that all those loop types would
Robert Haas robertmh...@gmail.com writes:
I think the attached might be a little tidier. Thoughts?
I'm not really thrilled at the idea of calling
IsPostmasterChildWalSender for every child whether or not it will have
any impact on the decision. That involves touching shared memory which
can be
On Thu, Dec 16, 2010 at 07:24:46PM -0800, David Wheeler wrote:
On Dec 16, 2010, at 6:39 PM, Alex Hunsaker wrote:
Grr that should error out with Invalid server encoding, or worst
case should return a length of 3 (it utf8 encoded 128 into 2 bytes
instead of leaving it as 1). In this case
On tor, 2010-12-16 at 22:31 +0100, Gevik Babakhani wrote:
I was wondering if there has been anyone experimenting to compile PG
using LLVM/clang compiler tools.
This has been dealt with a number of times. Search the archives.
--
Sent via pgsql-hackers mailing list
2010/12/17 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from Pavel Stehule's message of vie dic 17 07:02:00 -0300 2010:
Hello
This patch remove redundant rows from PL/pgSQL executor (-89 lines).
Doesn't change a functionality.
Hmm I'm not sure but I think the new code has some of the
2010/12/17 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from Pavel Stehule's message of jue dic 16 16:19:17 -0300 2010:
The most performance issue of access to a untoasted array is solved
with other patch.
Was the other patch applied?
no, it's in queue for next commitfest
Pavel Stehule pavel.steh...@gmail.com writes:
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
I'm not really impressed with this idea: there's no a priori reason
that all those loop types would necessarily have exactly the same
control logic.
There is no reason why the processing should be same, but
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
I noticed that the fastpath code doesn't update ps_status, which would
be harmless except that it leads to idle in transaction being logged
in log_line_prefix for the command tag.
Are there objections to applying this?
Hm, what about
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
I'm not really impressed with this idea: there's no a priori reason
that all those loop types would necessarily have exactly the same
control logic.
There is no
Pavel Stehule pavel.steh...@gmail.com writes:
I am resending a redesigned proposal about special plpgsql statement
that support iteration over an array.
OK ...
== Iteration over multidimensional arrays ==
Its designed to reduce one dimension from source array. It can remove
a slicing and
On 15.12.2010 16:20, Florian Pflug wrote:
On Dec14, 2010, at 15:01 , Robert Haas wrote:
On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflugf...@phlo.org wrote:
- serializable lock consistency - I am fairly certain this needs
rebasing. I don't have time to deal with it right away. That sucks,
On Fri, Dec 17, 2010 at 10:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
I am resending a redesigned proposal about special plpgsql statement
that support iteration over an array.
OK ...
== Iteration over multidimensional arrays ==
Its designed to
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I am resending a redesigned proposal about special plpgsql statement
that support iteration over an array.
OK ...
== Iteration over multidimensional arrays ==
Its designed to reduce one dimension from
On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think the attached might be a little tidier. Thoughts?
I'm not really thrilled at the idea of calling
IsPostmasterChildWalSender for every child whether or not it will have
any
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Dec 17, 2010 at 10:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This seems like a really bad, confusing idea. I think it should throw
a type-mismatch error in this case. If there is any use-case for such a
thing, which I'm quite unconvinced of,
Excerpts from Tom Lane's message of vie dic 17 12:27:30 -0300 2010:
Robert Haas robertmh...@gmail.com writes:
I think the attached might be a little tidier. Thoughts?
I'm not really thrilled at the idea of calling
IsPostmasterChildWalSender for every child whether or not it will have
any
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not really thrilled at the idea of calling
IsPostmasterChildWalSender for every child whether or not it will have
any impact on the decision. That involves touching shared memory
On Fri, Dec 17, 2010 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas rh...@postgresql.org writes:
Reset 'ps' display just once when resolving VXID conflicts.
This prevents the word waiting from briefly disappearing from the ps
status line when ResolveRecoveryConflictWithVirtualXIDs
Alvaro Herrera alvhe...@commandprompt.com writes:
Is it possible to save the is walsender flag in the Backend struct?
That would make it possible to solve the problem very easily.
Yeah, I was wondering about that too, but the problem is that the
postmaster doesn't know that at the time it forks
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I imagine the reason for the original coding was to avoid a useless
gettimeofday kernel call in the common case that there are no
conflicting xacts to wait for. Could we restore that
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Dec 17, 2010 at 10:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This seems like a really bad, confusing idea. I think it should throw
a type-mismatch error in this case. If there is any use-case for such a
On Fri, Dec 17, 2010 at 11:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think what we ought to be looking to do is get rid of the distinction,
so that the postmaster treats walsenders the same as other children.
It's not apparent to me that the existing places where postmaster.c
makes that
Excerpts from Fujii Masao's message of mié dic 15 00:54:39 -0300 2010:
Hi,
I found a bug which always prevents SignalSomeChildren with
BACKEND_TYPE_WALSND from sending a signal to walsender.
Though currently SignalSomeChildren with BACKEND_TYPE_WALSND
has not been called anywhere, it's
On 17/12/2010 7:17 PM, Magnus Hagander wrote:
What version of dbghelp do you have?
6.1.7600.16385 by default, as shipped in Windows 7 32-bit, and what I
was testing with.
6.12.0002.633 is what came with my copy of Debugging Tools for windows,
from the windows SDK. The same version comes
Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Is it possible to save the is walsender flag in the Backend struct?
That would make it possible to solve the problem very easily.
Yeah, I was wondering about that too, but
On fre, 2010-12-17 at 12:57 +0100, Magnus Hagander wrote:
The limit on max_standby_streaming_delay is currently 35 minutes
(around) - or you have to set it to unlimited. This is because the GUC
is limited to MAX_INT/1000, unit milliseconds.
Is there a reason for the /1000, or is it just an
On Fri, Dec 17, 2010 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I imagine the reason for the original coding was to avoid a useless
gettimeofday kernel call in the common case
Pavel Stehule pavel.steh...@gmail.com writes:
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Furthermore, it's underspecified: who's to say how many dimensions of
the array are supposed to get sliced off? Â There's no reasonable place
to extend this syntax to specify that. Â It will also be
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
I think what we ought to be looking to do is get rid of the distinction,
so that the postmaster treats walsenders the same as other children.
I think the problem with this is
On Dec17, 2010, at 16:49 , Heikki Linnakangas wrote:
On 15.12.2010 16:20, Florian Pflug wrote:
On Dec14, 2010, at 15:01 , Robert Haas wrote:
On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflugf...@phlo.org wrote:
- serializable lock consistency - I am fairly certain this needs
rebasing. I don't
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I was wondering if there has been anyone experimenting to compile PG
using LLVM/clang compiler tools.
I got it working on Linux but it required a Postgres src file change to work
properly (see previous thread by me). Supposedly the clang
On Fri, Dec 17, 2010 at 17:24, Craig Ringer cr...@postnewspapers.com.au wrote:
On 17/12/2010 7:17 PM, Magnus Hagander wrote:
What version of dbghelp do you have?
6.1.7600.16385 by default, as shipped in Windows 7 32-bit, and what I was
testing with.
6.12.0002.633 is what came with my copy
On Fri, Dec 17, 2010 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Furthermore, it's underspecified: who's to say how many dimensions of
the array are supposed to get sliced off? There's no reasonable
On Fri, Dec 17, 2010 at 11:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
I think what we ought to be looking to do is get rid of the distinction,
so that the postmaster treats
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Furthermore, it's underspecified: who's to say how many dimensions of
the array are supposed to get sliced off? There's no reasonable place
to extend this syntax to
On Sat, Dec 18, 2010 at 02:03, Merlin Moncure mmonc...@gmail.com wrote:
FOREACH scalar-variable IN ARRAY array-expression
FOR_EACH scalar-variable IN ARRAY array-expression
FOR_SLICE array-variable [DEPTH n] IN ARRAY array-expression
FOREACH scalar-variable IN ARRAY
2010/12/17 Merlin Moncure mmonc...@gmail.com
On Fri, Dec 17, 2010 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Furthermore, it's underspecified: who's to say how many dimensions of
the array are
On Fri, Dec 17, 2010 at 17:42, Magnus Hagander mag...@hagander.net wrote:
On Fri, Dec 17, 2010 at 17:24, Craig Ringer cr...@postnewspapers.com.au
wrote:
On 17/12/2010 7:17 PM, Magnus Hagander wrote:
Now, that's annoying. So clearly we can't use that function to
determine which version we're
On 17.12.2010 19:08, Robert Haas wrote:
On Fri, Dec 17, 2010 at 11:43 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herreraalvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 13:18:35 -0300 2010:
I think what we ought to be looking to do is get rid of the
Merlin Moncure mmonc...@gmail.com writes:
another way:
FOREACH scalar IN ARRAY arr_exp DIMS in dim_var
dim_var being int[], or possibly text, of length #dimensions, giving
per dimesion index.
[ scratches head... ] I don't follow what you envision this doing,
exactly?
I'm not thrilled with
2010/12/17 Itagaki Takahiro itagaki.takah...@gmail.com:
On Sat, Dec 18, 2010 at 02:03, Merlin Moncure mmonc...@gmail.com wrote:
FOREACH scalar-variable IN ARRAY array-expression
FOR_EACH scalar-variable IN ARRAY array-expression
FOR_SLICE array-variable [DEPTH n] IN ARRAY
On Fri, Dec 17, 2010 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
another way:
FOREACH scalar IN ARRAY arr_exp DIMS in dim_var
dim_var being int[], or possibly text, of length #dimensions, giving
per dimesion index.
[ scratches head... ] I
On 12/17/2010 12:15 PM, Pavel Stehule wrote:
2010/12/17 Itagaki Takahiroitagaki.takah...@gmail.com:
It should be not a main subject, but I remember there was a discussion
that IN ARRAY array-expression looks redundant for a literal array:
IN ARRAY ARRAY[1, 3, 5]
Are there any improvement
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Dec 17, 2010 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
[ scratches head... ] I don't follow what you envision this doing,
exactly?
It's like _pg_expandarray but alterted support multiple dimensions:
select * from
Andrew Dunstan and...@dunslane.net writes:
On 12/17/2010 12:15 PM, Pavel Stehule wrote:
The reason for this is bigger space for possible
future features related to FOREACH loop.
So what you're saying is we need to allow ugliness now so we can have
more ugliness in future? I don't find that
2010/12/17 Andrew Dunstan and...@dunslane.net:
On 12/17/2010 12:15 PM, Pavel Stehule wrote:
2010/12/17 Itagaki Takahiroitagaki.takah...@gmail.com:
It should be not a main subject, but I remember there was a discussion
that IN ARRAY array-expression looks redundant for a literal array:
Dne 12.12.2010 15:43, Heikki Linnakangas napsal(a):
On 12.12.2010 15:17, Martijn van Oosterhout wrote:
On Sun, Dec 12, 2010 at 03:58:49AM +0100, Tomas Vondra wrote:
Very cool that you're working on this.
+1
Lets talk about one special case - I'll explain how the proposed
solution works,
On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
Well, we did beat up Pavel over trying to shoehorn this facility into
the existing FOR syntax, so I can hardly blame him for thinking this
way. The question is whether we're willing to assume that FOREACH will
be limited to iterating over arrays,
On Wed, Dec 15, 2010 at 2:20 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Looks ok. I'd suggest rewording this comment though:
[ the comment in question ]
It's a bit hard to follow, as it first lists exceptions on when we must
flush XLOG immediately, and then lists
David E. Wheeler da...@kineticode.com writes:
On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
Well, we did beat up Pavel over trying to shoehorn this facility into
the existing FOR syntax, so I can hardly blame him for thinking this
way. The question is whether we're willing to assume that
On Fri, Dec 17, 2010 at 08:30, David Fetter da...@fetter.org wrote:
On Thu, Dec 16, 2010 at 07:24:46PM -0800, David Wheeler wrote:
On Dec 16, 2010, at 6:39 PM, Alex Hunsaker wrote:
Grr that should error out with Invalid server encoding, or worst
case should return a length of 3 (it utf8
On Tue, Dec 14, 2010 at 5:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 14, 2010 at 4:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, the first
On Fri, Dec 17, 2010 at 12:58 PM, Tomas Vondra t...@fuzzy.cz wrote:
In the end, all they need to compute an estimate is number of distinct
values for each of the columns (we already have that in pg_stats) and a
number of distinct values for the group of columns in a query. They
really don't
Given the foregoing discussion, I see only two possible paths forward here.
1. Just decide that that unlogged tables can't have GIST indexes, at
least until someone figures out a way to make it work. That's sort of
an annoying limitation, but I think we could live with it.
+1
In the small
On Fri, Dec 17, 2010 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
Well, we did beat up Pavel over trying to shoehorn this facility into
the existing FOR syntax, so I can hardly blame him for thinking
Folks,
Is there any good reason that this works:
postgres=# select ('1e+01'::numeric)::integer
postgres-# ;
int4
--
10
But this doesn't?
postgres=# select '1e+01'::Integer
postgres-# ;
ERROR: invalid input syntax for integer: 1e+01
LINE 1: select '1e+01'::Integer
... or did we just
We would need an extra keyword if there were some third kind of
iteration that was fundamentally different from either of these, but
like I said, I don't see a plausible candidate. So right at the moment,
I'm leaning to the position that we could do without the ARRAY keyword
in FOREACH. If
Robert Haas robertmh...@gmail.com writes:
Given the foregoing discussion, I see only two possible paths forward here.
1. Just decide that that unlogged tables can't have GIST indexes, at
least until someone figures out a way to make it work. That's sort of
an annoying limitation, but I think
On Fri, Dec 17, 2010 at 11:51, Alex Hunsaker bada...@gmail.com wrote:
Also note this is just a simple test case, perl *could* elect to store
completely ascii strings internally as utf8. In those cases we still
Erm... not ascii I mean bytes 127
--
Sent via pgsql-hackers mailing list
On 17.12.2010 21:04, Robert Haas wrote:
Unfortunately, there are likely to be a limited number of such
keywords available. While I agree it's helpful to have a clear
distinction between what FOR does and what FOREACH does, it's wholly
conventional here and won't be obvious without careful
2010/12/17 Robert Haas robertmh...@gmail.com:
On Fri, Dec 17, 2010 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
Well, we did beat up Pavel over trying to shoehorn this facility into
the existing FOR
Robert Haas robertmh...@gmail.com writes:
Unfortunately, there are likely to be a limited number of such
keywords available. While I agree it's helpful to have a clear
distinction between what FOR does and what FOREACH does, it's wholly
conventional here and won't be obvious without careful
Pavel Stehule pavel.steh...@gmail.com writes:
Second semi argument for using ARRAY keyword is a verbosity of
PL/pgSQL. So from this perspective a ARRAY should be minimally
optional and ensure, so expr result will be really a array. But with a
optional ARRAY keyword we leaving a simple
On 17.12.2010 21:07, Tom Lane wrote:
IIUC, the problem is that the bufmgr might think that a GIST NSN is an
LSN that should affect when to force out a dirty buffer? What if we
taught it the difference? We could for example dedicate a pd_flags
bit to marking pages whose pd_lsn isn't actually an
Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
I noticed that the fastpath code doesn't update ps_status, which would
be harmless except that it leads to idle in transaction being logged
in log_line_prefix for the command
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 17.12.2010 21:07, Tom Lane wrote:
IIUC, the problem is that the bufmgr might think that a GIST NSN is an
LSN that should affect when to force out a dirty buffer? What if we
taught it the difference? We could for example
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
Second semi argument for using ARRAY keyword is a verbosity of
PL/pgSQL. So from this perspective a ARRAY should be minimally
optional and ensure, so expr result will be really a array. But with a
optional
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
Hm, what about pgstat_report_activity()?
I wasn't sure about that, because of the overhead, but now that I look
at it, it's supposed to be cheaper than changing the ps_status
On Fri, Dec 17, 2010 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
IIUC, the problem is that the bufmgr might think that a GIST NSN is an
LSN that should affect when to force out a dirty buffer? What if we
taught it the difference? We could for
Robert Haas robertmh...@gmail.com writes:
Another possibly-useful thing about mandating a full page header for
every page is that it might give us a way of avoiding unnecessary full
page writes. As I wrote previously:
Could we do that via a bufmgr status bit, instead? Heikki's idea has
the
On Fri, Dec 17, 2010 at 2:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 17.12.2010 21:07, Tom Lane wrote:
IIUC, the problem is that the bufmgr might think that a GIST NSN is an
LSN that should affect when to force out a dirty
On Fri, Dec 17, 2010 at 2:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Another possibly-useful thing about mandating a full page header for
every page is that it might give us a way of avoiding unnecessary full
page writes. As I wrote previously:
Could
Josh Berkus j...@agliodbs.com writes:
postgres=# select '1e+01'::Integer
postgres-# ;
ERROR: invalid input syntax for integer: 1e+01
I have never heard of any programming system anywhere that accepts such
a syntax for integers (assuming it distinguishes integers from other
numbers at all).
Excerpts from Tom Lane's message of vie dic 17 16:25:17 -0300 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
Hm, what about pgstat_report_activity()?
I wasn't sure about that, because of the overhead, but now
On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Unfortunately, there are likely to be a limited number of such
keywords available. While I agree it's helpful to have a clear
distinction between what FOR does and what FOREACH does,
On 17.12.2010 21:32, Robert Haas wrote:
I guess the question is whether it's right to conflate table is
unlogged with LSN is fake. It's not immediately obvious to me that
those concepts are isomorphic, although though the reverse isn't
obvious to me either.
The buffer manager only needs to
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Unfortunately, there are likely to be a limited number of such
keywords available. While I agree it's helpful to have a clear
distinction
On Fri, Dec 17, 2010 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Unfortunately, there are likely to be a limited number of such
keywords
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 17.12.2010 21:32, Robert Haas wrote:
I guess the question is whether it's right to conflate table is
unlogged with LSN is fake. It's not immediately obvious to me that
those concepts are isomorphic, although though the reverse
On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 17.12.2010 21:32, Robert Haas wrote:
I guess the question is whether it's right to conflate table is
unlogged with LSN is fake. It's not immediately obvious to
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
plpgsql's parser is rickety enough that I don't have a lot of confidence
in its ability to do things that way.
Bummer. Rickety is not good.
Agreed, but it's not entirely the
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. I think that BM_UNLOGGED might be a poor choice for the flag name,
just because it overstates what the bufmgr needs to assume.
I was actually thinking of adding BM_UNLOGGED
1 - 100 of 159 matches
Mail list logo