After taking look at our monitoring system i think some hint about previous
SQL might be useful.
dbadb70db_nameWARNING1long transactions, duration
2690min user=postgres pid=7887 waiting=False query=IDLE in transaction
Currently i have no idea what exactly did i kill without
It was just yesterday when i wondering why we don't have this feature (i was
trying to use it and it wasn't there :).
The group of people who think it's unsafe should not use the feature.
Clearly this feature would be useful when managing large amounts of servers
and would simplify our release
How do you use -s to exclude data for some tables from otherwise full dump?
Dump schema and data separately?
On Fri, May 1, 2009 at 6:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Vadim Trochinsky m...@vadim.ws writes:
This is a patch that allows choosing not to dump the data for the
selected
On Sat, Mar 7, 2009 at 9:29 PM, Dimitri Fontaine dfonta...@hi-media.comwrote:
In fact, maybe a new option to set the OUT parameters prefix to use from
within the function body would do?
Le 7 mars 09 à 19:56, Dimitri Fontaine a écrit :
CREATE OR REPLACE FUNCTION test_out
(
IN a integer,
Hi
It was one of my worst Friday's finding out that this brain dead
implementation of out parameters had been part of fuck up again.
This time we did notice it two days too late.
I wish for a way to use out parameters in functions only through some
predefined prefix like in triggers new and old.
Did this change hashtext() visible to users? We have been using it quite
widely for partitioning our databases. If so then it should be marked quite
visibly in release notes as there might be others who will be hit by this.
regards
Asko
On Mon, Feb 9, 2009 at 11:22 PM, Tom Lane
I would agree with making it stricter. It would force people to do less
stupid things.
Our main use case for default parameter will be getting rid of all the old
versions of functions with shorter parameter lists by just creating new
versions of old functions with additional default parameters.
On Fri, Dec 12, 2008 at 8:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Michael Meskes mes...@postgresql.org writes:
On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
Hmm ... actually, ecpg might be a problem here anyway. I know it has
special meaning for :name, but does it allow
Hi
We use plproxy for this kind of security enhancement. We create plpgsql
functions that do whats needed and then we create so called proxy database
that contains only plproxy interfaces for these functions. Users get access
only to proxy database. This way it is easier to rest assured that
On Thu, Oct 2, 2008 at 6:46 PM, Bob Henkel [EMAIL PROTECTED] wrote:
Have you looked at creating a function in perl and creating a new
connection? Or using a dblink query which can create a new connection?
These two methods work. I have used them to insert to a log table regardless
of the
On Mon, Sep 22, 2008 at 5:41 AM, Stephen Frost [EMAIL PROTECTED] wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
If we were to accept the pg_attrdef approach, why aren't we
doing a pg_attracl table instead of adding a column to pg_attribute?
On Wed, Sep 10, 2008 at 1:39 PM, Zdenek Kotala [EMAIL PROTECTED]wrote:
I has played with new hash index implementation and I tried following
command:
postgres=# select * from test where id between 1 and 5;
Time: 9651,033 ms
postgres=# explain select * from test where id between 1 and 5;
On Sat, Sep 6, 2008 at 2:29 AM, Euler Taveira de Oliveira [EMAIL PROTECTED]
wrote:
Martin Pihlak escreveu:
I suspected that, but somehow managed to overlook it :( I guess it was
too tempting to use it. I'll start looking for alternatives.
If you can't afford a 500 msec pgstat time, then
Too frequent read protection is already handled in the patch but these
comments might lead it into new directions. Current implementation had this
same limit that file was written no more than once per 500 ms.
On Sat, Sep 6, 2008 at 9:12 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera
On Fri, Sep 5, 2008 at 7:37 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
So, you'll implement the part of SQL-MED that deals with specifying remote
connections, e.g something like CREATE CONNECTION (no, I haven't looked at
what the syntax actually is)?
Yeah, that sounds like a good idea.
On Wed, Sep 3, 2008 at 9:17 AM, daveg [EMAIL PROTECTED] wrote:
On Thu, Aug 14, 2008 at 06:50:09PM +0100, Simon Riggs wrote:
On Fri, 2008-08-08 at 16:23 -0400, Tom Lane wrote:
NOT IN is a lot trickier,
condition: you must also assume that the comparison operator involved
never
On Wed, Sep 3, 2008 at 11:20 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Marko Kreen wrote:
On 9/2/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
In the meantime, here is simple patch for case-insensivity.
You might be able to talk me into accepting various
Anything that will reduce potential downtime should be way to go.
To me it seems that Peter uses the loudest voice and others just don't care
enough.
Using kB for kilobyte seems quite alien and confusing. I have not noticed
that to be used in software i use in my everyday work and could not find
On Mon, Sep 1, 2008 at 12:59 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Does anyone think this might be too chatty?
No.
+1
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
As stated above this format is mainly good for copy paste and may require
occasional manual tweaking.
Users should be people who use psql in their everyday work and on the other
hand need to publish data from database in some other places. Would you
please bring examples of some widespread
On Wed, Aug 20, 2008 at 9:15 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Idly thumbing through the new TODO list, I noticed that the second item
from the bottom (about how we don't want optional AS) has been
superseded by events ...
Would AS be harder to implement?
select foo(10 AS a, 20 AS b);
select foo(20 AS b, 20 AS a);
select x(0 = 1 AS a);
other fantasies
select foo(10 a, 20 b);
select foo(a 10, b 20);
regards,
Asko
On Wed, Aug 20, 2008 at 4:26 PM, Pavel Stehule [EMAIL PROTECTED]wrote:
2008/8/20 Tom Lane [EMAIL
Proposed formats don't look easier to read for humans.
I doubt that they are more common or easier to process by machines than just
COPY query TO STDOUT CSV;
The reason for this is to allow the output to be fed directly into any
system using Restructured text
The idea would be to use psql as
The lack of plan invalidation is limitation that also has two bugs attached
to it.
I agree that full fledged patch to fix all the isssues should not be done in
8.3.
I can't agree that effort to get the bugs fixed already in 8.3 should not be
made.
I can understand that hackers here have learned to
at 03:12:43PM +0300, Asko Oja wrote:
- If there is nothing that can be done in 8.3 at least warning should be
added into the documentation. It will be just one more don't in our long
list don'ts for our developers.
I am in favour of that change in the 8.3 branch.
ERROR: cache lookup
in partitions due to cache problems it creates. Could you tell me
what I should do? Thanks
On Tue, Aug 19, 2008 at 3:29 AM, Tom Lane [EMAIL PROTECTED] wrote:
Asko Oja [EMAIL PROTECTED] writes:
For users of stored procedures it is protection from downtime. For Skype
it
has been around 20% of databse
Polite answers lead to polite discussions. Caling other people names lead to
flame wars.
It's perfectly ok for Skype to keep our own build of 8.3 with given patch
and make it available for whoever might want it. At least now there is
almost good enough description why the patch was needed althou
Another thing I do not understand well is how people are expected to work
in
8.3 with a function based API, without hitting Skype problems.
People are expected to use same workarounds as Skype is using. For us
another unneccessary downtime week ago was what set us moving/thinking :).
When you
Every thread we are concerned in turns into something strange thing that is
almost entirely differnet from the original intention. First thread we
started was with the intention to discuss how we should handle the problem.
Instead of discussion it was trolled into oblivion. Then we thought so what
In my experience synonyms as well as rules are hacks and should be avoided
althou there are cases where they can save some work for dba's during
transitions from one situation to better one.
There is also another possible way one might want to create a
compatibility
type. Instead of creating a
Does it change of result some queries?
Patch in itself is not changing what the queries return. It just gets rid of
error condition from which Postgres itself is not able to recover.
It is protection to server's hang?
For users of stored procedures it is protection from downtime. For Skype it
Not able to means not implementable o not implemented ?
On Sun, Aug 17, 2008 at 6:59 PM, Pavel Stehule [EMAIL PROTECTED]wrote:
Hannu
it's not possible inNot able to plpgsql, because we are not able iterate
via record.
Pavel
2008/8/17 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-17
I can say that we have had several times to use bigint instead because of
the lack of uint type in postgres.
On Sun, Aug 17, 2008 at 9:03 PM, Ryan Bradetich [EMAIL PROTECTED]wrote:
On Sat, Aug 16, 2008 at 10:53 AM, Decibel! [EMAIL PROTECTED] wrote:
On Aug 15, 2008, at 1:00 AM, Ryan Bradetich
Hi
We need plan invalidation fix in 8.3 also at least it would make migrating
from 8.2 to 8.3 much more attractive.
Currenlty we are having problems related to plan invalidation couple of
times per week (mainly we have to let developers change their code before we
release it into live databases
ALTER VIEW does not sound useful for me.
CREATE OR REPLACE VIEW should create or replace view and only thing that
should be same is the name of the view. It's up to Postgres to invalidate
all plans and up to developer to make sure that all places where his view is
used will stay still working. All
It would make PostgreSQL too much like Oracle ;) Let's keep PostgreSQL
simple and compact please.
I prefer applications retest when migrating to new PostgreSQL version. In
this case surprises happen then you expect them not in some unforeseen point
of time in the future.
Keeping all this old
Don't you think we try to be careful but still we manage to overlook several
times in year something and cause some stupid downtime.
On Wed, Aug 6, 2008 at 9:13 PM, Merlin Moncure [EMAIL PROTECTED] wrote:
On Wed, Aug 6, 2008 at 2:20 AM, Marko Kreen [EMAIL PROTECTED] wrote:
But the main
Hi
Sadly PostgreSQL inability to invalidate plan cache when function is dropped
causes us downtime and costs money.
ERROR: cache lookup failed for function 24865)
This time our developers just rewrote function to use OUT parameters instead
of return type.
Currently i had to forbid dropping
Hi
Thanks for pointing to another thing to fix :)
postgres=# create type public.ret_status as ( status integer, status_text
text);
CREATE TYPE
postgres=# create or replace function pavel ( i_param text ) returns
public.ret_status as $$ select 200::int, 'ok'::text; $$ language sql;
CREATE
This is simply a bad, wrong, stupid way to do it. Why do you not use
CREATE OR REPLACE FUNCTION?
I totally agree we should get this fixed first :)
postgres=# create or replace function pavel ( i_param text, status OUT int,
status_text OUT text ) returns record as $$ select 200::int,
) returns record as $$ select
200::int, 'ok'::text, 'tom'::text; $$ language sql;
ERROR: cannot change return type of existing function
DETAIL: Row type defined by OUT parameters is different.
HINT: Use DROP FUNCTION first.
On Tue, Aug 5, 2008 at 5:04 PM, Asko Oja [EMAIL PROTECTED] wrote
Sounds very much like 80% 20% story. 80% that was easy to do is done and now
20% that is complex and progress is slow is left to be done. Sounds very
familiar from the comment in plan cache invalidation :)
On Tue, Aug 5, 2008 at 5:51 PM, Tom Lane [EMAIL PROTECTED] wrote:
I've pretty much
Marko is talking about types created with CREATE TYPE
CREATE FUNCTION fraud.get_user_status(
i_key_user text
) RETURNS ret_get_user_status AS
$$
Current pg_dump annoyingly removes schem reference from type.
On Wed, Jul 23, 2008 at 6:19 PM, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen
Not so sure about omitting OR REPLACE. In my experience it is more often
needed than not. Main argument for omitting might be to protect hackers from
carelesse users :)
On Wed, Jul 23, 2008 at 5:50 PM, Tom Lane [EMAIL PROTECTED] wrote:
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
At 2008-07-17
Tom RETURNS TABLE columns semantically just the same as OUT parameters.
I hope you are not proposing to create another case of crippled OUT
parameters that are quite problematic to use together with inline sql or has
it gotten fixed on the road (we are still using 8.2 on most of our servers).
On
Hi hackers
Just my non hacker view on the pl/proxy matter.
From FAQ:
PL/Proxy is compact language for remote calls between PostgreSQL databases.
Why we submitted pl/proxy into core at all?
1. Current core distribution contains dblink which sucks both usability wise
and security wise but being
Hi
One of reasons to get PL/proxy into core is to make it available to Windows
users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would like
to hear how.
Asko
On Fri, Jul 25, 2008 at 2:19 AM, Tom Lane [EMAIL
Just use plproxy and skip all the hassle of dblink :)
On Mon, Jun 2, 2008 at 3:14 AM, Joe Conway [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Tommy Gildseth [EMAIL PROTECTED] writes:
One obvious disadvantage of this approach, is that I need to connect and
disconnect in every function. A
48 matches
Mail list logo
