Hello
I'm not against having SQL/PSM support. I'm just saying I'm not
willing to support two copies of plpgsql to do it.
regards, tom lane
I understand it well. Pending development of plpgpsm I respected
unbreakability plpgsql. So I can move duplicate parts to
Hi,
Sorry for the delay, but the reply of Tom didn't reach me. I've modified
the patch according to Tom's comments. I hope I am not too late.
Regards.
fuzzystrmatch-levenshtein.patch.1
Description: Binary data
On Wed, 2 Apr 2008, Bruce Momjian [EMAIL PROTECTED] writes:
Because of lack of
Hello!
Attached is a simple patch which adds a \G backslash command, that is
similar \g command. The difference is that \G prints results using
extended output format. After the query the format is reset to the original
value.
In other words command like:
SELECT * FROM pg_stat_activity\G
is
--On Donnerstag, April 03, 2008 03:13:47 +0100 Gregory Stark
[EMAIL PROTECTED] wrote:
I think you're crazy to think shells are more likely to have conflicts.
Shells require a whole token match, not just the first letter.
In other words, any alias *starting with* the letters c, d, e, f, g, h,
Bernd Helmle [EMAIL PROTECTED] writes:
Picture a newbie typoing on their \old alias and trying to figure out
where all their data is going... Hopefully they weren't too attached to
whatever was in their ldd file yesterday.
Of course, the patch doesn't work this way. Only complete tokens
Am Donnerstag, 3. April 2008 schrieb Gregory Stark:
To be more explicit what I meant was someone doing
#= \alias old select version();
...
#= \oldd
oops
#= \old
#= select 'where is all my output going?'
#= select 'what happened to my ldd file?'
This is a valid concern, but it is
Peter Eisentraut [EMAIL PROTECTED] writes:
This is a valid concern, but it is orthogonal to the alias feature. You have
the same problem already if you mistype
\oo instead of \o
\ofoo instead of \obar
Not really. In these cases you know what \o is going to do, you've just typo'd
the
Am Donnerstag, 3. April 2008 schrieb Gregory Stark:
\old means something *today*. In the proposed syntax by creating the alias
you're changing what it means.
Yes. There are two complementary responses to that:
1. That's an intentional, useful feature of aliases.
2. If you don't like it, don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 3. April 2008 schrieb Gregory Stark:
#= \oldd
#= \old
#= select 'where is all my output going?'
#= select 'what happened to my ldd file?'
psql allows you to omit the space between the command and argument?
Does
Pavel Stehule [EMAIL PROTECTED] writes:
I thinking about new directory structure (some like)
pl/sqlsp/ .. sql Stored Procedures
pl/sqlsp/utils
pl/sqlsp/plpgsql - only plpgpsm code
pl/sqlsp/plpgpsm - only plpgsql code
Maybe common instead of utils?
Also, where did plpgpsm come from? This
Heikki Linnakangas [EMAIL PROTECTED] writes:
On second thought, expanding AttrNumber to int32, wholesale, might not
be a good idea,
No, it wouldn't. For one thing it'd be a protocol break --- column
numbers are int16 --- and for another, we'd have terrible performance
problems with such wide
Am Donnerstag, 3. April 2008 schrieb Brendan Jurd:
psql allows you to omit the space between the command and argument?
Does anybody else find that weird?
What is the virtue of allowing such a syntax in the first place?
Combatability with hysterial practice.
--
Sent via pgsql-patches mailing
--On Freitag, April 04, 2008 01:11:51 +1100 Brendan Jurd
[EMAIL PROTECTED] wrote:
What is the virtue of allowing such a syntax in the first place? I
can't think of any other context where it's okay to issue a command
together with arguments without some kind of delimiter, for the
obvious
This patch adds a GUC parameter for tuple_fraction of cursors (discussed
earlier here:
http://archives.postgresql.org/pgsql-performance/2008-04/msg00018.php).
By setting this parameter the planner's favor to use fast-start plans
for cursors can be affected.
Regards,
Robert
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On second thought, expanding AttrNumber to int32, wholesale, might not
be a good idea,
No, it wouldn't. For one thing it'd be a protocol break --- column
numbers are int16 ---
I wasn't planning to change that.
and for another,
--On Donnerstag, April 03, 2008 14:36:59 +0100 Gregory Stark
[EMAIL PROTECTED] wrote:
\o foo instead of \i foo -- check your keyboard layout
The point is here you've typed a different command entirely.
Unsurprisingly it's going to do something different.
Uh well, you surely don't know that
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually rows are supposed to be limited
to ~1600 columns, anyway, because of HeapTupleHeader limitations.
The trick is that that limitation doesn't apply to the intermediate
virtual tuples we move around in the executor.
I'm
Andrew Dunstan wrote:
Jonah H. Harris wrote:
On Tue, Apr 1, 2008 at 5:55 PM, Tom Lane [EMAIL PROTECTED] wrote:
The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
... I suspect anyone wanting to migrate
their existing SQL/PSM stuff to Postgres will be less than impressed by
our function body as a string mechanism.
Yeah, that's the other little problem with claiming standards-compliance
Volkan YAZICI wrote:
Hi,
Sorry for the delay, but the reply of Tom didn't reach me. I've modified
the patch according to Tom's comments. I hope I am not too late.
OK, great. I will re-add it to the current queue and add this email as
well.
--
Bruce Momjian [EMAIL PROTECTED]
Bernd Helmle [EMAIL PROTECTED] writes:
--On Donnerstag, April 03, 2008 14:36:59 +0100 Gregory Stark
[EMAIL PROTECTED] wrote:
\o foo instead of \i foo -- check your keyboard layout
The point is here you've typed a different command entirely.
Unsurprisingly it's going to do something
Tom Lane wrote:
I still haven't seen the actual bug description come by here, and the
pgsql-bugs archive hasn't got it either.
http://archives.postgresql.org/pgsql-bugs/2008-03/msg00351.php
and continues in April here
http://archives.postgresql.org/pgsql-bugs/2008-04/msg00031.php
Gregory Stark [EMAIL PROTECTED] writes:
I think you have to find a syntax where the current commands continue to mean
exactly what they always meant and where typos can't result in an entirely
different kind of behaviour.
Yeah, the fundamental difference between the backslash command
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I still haven't seen the actual bug description come by here, and the
pgsql-bugs archive hasn't got it either.
(apparently some mails on that thread are missing ...)
That's what I meant. Heikki is quoting himself from a message that
Tom Lane wrote:
That's what I meant. Heikki is quoting himself from a message that
hasn't appeared anywhere public, and he must have had at least one
message from the OP that hasn't appeared either. So the rest of us
are still mostly in the dark about the problem.
I got this one, which
Seems discussion has now started on how to move this forward so this
patch is being kept for the next commit-fest.
---
Ireneusz Pluta wrote:
Hello,
there was postgresql-icu patch for proper collation of UTF8 character
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I still haven't seen the actual bug description come by here, and the
pgsql-bugs archive hasn't got it either.
(apparently some mails on that thread are missing ...)
That's what I meant. Heikki is quoting himself
Heikki Linnakangas [EMAIL PROTECTED] writes:
Oh, the query actually gives an assertion failure on an
assertion-enabled build, so this is clearly a bug:
TRAP: FailedAssertion(!(attnum 0 attnum =
list_length(rte-joinaliasvars)), File: parse_relation.c, Line: 1697)
Okay, I looked at this
Hell, Robert wrote:
This patch adds a GUC parameter for tuple_fraction of cursors (discussed
earlier here:
http://archives.postgresql.org/pgsql-performance/2008-04/msg00018.php).
By setting this parameter the planner's favor to use fast-start plans
for cursors can be affected.
I have added
Volkan YAZICI [EMAIL PROTECTED] writes:
Sorry for the delay, but the reply of Tom didn't reach me. I've modified
the patch according to Tom's comments. I hope I am not too late.
Applied after considerable revision. This patch:
* introduced a memory stomp that was not there before (I strongly
First whack at exposing the start and finish checkpoint times into SQL.
--
Theo Schlossnagle
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/
checkpoint_exposed.patch
Description: Binary data
--
Sent via pgsql-patches mailing list
Theo Schlossnagle wrote:
First whack at exposing the start and finish checkpoint times into SQL.
I suggest using GetCurrentTimestamp() directly instead of time_t and
converting.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting,
Theo Schlossnagle wrote:
First whack at exposing the start and finish checkpoint times into SQL.
Why is that useful?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 03 Apr 2008 23:21:49 +0100
Heikki Linnakangas [EMAIL PROTECTED] wrote:
Theo Schlossnagle wrote:
First whack at exposing the start and finish checkpoint times into
SQL.
Why is that useful?
For knowing how long checkpoints are taking.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Theo Schlossnagle wrote:
First whack at exposing the start and finish checkpoint times into SQL.
Why is that useful?
Does this implementation even work? It looks to me like the
globalStats.last_checkpoint_start/done fields will go back to zero the
On Thu, Apr 03, 2008 at 01:19:21PM -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
I think you have to find a syntax where the current commands continue to
mean
exactly what they always meant and where typos can't result in an entirely
different kind of behaviour.
Joshua D. Drake wrote:
Theo Schlossnagle wrote:
First whack at exposing the start and finish checkpoint times into
SQL.
Why is that useful?
For knowing how long checkpoints are taking. If they are taking too
long you may need to adjust your bgwriter settings, and it is a
On Sun, Mar 30, 2008 at 3:09 PM, Tom Lane [EMAIL PROTECTED] wrote:
I looked this over and realized that it has little to do with the
functionality that was so painfully hashed out in the original
discussion thread here:
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00207.php
As
Joshua D. Drake [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
Why is that useful?
For knowing how long checkpoints are taking. If they are taking too
long you may need to adjust your bgwriter settings, and it is a
serious drag to parse postgresql logs for this info.
Robert Treat wrote:
On Thursday 03 April 2008 19:08, Andrew Dunstan wrote:
Joshua D. Drake wrote:
Theo Schlossnagle wrote:
First whack at exposing the start and finish checkpoint times into
SQL.
Why is that useful?
For knowing how long checkpoints are
On Thursday 03 April 2008 19:08, Andrew Dunstan wrote:
Joshua D. Drake wrote:
Theo Schlossnagle wrote:
First whack at exposing the start and finish checkpoint times into
SQL.
Why is that useful?
For knowing how long checkpoints are taking. If they are taking too
long you may need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 03 Apr 2008 20:29:18 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
Why is that useful?
For knowing how long checkpoints are taking. If they are taking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 03 Apr 2008 20:45:37 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
Exposing everything into the log files isn't always sufficient
(says the guy who maintains a remote admin tool)
It should be now that you can have machine readable
Joshua D. Drake [EMAIL PROTECTED] writes:
I would agree with this. We would need a history of checkpoints that
didn't reset until we told it to.
Indeed, but the submitted patch has nought whatsoever to do with that.
It exposes some instantaneous state.
You could perhaps *build* a log facility
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 03 Apr 2008 21:26:46 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
I would agree with this. We would need a history of checkpoints that
didn't reset until we told it to.
Indeed, but the submitted
On Apr 3, 2008, at 7:08 PM, Andrew Dunstan wrote:
Joshua D. Drake wrote:
Theo Schlossnagle wrote:
First whack at exposing the start and finish checkpoint times into
SQL.
Why is that useful?
For knowing how long checkpoints are taking. If they are taking too
long you may need to
Joshua D. Drake wrote:
Exposing everything into the log files isn't always sufficient
(says the guy who maintains a remote admin tool)
It should be now that you can have machine readable logs (says the
guy who literally spent weeks making that happen) ;-)
And how does the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 03 Apr 2008 21:44:00 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
I think there is quite possibly a good case for keeping some
diagnostics in a table or tables, on a rolling basis, maybe. But then
that's a facility that needs to be
Theo Schlossnagle [EMAIL PROTECTED] writes:
Heikki: It it useful for knowing when the last checkpoint occurred.
I guess I'm wondering why that's important. In the current bgwriter
design, the system spends half its time checkpointing (or in general
checkpoint_completion_target % of the
Theo Schlossnagle wrote:
Has this feature been discussed on -hackers? I don't recall it (and
my memory has plenty of holes in it), but I'm sure that after
attending my talk last Sunday Theo hasn't sent in a patch for an
undiscussed feature ;-)
Andrew: I don't think this feature has
On Thursday 03 April 2008 21:14, Joshua D. Drake wrote:
On Thu, 03 Apr 2008 20:29:18 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
Why is that useful?
For knowing how long checkpoints are taking. If
Robert Treat [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
3. As of PG 8.3, the bgwriter tries very hard to make the elapsed time
of a checkpoint be just about checkpoint_timeout *
checkpoint_completion_target, regardless of load factors. So unless
your settings are completely
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 03 Apr 2008 22:33:15 -0400
Tom Lane [EMAIL PROTECTED] wrote:
JD seems to be on record that the existing logging mechanism sucks
and he needs something else. That's fine, but I think it means that
we need to improve logging in general, not
On Apr 3, 2008, at 10:33 PM, Tom Lane wrote:
Theo claimed he had a reason for wanting to know the latest checkpoint
time, *without* any intention of time-extended tracking of that; but
he didn't say what it was. If there is a credible reason for that
then it might justify a patch of this
Theo Schlossnagle [EMAIL PROTECTED] writes:
On Apr 3, 2008, at 10:33 PM, Tom Lane wrote:
Theo claimed he had a reason for wanting to know the latest checkpoint
time, *without* any intention of time-extended tracking of that; but
he didn't say what it was.
We had a recent event where the
On Thu, 3 Apr 2008, Robert Treat wrote:
You can plug a single item graphed over time into things like rrdtool to
get good trending information. And it's often easier to do this using
sql interfaces to get the data than pulling it out of log files (almost
like the db was designed for that :-)
Greg Smith wrote:
On Thu, 3 Apr 2008, Robert Treat wrote:
You can plug a single item graphed over time into things like rrdtool to
get good trending information. And it's often easier to do this using
sql interfaces to get the data than pulling it out of log files (almost
like the db
On Thu, 3 Apr 2008, Joshua D. Drake wrote:
For knowing how long checkpoints are taking. If they are taking too
long you may need to adjust your bgwriter settings, and it is a
serious drag to parse postgresql logs for this info.
There's some disconnect here between what I think you want here
On Thu, 3 Apr 2008, Tom Lane wrote:
As of PG 8.3, the bgwriter tries very hard to make the elapsed time of a
checkpoint be just about checkpoint_timeout *
checkpoint_completion_target, regardless of load factors.
In the cases where the timing on checkpoint writes are timeout driven.
When
On Friday 04 April 2008 00:09, Greg Smith wrote:
On Thu, 3 Apr 2008, Robert Treat wrote:
You can plug a single item graphed over time into things like rrdtool to
get good trending information. And it's often easier to do this using
sql interfaces to get the data than pulling it out of log
Robert Treat [EMAIL PROTECTED] writes:
I have to add, given that we already provide the time of last checkpoint
information via pg_controldata, I don't understand why people are against
making that information accesible to remote clients.
So, I can expect to see a patch next week that
On Thu, 3 Apr 2008, Tom Lane wrote:
the system stopped checkpointing does not strike me as a routine
occurrence that we should be making provisions for DBAs to watch for.
What, pray tell, is the DBA supposed to do when and if he notices that?
Schedule downtime rather than wait for it to
On Thu, 03 Apr 2008, Tom Lane [EMAIL PROTECTED] writes:
Volkan YAZICI [EMAIL PROTECTED] writes:
Sorry for the delay, but the reply of Tom didn't reach me. I've modified
the patch according to Tom's comments. I hope I am not too late.
Applied after considerable revision. This patch:
*
63 matches
Mail list logo
