Did you guys find any solution to this in the end?
Chris
Oleg Bartunov wrote:
Thanks Christopher,
we'll look into the issue.
Oleg
On Fri, 7 May 2004, Christopher Kings-Lynne wrote:
I have a table with a tsearch2 index on it. Now, I have all the
tsearch2 stuff installed into a
On Wed, 2004-05-12 at 04:47, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think this argument is largely a red herring ... but if it makes you
feel better, we could change the contents of the commit timestamp to
be gettimeofday()
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Should we be thinking about a 7.4.3?
I'm not panicking over this particular bug ... but it does seem like
we've accumulated enough fixes since 7.4.2 that it may be time to start
thinking about another dot-release. Maybe set a date
This is what I currently have:
#if (CATALOG_VERSION_NO = 200211021)
#define PG_VERSION_73_COMPAT
#elif (CATALOG_VERSION_NO = 200310211)
#define PG_VERSION_74_COMPAT
#else
#define PG_VERSION_75_COMPAT
#endif
Since CATALOG_VERSION_NO doesn't change between major releases, it seems
to
Greg Sabino Mullane [EMAIL PROTECTED] wrote in message
DBD::Pg uses pg_config --version and parses the output to set the
version information before compiling. It finds pg_config by using
PG envrironment variables, or looks in the path. Once running, it
does a SELECT version() to find out what
I think this argument is largely a red herring ... but if it makes you
feel better, we could change the contents of the commit timestamp to
be gettimeofday() output (seconds+microseconds) instead of just time()
output. That should be precise enough for practical purposes.
I am saying
On Wed, 12 May 2004, Christopher Kings-Lynne wrote:
Did you guys find any solution to this in the end?
Not yet. Could you send me a simple test suite ? I'm not
experienced with schema and don't know how to load tsearch2 into
specific schema.
Oleg
Chris
Oleg Bartunov wrote:
Christopher, I don't quite understand the problem
Did you move pg_ts_* table to schema 'contrib' ?
What functions you schema-qualified and how ?
It's always required to set search_path properly.
Oleg
On Wed, 12 May 2004, Christopher Kings-Lynne wrote:
Did you guys find any solution to this in
[EMAIL PROTECTED] writes:
They say the absolute path is a security issue, I honestly don't see how
Because it allows someone with only CREATEDB privilege to tell the
backend to write anywhere (that it can write). That's an ability
that should be reserved to superusers.
The
Joe Conway wrote:
#if (CATALOG_VERSION_NO = 200211021)
#define PG_VERSION_73_COMPAT
Since CATALOG_VERSION_NO doesn't change between major releases, it seems
to work pretty well.
That approach also has the nice property that it already works for all
releases back to 7.0, whereas anything we
OK, I'll try to explain it better.
1. Tsearch2 requires access to several tables.
2. You can edit the tsearch2.sql script and change the set schema =
... to contrib.
3. You load all the tsearch2 objects into contrib.
4. You create a table in the public schema with a column of type
[EMAIL PROTECTED] writes:
They say the absolute path is a security issue, I honestly don't see how
Because it allows someone with only CREATEDB privilege to tell the
backend to write anywhere (that it can write). That's an ability
that should be reserved to superusers.
I guess I can see
I ran the new Pgpool-1.2.2 and it was a bit faster on
the TCP but still slower than on UNIX socket. I used
the same script as before.
TCP Socket (Pgpool 1.2.0)
--
2.39 sec
TCP Socket (Pgpool 1.2.2)
--
0.80 sec
0.80 sec
0.79 sec
UNIX Socket (Pgpool 1.2.2)
---
0.026 sec
Christopher,
On Wed, 12 May 2004, Christopher Kings-Lynne wrote:
OK, I'll try to explain it better.
1. Tsearch2 requires access to several tables.
2. You can edit the tsearch2.sql script and change the set schema =
... to contrib.
Aha, this is what I thought about.
3. You load all the
6. However, it is now not possible to restore the sql script as it was
dumped, as you get this error:
ERROR: relation pg_ts_cfg does not exist
No problem,
[EMAIL PROTECTED]:~/app/pgsql/tsearch2/test_scheme$ createdb qq
CREATE DATABASE
[EMAIL PROTECTED]:~/app/pgsql/tsearch2/test_scheme$ psql
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
Has any other platform come up with a need to look for the real pthread_*
calls from libpq?
I would REALLY like us to support threaded programs in UnixWare,
Christopher,
here is a cut'n paste from test script (patch applied):
dropdb qq
createdb qq
psql qq -c create schema contrib;
psql qq tsearch2_contrib-2.sql
psql qq -c create table test ( a text, fts contrib.tsvector);
psql qq -c insert into test(a) values ('I hit a dog');
psql qq -c set
No problem,
Actually, I did some more testing and I properly understand the problem
now - and it won't happen in the general restoring case.
What fails is if you pg_dump -a to just dump the DATA from a table
containing a tsearch2 trigger that is in a different schema.
Then you delete all the
On Wed, 12 May 2004, Christopher Kings-Lynne wrote:
No problem,
Actually, I did some more testing and I properly understand the problem
now - and it won't happen in the general restoring case.
What fails is if you pg_dump -a to just dump the DATA from a table
containing a tsearch2 trigger
On Wed, 12 May 2004, Larry Rosenman wrote:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
Has any other platform come up with a need to look for the real pthread_*
calls from libpq?
I would REALLY
Oleg Bartunov [EMAIL PROTECTED] writes:
Hmm, what other hackers thinks ? This is not just a tsearch2 problem,
it could happens with any such kind of things, like defining user defined
type in one scheme, using it in another, dumping separate data.
Could pg_dump be enough smart to set
--On Wednesday, May 12, 2004 12:57:10 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
Has any other platform
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
In what way does the current thread
Larry Rosenman [EMAIL PROTECTED] writes:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
In what way does the current thread stuff not work for you?
regards, tom lane
Larry Rosenman [EMAIL PROTECTED] writes:
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane [EMAIL PROTECTED]
In what way does the current thread stuff not work for you?
In the initdb compile:
Undefined first referenced
symbol in file
--On Wednesday, May 12, 2004 14:14:30 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and if
they are NOT there,
On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and if
they are NOT there, use fake functions that assume we are NOT threaded.
Wouldn't it be easier to have a
Shachar Shemesh [EMAIL PROTECTED] writes:
Also, if we want greater flexibility in handling these cases in the future, we
should set up an invite-only list for reporting security bugs, and advertise it
on the web site as the place to report security issues. Had this vulnerability
been
--On Wednesday, May 12, 2004 13:18:35 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane [EMAIL PROTECTED]
In what way does the current thread stuff not work for you?
In the initdb compile:
Undefined
Neil Conway [EMAIL PROTECTED] writes:
The historical origins of the feature are no excuse for its
deficiencies.
On the other hand, the alleged deficiencies are not bad enough to
justify making non-backwards-compatible changes. If we were getting
routine complaints from the field I might be
On Wed, May 12, 2004 at 10:46:00 +0300,
Shachar Shemesh [EMAIL PROTECTED] wrote:
Industry practices dictate that we do issue SOMETHING now. The bug is
now public, and can be exploited.
The description of the problem indicates that it can only be exploited
after you have authenticated to the
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via
--On Wednesday, May 12, 2004 15:02:30 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG
Greg Stark [EMAIL PROTECTED] writes:
Shachar Shemesh [EMAIL PROTECTED] writes:
Also, if we want greater flexibility in handling these cases in the future, we
should set up an invite-only list for reporting security bugs,
A lot of people would be unhappy with that approach. A) they don't know
--On Wednesday, May 12, 2004 15:39:34 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:02:30 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:02:30 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May
--On Wednesday, May 12, 2004 15:59:19 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was
On Wed, 12 May 2004, Larry Rosenman wrote:
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.
deemed unacceptable by whom? Sounds to me alot simpler of a
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
This is the whole discussion we had back in January/February about
forcing -Kpthread for *ALL* libpq using programs, or dynamically
determining if the image already is linked
Larry Rosenman [EMAIL PROTECTED] writes:
This is the whole discussion we had back in January/February about forcing
-Kpthread for *ALL* libpq using programs, or dynamically determining
if the image already is linked -Kpthread, or not supporting threads
at all on UW.
Oh, that business :-(.
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:59:19 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using
Larry Rosenman [EMAIL PROTECTED] writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane [EMAIL PROTECTED]=20
wrote:
At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane
[EMAIL PROTECTED]=20 wrote:
At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a
Larry Rosenman [EMAIL PROTECTED] writes:
I was thinking of pq_pthread_* calls, and that function would
set a static flag for calling either the real pthread_* function
or a statically named version in libpgport.a that is a single thread
wrapper.
And how will you avoid having a link-time
--On Wednesday, May 12, 2004 16:22:58 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I was thinking of pq_pthread_* calls, and that function would
set a static flag for calling either the real pthread_* function
or a statically named version in libpgport.a
--On Wednesday, May 12, 2004 17:29:30 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
--On Wednesday, May 12, 2004 15:39:54
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane
[EMAIL PROTECTED]=20 wrote:
At this point I'd settle for saying that
Bruno Wolff III wrote:
On Wed, May 12, 2004 at 10:46:00 +0300,
Shachar Shemesh [EMAIL PROTECTED] wrote:
Industry practices dictate that we do issue SOMETHING now. The bug is
now public, and can be exploited.
The description of the problem indicates that it can only be exploited
after
Gregory Stark wrote:
This patch also looks relevant to Postgres for two reasons.
This part seems like it might expose some bugs that otherwise might have
remained hidden:
This affects I/O scheduling potentially quite significantly. It is no
longer the case that the kernel
Shachar Shemesh [EMAIL PROTECTED] writes:
Ok. How about an official patch against 7.4.2 that fixes it, so that
packagers can make their own informed decision.
The official patch is available to anyone who wants it from our CVS
server.
On Wed, May 12, 2004 at 23:36:49 +0300,
Shachar Shemesh [EMAIL PROTECTED] wrote:
My take on this is different. To me, a DoS is a nuisance, but an
arbitrary code execution vulnerability means information leak, and a
major escalation (from which further escalation may be possible).
A DOS
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
Also, has anybody checked what other versions are affected?
Nothing before 7.4, at least by the known implications of this issue.
Again, if we wait a while and let Ken keep running his analysis tool,
he might turn up other stuff we
Manfred Spraul [EMAIL PROTECTED] writes:
But the change highlights one point: the order in which file blocks are
written to disk is undefined. Theoretically the wal checkpoint record
could be on the platter, but the preceeding pages were not written.
Is that case handled by the wal replay
On Wed, 12 May 2004, Larry Rosenman wrote:
k, a change that 'sucks', vs linking against -Kpthread ... I'm for the
-Kpthread route myself, which still sounds the 'clean' solution ...
that was rejected back in Jan-Mar.
BUT, I agree it would work.
I tried to submit the patch, and it was
On Wed, 12 May 2004, Jan Wieck wrote:
Can we please make move all replication software out of the release an
official open item for the 7.5 release?
Agreed ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy
Larry Rosenman [EMAIL PROTECTED] writes:
Please save us all time searching by providing a URL ...
I can't find my posts on archives.postgresql.org, but can find it in
MY archives.
Well, then we won't be able to find 'em either, so please repost.
This is heading down the same path I was back
This is a re-post, and still the state of things.
There were a few posts after this because of my STRENUOUS objection below.
I still think we should enable threads somehow on this platform.
--On Monday, March 22, 2004 11:14:59 -0600 Larry Rosenman [EMAIL PROTECTED]
wrote:
--On Monday, March
On Thu, May 13, 2004 at 00:54:19 +0300,
Shachar Shemesh [EMAIL PROTECTED] wrote:
I'm sorry. Maybe it's spending too many years in the security industry
(I've been Check Point's oh my god we have a security problem process
manager for over two years). Maybe it's knowing how to actually
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Please save us all time searching by providing a URL ...
I can't find my posts on archives.postgresql.org, but can find it in
MY archives.
Well, then we won't be able to find 'em either, so please repost.
This is heading down
I don't see a patch in here ... forget to attach it?
On Wed, 12 May 2004, Larry Rosenman wrote:
This is a re-post, and still the state of things.
There were a few posts after this because of my STRENUOUS objection below.
I still think we should enable threads somehow on this platform.
--On Wednesday, May 12, 2004 22:14:33 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
I don't see a patch in here ... forget to attach it?
It was way back in the thread, and this was the upshot of the discussion.
See the note I just replied to Bruce with.
LER
--
Larry Rosenman
Hi Thomas,
Please don't get too disheartened that a developer hasn't commented on
your stuff yet. Everyone's very busy at the moment. Just hang in there!
Chris
Thomas Hallgren wrote:
Yes, this is another vain attempt to get some attention to the custom
config variables patch that I've
It could not. I think the fundamental point here is that it is a real
bad idea for the tsearch routines to make any assumptions about the
current search path. What I would suggest is that the internal objects
used by the tsearch routines (such as pg_ts_cfg) should be required to
live in a
--On Wednesday, May 12, 2004 21:08:25 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Please save us all time searching by providing a URL ...
I can't find my posts on archives.postgresql.org, but can find it in
MY archives.
Well, then
Larry Rosenman wrote:
[ Sorry I have been away from email today. ]
Larry, now that I have put the thread testing into configure, I am ready
to deal with Unixware. In fact I posted to the list asking you about it
but was too lazy to look up your email address.
Anyway, I think the
--On Wednesday, May 12, 2004 21:55:40 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
[ Sorry I have been away from email today. ]
Larry, now that I have put the thread testing into configure, I am
ready to deal with Unixware. In fact I posted to the list asking you
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
2. When an object foo is called and needs to refer to another object
bar, it should assume that bar exists in the same schema as foo, and NOT
in the current search_path.
That would be great if a C function could find out what schema it had
Larry Rosenman wrote:
Yes, there would still be the overhead, because the functions that
libthread wraps would go through that overhead since libthread does it's
magic at _ini time.
Y'all were concerned with overhead in previous discussions.
If you want to link the backend with
That would be great if a C function could find out what schema it had
been declared in, but I don't think it can readily do so.
There's no context information available to it at all? Even if you go
contrib.tsearch2 qualfication?
How about making it so that the default context for functions is
I got tired of reading complaints about how upper/lower don't work with
Unicode, so I went and prototyped a solution. The attached code uses
the C99-standard functions mbstowcs and wcstombs to convert to and from
a wchar_t[] representation that can be fed to the also-C99 functions
towupper,
--On Wednesday, May 12, 2004 22:26:03 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
Yes, there would still be the overhead, because the functions that
libthread wraps would go through that overhead since libthread does it's
magic at _ini time.
Y'all were concerned with
Hackers,
I'm stuck trying to figure out how to decrease reference counting for
relcache entries at subtransaction abort.
Initially I thought I could just drop them all to zero, because a
subtransaction boundary should be enough warranty that the entries are
no longer needed. However I now think
A couple of months back, in order to deal with a client that was being
DDoS'd, we setup an 'offsite' server that we have about 1.4TB of bandwidth
into ... the machine itself isn't super powerful, but we also have very
very little on it ...
We moved bittorrent and ftp over to it about a month
73 matches
Mail list logo
