), $(LIBS))
$(LDAP_LIBS_FE)
endif
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Markus Schaaf wrote:
src/interfaces/libpq/Makefile is missing a reference to libgssapi.
The problem occurred while compiling 8.3.3 on NetBSD --with-gssapi,
and is still present in HEAD. A patch is attached.
Applied and backpatched to 8.3.
Thanks!
//Magnus
--
Sent via pgsql-patches mailing
Simon Riggs wrote:
On Thu, 2008-09-11 at 15:39 +0300, Peter Eisentraut wrote:
Bruce Momjian wrote:
Abhijit Menon-Sen wrote:
I thought -patches was supposed to die. What happened?
I was wondering the same thing. Peter?
Hmm, let's try this:
Anyone who thinks the patches list should remain
Peter Eisentraut wrote:
Simon Riggs wrote:
On Thu, 2008-09-11 at 15:39 +0300, Peter Eisentraut wrote:
Bruce Momjian wrote:
Abhijit Menon-Sen wrote:
I thought -patches was supposed to die. What happened?
I was wondering the same thing. Peter?
Hmm, let's try this:
Anyone who thinks
Marc, care to do the honors?
---
Peter Eisentraut wrote:
Simon Riggs wrote:
On Thu, 2008-09-11 at 15:39 +0300, Peter Eisentraut wrote:
Bruce Momjian wrote:
Abhijit Menon-Sen wrote:
I thought -patches was supposed
, Peter Eisentraut wrote:
Bruce Momjian wrote:
Abhijit Menon-Sen wrote:
I thought -patches was supposed to die. What happened?
I was wondering the same thing. Peter?
Hmm, let's try this:
Anyone who thinks the patches list should remain as separate
from hackers, shout now
Bruce Momjian wrote:
Marc, care to do the honors?
Note:
1. there are several lists to kill, not just pgsql-patches. The
database says:
pgsql-chat
pgsql-benchmarks
pgsql-hackers-win32
pgsql-hackers-pitr
pgsql-cygwin
pgsql-ports
2. The archives must, obviously, survive the kill
on production
servers, I have to ask : what about the compatibility of this patch in
8.3.4 ?
We use patches to build the next releases of PostgreSQL. We don't make
any attempt to maintain past patches as current so that people can apply
them to previous branches.
If you want someone to do that you
On Thu, 2008-09-11 at 15:39 +0300, Peter Eisentraut wrote:
Bruce Momjian wrote:
Abhijit Menon-Sen wrote:
I thought -patches was supposed to die. What happened?
I was wondering the same thing. Peter?
Hmm, let's try this:
Anyone who thinks the patches list should remain as separate
Hello,
Upgrade 8.3.4 is available. Before compiling, I have to apply the optimized
toast patch :
*bin7hetTGkMRL.binhttp://archives.postgresql.org/pgsql-patches/2008-02/bin7hetTGkMRL.bin
*.
There are differences in 1 of the 3 files patched : tuptoaster.c
The patch runs successfully but before
* write restart_segments value to control file
* force a restartpoint on first valid checkpoint WAL record after we
have passed restart_segments worth of log
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql
are pretty daunting. We don't really want slaves
doing that while they're in catchup mode.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
the crash, but not too much further because
we already know the whole WAL file is available.
Or is that the same thing you were saying? The detail about using
the end address seems fairly critical, and you didn't mention it...
regards, tom lane
--
Sent via pgsql-patches
Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
that an
additional write/fsync per cycle doesn't seem that big a problem to me.
There's almost certainly a few fsync-equivalents going on in the
filesystem to create and delete the retrieved segment files.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
, just didn't agree. :-)
I'll put it at one (1) and then wait for any negative perf reports. No
need to worry about things like that until later.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches
arguing about ...
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
when time to free the tuple */
vardata-freefunc = heap_freetuple;
return true;
}
and if you want to insert stats for expression indexes then there's a
separate get_index_stats_hook for that.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
will
be unreliable.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Hello all,
Just wanted to let everyone know I have committed this patch to the
PgFoundry uint project.
I have also updated the commit-fest wiki with this status.
Thanks to everyone (especially Jaime) for the feedback and reviews.
- Ryan
--
Sent via pgsql-patches mailing list (pgsql-patches
If they don't specify this, then bgwriter will not start and you cannot
run in Hot Standby mode. Their choice, so we need not worry then about
the loophole any more.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql
) \
! (vardata).freefunc((vardata).statsTuple); \
! else \
! elog(ERROR, unable to release variable stats correctly); \
! } \
} while(0)
TOM.v3.tar
Description: Unix tar archive
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
, but that will all have to be cleaned up before we dare
allow any backends to run concurrently with recovery. btree's
suppression of relcache invals for metapage updates will be a problem
too.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make
, and the
multibyte conversion functions can certainly fail. That will need to be
added.
//Magnus
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
that?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
/LC_MESSAGE_CHECK/LC_TIME_PATCH/LC_TIME_CHECK_LOCALE.sql
Regards,
Hiroshi Saito
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
this is really worth
arguing about, much less exposing a separate parameter for.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
--
Bruce
On Wed, 2008-09-24 at 12:04 -0400, Bruce Momjian wrote:
Can we consider this hash thread closed/completed?
Please
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes
TransactionIdFollows(TransactionId id1, TransactionId id2);
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
allocation
parameter; it's a switchover threshold between two different behaviors.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
that's when
the number of levels in the index is significantly less than btrees? Do
we need to optimise creation time of smaller hash indexes at all?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches
of shared_buffers then
it could still take awhile on installations with lots-o-buffers.
The other side of that coin is that it's not clear this is really worth
arguing about, much less exposing a separate parameter for.
regards, tom lane
--
Sent via pgsql-patches mailing
via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
On Mon, 2008-09-22 at 23:06 +0100, Simon Riggs wrote:
On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
Do we really need a checkpoint there at all?
Timelines only change at shutdown
On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
Do we really need a checkpoint there at all?
Timelines only change at shutdown checkpoints.
Hmm. I *think* that that is just a debugging
create_test_hash.pl
bench.pl
Description: Perl program
create_test_hash.sql
Description: Binary data
result.out
Description: Binary data
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
(machine has 8GB) its still going an hour later.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
: 487949.490 ms
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
shared_buffers as a cutoff is a much better idea as
well.
Already done in CVS a week or so back, but thanks for following up with
some confirmation.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
it.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
a need to do
that yet. In any case, tying it to maintenance_work_mem is certainly
wrong.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
: cannot cast type smallint to uint4
LINE 1: select 256::int2::uint4;
otherwise seems fine
--
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
selectivity functions
I implemented to handle the
cross-type problem? Is that what you had in mind?
Thanks!
- Ryan
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
bgwriter doesn't need to
do a dynamic state change.
Comments anyone?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
*/
PMSIGNAL_PASSWORD_CHANGE, /* pg_auth file has changed */
PMSIGNAL_WAKEN_ARCHIVER, /* send a NOTIFY signal to xlog archiver */
PMSIGNAL_ROTATE_LOGFILE, /* send SIGUSR1 to syslogger to rotate logfile */
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes
in a query-answering
slave.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
take some close investigation,
which maybe isn't warranted if you have a less-invasive solution.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
timelineid, so it can't be that risky.
Ignore v5 then and look for v6 on Monday. Hopefully the final one :-)
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
and that reporting back later today.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
--On Donnerstag, September 11, 2008 15:39:01 +0300 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Hmm, let's try this:
Anyone who thinks the patches list should remain as separate from
hackers, shout now (with rationale)!
Seems i've missed something, what's then supposed to hold patches now
Bernd Helmle wrote:
--On Donnerstag, September 11, 2008 15:39:01 +0300 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Hmm, let's try this:
Anyone who thinks the patches list should remain as separate from
hackers, shout now (with rationale)!
Seems i've missed something, what's then supposed
Bernd Helmle wrote:
--On Donnerstag, September 11, 2008 15:39:01 +0300 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Anyone who thinks the patches list should remain as separate from
hackers, shout now (with rationale)!
Seems i've missed something, what's then supposed to hold patches now?
Just
--On Mittwoch, September 17, 2008 22:37:29 +0300 Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Just send them to pgsql-hackers.
Oh, that's fine, since discussions are already moved from -patches and are
continued there. The only disadvantage i see is that -hackers is a little
more frequented
sistemas
Guayaquil - Ecuador
Cel. (593) 87171157
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
to
address properly.
I will work on better commenting the code tonight and tomorrow.
Thanks again for your review and testing!
- Ryan
uint-base-v2.tar.bz2
Description: BZip2 compressed data
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
of effective_cache_size --- any thoughts about that?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
on performance in v5 case, but result is still better than cvs head.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
with the hashint8 which just ignores the top 32 bits.
Right?
Yes, that is exactly right.
Ken
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
(v5 between 5700 and 6200). Also the query im doing
ming be two simplistic because it runs to fast, thats part of why I
get the variable speed between runs (i think...)
Suggestions?
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
otherwise identical to
existing message. I'd rather not change that.
The new message is not translatable, the original was.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-patches mailing list (pgsql
is redundant anyhow. Anybody looking
at the log can see we're in recovery. So I'll switch it back to say just
checkpoint whether we do restartpoint or checkpoints.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql
Bruce Momjian wrote:
Abhijit Menon-Sen wrote:
I thought -patches was supposed to die. What happened?
I was wondering the same thing. Peter?
Hmm, let's try this:
Anyone who thinks the patches list should remain as separate from
hackers, shout now (with rationale)!
--
Sent via pgsql
-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
;
end loop;
return true;
end;
$$ language 'plpgsql';
And then benchmark each table, and for extra credit cluster the table
on the index and benchmark that.
Also obviously with the hashint8 which just ignores the top 32 bits.
Right?
--
Sent via pgsql-patches mailing list (pgsql-patches
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
on my status.
Thanks,
- Ryan
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
archiver */
PMSIGNAL_ROTATE_LOGFILE, /* send SIGUSR1 to syslogger to rotate logfile */
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
= 5234.680407
v5: tps = 5286.08252
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
it will be a good benchmark of collision processing. Then
again you seem to have studied the hash algo closer than me. Ill go
see about doing this. Stay tuned.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
;
}
?
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
the
error with your test cases and I am working on a solution now.
Thanks!
- Ryan
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
operation is broken.
Well, the cause of that one would've been marking an operator as HASHES
without providing a hash opclass to back it up.
IIRC the test case involved ? That shouldn't even be marked HASHES
anyway ...
regards, tom lane
--
Sent via pgsql-patches mailing
() functions
was about 2 * (1/1) of what you test generated. You could just
test against the integers between 1 and 200.
Ken
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
:
drop table if exists t1_uint4;
create table t1_uint4 (f1 uint4 primary key);
insert into t1_uint4 select generate_series(1, 255);
analyze t1_uint4;
select * from t1_uint4, generate_series(1, 10) as foo where t1_uint4.f1 = foo;
Thanks,
- Ryan
--
Sent via pgsql-patches mailing list (pgsql
on doing a wide vs narrow test... sometime... :)
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
test_hash_num_idx on test_hash using hash (num);
pgbench -c1 -n -t10 -f bench_index.sql
cvs head: tps = 7345.69432
v5: tps = 7526.290462
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
more comments to the code.
Jamie: Thanks for the patches. I have applied the Makefile patch to my
local tree. I am still reviewing the regressions.diffs patch. I definitely
see the issue now, I am still reviewing to see/understand if your solution
is the proper fix. I am reviewing the main
happens in joins, unions, hash, etc... so you have to
look at those functions as well
PS: Jaime not Jamie :)
--
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157
--
Sent via pgsql-patches mailing list (pgsql-patches
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
)- \
+ (MAXALIGN(SizeOfPageHeaderData) + \
+ MAXALIGN(sizeof(HashPageOpaqueData))) )
+
+ #define HashPageGetMeta(page) \
+ ((HashMetaPage) PageGetContents(page))
+
/*
* The number of bits in an ovflpage bitmap word.
*/
--
Sent via pgsql-patches mailing list (pgsql-patches
: Jaime not Jamie :)
Sorry! I will spell your name correctly from now on!
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.
If we accept that patch, I'm okay with including this one too. Still
hoping for some performance testing though. (Note that this one isn't
going to affect performance, so no need to include it for that purpose.)
regards, tom lane
--
Sent via pgsql-patches mailing list
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
had a caveat which looked ugly and multiplied the testing. You're
the code dude, always happy to structure things as you suggest. If
you're sure, that is.
Thanks for the review.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
. Only having a lossy skip table
throws that out the window without having a special check for _
David.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
to help me figure out what I am missing!
Thanks!
- Ryan
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
t1_uint4 where f1 30;
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
: 16486
contrib_regression=# select * from t1 where f1 35::uint4;
f1
-
36
37
38
--
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
Jaime Casanova [EMAIL PROTECTED] writes:
contrib_regression=# select * from t1 where f1 35;
ERROR: unsupported type: 16486
That obviously isn't supposed to happen. Where's it coming from
exactly?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql
1 - 100 of 17787 matches
Mail list logo
