On 09/15/2013 02:11 PM, Andres Freund wrote:
What did you actually try to find out? Greetings, Andres Freund
I was just trying to mentally sync up
http://www.postgresql.org/docs/9.3/static/xindex.html with (more)
concrete examples. Investigating pg_catalog seemed like the obvious
choice. T
(Using the new PostgreSQL v9.3.0)
I did a schema-only dump of the 'pg_catalog' schema in the hopes to
study how the built-in OPERATOR CLASSes are defined.
Doing so output a few warnings:
$ [pg930] pg_dump -s -n pg_catalog template1 > /tmp/pg_catalog.sql
pg_dump: WARNING: typtype of data type
On Feb 18, 2010, at 5:52 PM, Scott Bailey wrote:
> SQL name resolution rules are that column names have higher precedence than
> aliases and variables. So it will always bind to the column not the alias.
That explains it. Thanks. Breaks the rule of least surprise, but it is SQL.
eric
--
Sent
On Feb 18, 2010, at 4:31 PM, Scott Bailey wrote:
> I'm not sure why you would be surprised by that behavior. You are grouping by
> a timestamp, so any microsecond difference will be a new group.
I get that. ;) Hence the ::date. This is what doesn't make sense:
Expected: select day::date as
Maybe I'm getting too old to SQL anymore, but I ran across something yesterday
in a machine generated query that took me over an hour to figure out.
Here's a little testcase. Maybe somebody can explain why the last "Not
Expected" case does what it does.
select version();
PostgreSQL 8.4.1 on
On Dec 10, 2009, at 6:58 PM, Tom Lane wrote:
> It seems likely that the root cause is having somehow lost a wakeup signal
> somewhere
What would cause that?
eric
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
On Dec 10, 2009, at 6:28 PM, Tom Lane wrote:
> It looks like somehow the SInvalLock got stuck --- that would account
> for both the stack traces you show.
What's a SInvalLock? I looked at the code/comments for
ReceiveSharedInvalidMessages(), but it didn't make much sense out of context.
> I'
# select version():
PostgreSQL 8.1.10 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.2
(Gentoo 4.1.2 p1.0.1)
(I know, I know, it's an old version of PG whose sources aren't even available
today. Nonetheless, we've had great success with it.)
# uname -a
Linux servername 2.6.24.3-TCDI #16 S
On Sep 24, 2009, at 5:15 PM, Tom Lane wrote:
Yeah, you'll eventually overflow the balance fields because the deltas
are always positive. More recent versions of pgbench use a
positive-and-negative range for delta.
Awesome, thanks! Was really worried that our new hardware was flaking
out.
Okay, don't flame me for (still) using Postgres v8.1.10, but we were
running pgbench on new hardware today, and in the middle of like 50
various runs of pgbench, we saw this:
pgbench -c 20 -t 500 pgbench
starting vacuum...end.
Client 4 aborted in state 8: ERROR: integer out of range
Client 3
On Mar 6, 2009, at 3:49 PM, hubert depesz lubaczewski wrote:
On Fri, Mar 06, 2009 at 03:33:30PM -0500, Eric B. Ridge wrote:
So my question is really, what's the difference and why doesn't this
work with PL/PGSQL functions?
because it is long-time limitation of setof-returni
On Mar 6, 2009, at 3:27 PM, Raymond O'Donnell wrote:
When a function returns SETOF something, you need to treat it as if it
were a table, thus:
select * from unnest2(...);
Except that isn't true if the function is written in C.
CREATE OR REPLACE FUNCTION unnest(anyarray)
RETURNS SETOF anye
This is using PG v8.1.
I have a "table function" in C called "unnest". It takes "anyarray"
as its only argument and returns a set of "anyelement". It's a handy
little function for turning arrays into sets.
You can use it in two different ways:
SELECT * FROM unnest(ARRAY[1,2,3]);
o
On Mar 31, 2007, at 5:15 PM, Martijn van Oosterhout wrote:
Firstly, with autovacuum you really don't need to be running VACUUM
FULL anyway. VACUUM FULL is actually quite inefficient, you're better
off having higher FSM settings and leaving it to autovacuum.
Thank you (and Bill Moran) for the r
Hi! We've got a Postgres 8.1.5 installation with a 60GBish database:
=# select version();
version
---
PostgreSQL 8.1.5 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
4
On Jul 11, 2006, at 1:11 PM, Paul Tilles wrote:
ERROR: operator does not exist: smallint !=- integer
HINT: No operator matches the given name and argument type(s). You
may need to add explicit type casts.
I'm pretty sure the SQL-standard spelling of "not equals" is "<>".
Postgres support
On Mar 25, 2006, at 12:24 AM, Tom Lane wrote:
This is the sort of detail that you really should not omit.
Yeah, it didn't even occur to me until I ran the "explain execute foo
(42)" thing you suggested. We've been using these update rules for
so long that I just think of the views as regul
On Mar 24, 2006, at 11:39 PM, Tom Lane wrote:
The issue is probably that the planner is seeing a parameterized
query. Try this:
prepare foo(int8) as update some_other_table SET field = 'value'
WHERE id = $1;
explain execute foo(42);
I should have mentioned that while the UPDATE statement
I've found a few performance issues with an internal database
application and I'm sure it's related to my misunderstanding of how
and when queries are planned when used in a plpgsql function. This
is against Postgres 7.4.
For example, suppose this function is defined as a per-statement
u
On Mar 13, 2006, at 11:12 PM, Tom Lane wrote:
The relation-extension race condition could explain recently-added
tuples simply disappearing, though if it happened in more than one
table
you'd have to assume that the race condition window got hit more than
once. The slru race condition is eve
First off, let me make clear that I blame the strange data corruption
problem we encountered today on our hardware raid controller -- some
versions of its firmware are known-to-be-buggy and cause the raid set
to "drop" off, and we've encountered this problem in the past on this
particular s
On Mar 12, 2006, at 4:47 PM, Bob Pawley wrote:
Hi
I'm having trouble connecting the Postgresql JDBC drivers to Java
Studio Creator. No matter which of the Postgresql drivers, for
version 8.1, that I attempt for connection I continue to get an
error message "wrong driver: org.postgresql.D
On Jan 28, 2006, at 4:20 PM, Eric B. Ridge wrote:
Dude, "pg_dump" is not a psql command, nor is it a SQL command.
It's a command-line program. You run it from your shell:
$ pg_dump --schema-only pg_dump > xrms-schema.dmp
pardon my type-o. This should read:
$ pg_
On Jan 28, 2006, at 4:12 PM, Rich Shepard wrote:
Please keep replies on the mailing list.
Again, you can't use redirection via the psql prompt. But you can
do it
via your shell command line:
$ psql -c "\dt" > xrms.tables
Well, that doesn't seem to be working here, either:
[EMAIL PROT
On Jan 28, 2006, at 3:20 PM, Rich Shepard wrote:
contacts=# \d | less
\d: extra argument "less" ignored
You can't do this via the psql prompt. A simple "\d" will output to
the screen, automatically using your $PAGER if the output is too long
to fit on your screen.
I can, however, run '
On Jan 26, 2006, at 5:22 PM, Michael Fuhr wrote:
I suppose a sequence is out of the question? Too easy to get it
wrong?
Well, I just wanted to avoid embedding this idea into my
application. Would rather Postgres take care of it for me.
Not in the standard installation, but I think a C fu
On Jan 26, 2006, at 4:50 PM, Michael Fuhr wrote:
test=> SELECT xmin, * FROM foo;
xmin | x
+---
424584 | 1
424585 | 2
424584 | 3
(3 rows)
hmm. Is it possible to grab that first xmin value when the
transaction first starts, then I can explicitly use when I need it?
eric
--
On Jan 26, 2006, at 4:44 PM, Tom Lane wrote:
"Eric B. Ridge" <[EMAIL PROTECTED]> writes:
Outside of "VACUUM FREEZE", is there any way the "xmin" column in a
relation can change, assuming of course the tuple is never updated
again?
If the tuple lives l
Outside of "VACUUM FREEZE", is there any way the "xmin" column in a
relation can change, assuming of course the tuple is never updated
again? I'm considering using this as a way to identify all tuples
modified in the same transaction (in an effort to group them
together), and am wondering
On Nov 15, 2005, at 12:43 PM, Bruce Momjian wrote:
Cristian Prieto wrote:
Is there any way to get the numbers of items inside a cursor?
I can't see a way to do it except to do a FETCH ALL and count the
returned rows.
What we do, via JDBC is:
MOVE IN cursor_name;
The JDBC drivers
On Apr 25, 2005, at 9:42 PM, Alvaro Herrera wrote:
Well, you can get a page header corruption on any release as long
as you
have faulty hardware ... RAM randomly dropping bits is not unheard of.
Have you run memtest?
No doubt. :) What I was asking was if 7.3.9 (or .8 or .7) had a
known issue
We've got a PG 7.3.6 installation that just started receiving this
error:
2005-04-25 19:28:54 ERROR: Invalid page header in block 1110 of
the_table_name
We're also unable to dump that table using pg_dump. Postgres isn't
actually crashing, so I'm not sure how to get a backtrace out of i
On Aug 25, 2004, at 2:18 AM, Hadley Willan wrote:
Hi,
I was wondering if it's possible to order the result set by some
of the set contained in an IN clause.
I had to do something like this recently. Ended up with a pl/pgsql
function, looked a lot like this:
create or replace function arr
On Feb 25, 2004, at 9:07 PM, Joe Conway wrote:
Eric B.Ridge wrote:
I suppose this is obvious, but it's volatile because *other* backends
can change it while the current transaction is still in progress?
No. Other backends don't affect currval, but your own might on a
row-by-row basis. Consider:
On Feb 25, 2004, at 8:02 PM, Tom Lane wrote:
Brandon Craig Rhodes <[EMAIL PROTECTED]> writes:
But this same table suddenly becomes unwilling to use an index scan if
the target value is the result of the currval() function:
currval() is considered a volatile function, therefore it is unsafe to
use
On Jan 24, 2004, at 12:18 PM, Tom Lane wrote:
This surprises me. There's a moderate amount of overhead involved in
a plpgsql trigger, but I'd not have thought it would swamp the added
inefficiencies involved in a rule. Notice that you're getting a double
indexscan in the rule case --- that takes
if you execute 'select_gcc 3.1' as root it should change your default
GCC to a compiler that works.
That fixes the problems with -traditional-cpp v/s -no-cpp-precomp, but
it doesn't fix:
ld: Undefined symbol
_tas
eric
---(end of broadcast)---
TI
On Sep 27, 2003, at 3:43 PM, Tom Lane wrote:
Eric Ridge <[EMAIL PROTECTED]> writes:
I don't think the OS X 10.3 betas are readily available (I've payed to
be in Apple's developer program), so if you don't have access to 10.3
but have some idea as to what would cause this problem with tas, I'll
do
38 matches
Mail list logo
