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 ago,
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
--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 ov
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, towl
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 th
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 -K
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 ha
--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 yo
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
--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,
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 specifi
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 submi
--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
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.
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
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 actu
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, Marc
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 wa
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!: yscrap
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
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 repl
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 w
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
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.
http://developer.postgresql.org/cvsweb.cgi/pgsql-serve
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 wi
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 y
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 s
--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
--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
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: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
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
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
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 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 link
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 simp
--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, whi
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]> w
--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 Wednesda
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 do
This patch incorporates a number of changes suggested by the group. The
purpose of this patch is to move postgresql to a position where all
configuration options are specified in one place. The postgresql.conf file
could completely document a postgresql environment.
It adds this functionality:
T
--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
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
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 t
Yes, this is another vain attempt to get some attention to the custom
config variables patch that I've submitted (twice) :-)
But it's also a relevant question.
Given that the design is accepted and a custom variable will use
qualified names I'd propose a change to the SQL parser so that the nam
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 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
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 re
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 #d
--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,
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 i
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
-
--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 threa
--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
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 sea
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 REA
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 tsearch
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
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
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, an
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
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
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
0.0
> [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
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
contrib.v
> 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
[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 environment-variable
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 t
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:
>
>
> > 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 a
""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 fi
> 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 s
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
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
74 matches
Mail list logo
