review the revised patch today.
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
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> I'm not sure where we go from here. Your GSOC student has disappeared,
>> right? Is anyone else willing to take up the patch and work on it?
> I'm willing to take it up and w
ike we've got the issue in front of us.
One other mistake I noted was that the version checks added in pg_dump
and psql are ">= 80300", which of course is obsolete now.
I'm not sure where we go from here. Your GSOC student has disappeared,
right? Is anyone else willing to
I wrote:
> Also, I don't think the subtransaction management is correct at all.
BTW, maybe it would make more sense to keep the reference count
management inside ResourceOwners, instead of having a largely
duplicative set of logic in snapmgr.c.
regards, tom lane
reference counts being only uint16
wide. int32 seems safer and it isn't really saving anything much.
Push/PopActiveSnap leaks the ActiveSnapshotElt.
PopActiveSnapshot should probably assert active_count > 0 before
decrementing, likewise in UnregisterSnapshot.
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
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> ... So maybe the right thing is that
>> CREATE OR REPLACE LANGUAGE can change "inessential" properties of an
>> existing language, but not the core prope
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
>>> I think the use-case for varying the WAL segment size is unrelated to
>>> performance of the master server, but would instead be concerned with
>>> adjust
Greg Smith <[EMAIL PROTECTED]> writes:
> On Sun, 4 May 2008, Tom Lane wrote:
>> Well, I tried a pgbench test similar to that one --- on smaller hardware
>> than was reported, so it was a bit smaller test case, but it should have
>> given similar results.
> ...
there
is like this:
ereport(ERROR,
( ...,
have_sqlstate ? errcode(...) : 0,
...
That is, you should evaluate all the options into local variables
and then do one normal ereport call.
* // comments are against our coding conventions.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> But it'll only be in \dT+ anyway, no?
> Not in this patch.
Hmmm ... given that a long list of enum members would bloat the output
quite a lot, I think I'd vote for putting it in \dT+.
Greg Smith <[EMAIL PROTECTED]> writes:
> On Sun, 4 May 2008, Tom Lane wrote:
>> However, I am completely unable to measure any performance improvement
>> from it. Given the possible risk of out-of-memory failures, I think the
>> patch should not be applied without some
u can't just pick a convenient-looking OID, you must use one that
the unused_oids script reports as free.
There was no check for a zero step size.
There was no documentation.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I notice that this patch adds an "Elements" column to the output of \dT,
> which will only be used by enum types. That seems rather ... cluttered.
But it'll only be in \dT+ anyway, no?
regards, t
e last *successful* load of postgresql.conf", which I think is more
useful than "the last attempted load".
I also improved the documentation a bit and added the copy step needed
in restore_backend_variables().
regards, tom lane
--
Sent via pgsql-
low embedded nulls to go by. And lastly, quite a few of those
changes were just plain broken, eg several places in selfuncs.c where
you allowed strlen() to be applied to a "bytea converted to cstring".
regards, tom lane
--
Sent via pgsql-patches mailing
me direct proof of performance
benefits, and I don't see any.
regards, tom lane
Index: src/backend/storage/buffer/bufmgr.c
===
RCS file: /cvsroot/pgsql/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.228
d
bably not
wired into too many people's brains anymore. (Besides, some of us
remember it as octal 12, anyway...)
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
atible declarations. Put those externs in
keywords.h instead. I suspect you have ignored a compiler warning
about not declaring pg_get_keywords itself, too --- it should be
extern'd in builtins.h.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
t all, much less document it
incorrectly, and you forgot the "reserved" case, and "stribg"?
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
inessential" properties of an
existing language, but not the core properties --- which might only be
the handler function, though you could make a case for the validator and
the trusted flag as well.
regards, tom lane
--
Sent via pgsql-patches mailing list (pg
omatically.
> Yeah, maybe. Let's fix the issue pg_config.h.win32 that Tom raised first.
+1 for both. We really need to eliminate as much redundancy as we can
between the two build systems, because it'll keep biting us until we do.
regards, tom lane
--
Sent
d be concerned with
adjusting the granularity of WAL log shipping.
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
es. I doubt anyone would
bother distinguishing the different types of partially/wholly reserved
words. So maybe a boolean would be sufficient --- but I have nothing
against the R/T/C/U suggestion.
A more radical alternative is just to omit unreserved words from the
view altogether.
rows a sane error ...
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
g_dump wants to
generate output that is correct for its own PG version, not that of the
server it's dumping from.
The tradeoffs are probably different for pgAdmin, but it is important to
realize that either way might be the best thing for a particular case.
regards, tom
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> This patch allows dynamic queries in RETURN QUERY statement.
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg01180.php
Applied, thanks.
regards, tom lane
--
Sent via pgsql-patches maili
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This doesn't look quite right; unless the arithmetic is being done in
>> floating point? I had it like this in configure.in:
>>
>> RELSEG_SIZE=`expr '(' 1024 '*' ${se
nce
and inject its value into the comparisons using CaseTestExpr,
the same way the core CASE-expression code works?
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
ook quite right; unless the arithmetic is being done in
floating point? I had it like this in configure.in:
RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
Also it looks like you missed adding segsize to the config.pl comments.
r).
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
"Hell, Robert" <[EMAIL PROTECTED]> writes:
> You're right - that's just a typo in the subject of the post.
> It's called cursor_tuple_fraction in the submitted patch.
Ah, I hadn't actually read the patch yet ;-). As penance for the noise,
I will do so
Simon Riggs <[EMAIL PROTECTED]> writes:
> OK, if that's the view then the patch is ready for commit, AFAICS.
Use of the plural in the name seems a bit odd to me. Anyone have a
problem with calling it "cursor_tuple_fraction" instead?
regards, tom
as well.
It's not totally clear what the allowed ranges of the settings should
be. The method of using a shell "case" to verify the setting validity
is kinda klugy, but I couldn't offhand think of a direct test for
"is this a power of 2" at the shell level, so it seems w
IZE be
configurable as well. Thoughts?
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
this as being basically another cost parameter, and as such
I don't think it needs more documentation than any of those have.
(Now admittedly you could argue that they could all use a ton more
documentation than they now have, but it's not reasonable to insist
on just this one meeti
has your testing shown any
indication that they really ought to be separately configurable?
I could see having the same configure switch set both of 'em.
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
SZ is marginal already, and I've seen none at all for
varying XLOG_BLCKSZ. Why do we need to make it easier than "edit
pg_config_manual.h"?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscr
onfigure do the arithmetic and emit an integer.
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
tput, mainly because they aren't
helpful unless you still have the original query string laying 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
the assumption that there would never again be more than one
field.
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
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> They're logically different things, and after I get done putting a parse
>> location field into A_Const, they'll still be physically different too.
> Aha. Are you working from Brendan's
ace
> it with Value? After this patch, I don't see what's the difference.
They're logically different things, and after I get done putting a parse
location field into A_Const, they'll still be physically different too.
regards, tom lane
--
Sent
equire it then you need to find another way.
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
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If you actually want the behavior you propose, then the only correct way
>> to implement it is to embed it into the state machine logic, ie, do the
>> CancelBackup inside PostmasterStateMachine in
or each expression it evaluates, whether
or not there's any visible database access. As of 8.3 that won't
cause consumption of CIDs, but before it did. I suspect that in a
lot of real-world scenarios, CID consumption from triggers will be
down by an order of magnitude.
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> That should work, but isn't it better if backup_label is removed
> only if we know we're going to shutdown cleanly?
Why? That seems like an entirely arbitrary specification.
regards, tom
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So, is this a feature we want?
I have no objection to being able to use Sun Studio, but the submitted
patch seemed to need a lot of work yet ...
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsq
COLUMN ... DEFAULT/NOT NULL in 8.0.
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
code beautification, not a bug-fix, and
shouldn't be back-patched (particularly in view of the fact that we
haven't tested the change all that much --- there might be other
places depending on the old behavior).
Will take care of this.
regards, tom lane
--
Se
oid the extra complexity, at least till such
time as we see whether there are still any real field complaints about
this with 8.3.
In any case the patch is broken by --enable-float8-byval, and would
need some adjustments to play nice with that.
regards, tom lane
--
Sent v
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why not? It'll fall out of the state again immediately in
>> PostmasterStateMachine, no, if we do a CancelBackup here?
> We cannot call CancelBackup there because that's exactly the s
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Lastly, the changes to pmdie's SIGINT handling seem quite bogus.
>> Don't you need to transition into WAIT_BACKUP rather than WAIT_BACKENDS
>> state in that case too? Shouldn't yo
sunderstood that
> recommendation earlier, or if it still holds?
Oh, yes, "could not" is better. My mistake.
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
T_BACKUP rather than WAIT_BACKENDS
state in that case too? Shouldn't you do CancelBackup *before*
PostmasterStateMachine? The thing screams of race conditions.
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
n placing them in
general-purpose memory contexts.
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
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> On Mon, Apr 21, 2008 at 2:28 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Applied with revisions --- mostly, supporting configure-time control
>> over whether pass-by-value is used.
> Do we need buildfarm cove
ULE_MAGIC_DATA.
Very good point, especially now that it's configurable. Included
in committed patch.
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
rol
over whether pass-by-value is used.
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
e function used when not FLOAT8PASSBYVAL. Not clear how
useful that really is though.
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
Tom Lane <[EMAIL PROTECTED]> writes:
> BTW, I trolled the contrib files for other v0 functions taking or
> returning float4 or float8. I found seg_size (fixed it) and a whole
> bunch of functions in earthdistance.
Hmm, actually most of the "bunch" are SQL functions, th
ould do about this is add a variant expected file
with the hu_HU sort ordering. I'd be happy to do that if it were
affecting the main regression tests, but not sure it's worth it for
contrib/tsearch2 ... thoughts?
regards, tom lane
--
Sent via pgsql-
oat4byval to be selectable) over this weekend.
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
consider applying the other part of the
patch.
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
Gregory Stark <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Specifically, I think what you missed is that on some platforms C
>>> functions pass or return float values differently from similar-sized
>>> integer or pointer values (typically, the float
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Both --enable and --disable-float4-byval produced only this regression,
> but it seems to be a tuple order difference.
That looks suspiciously locale-ish; what locale are you running PG in?
regards, tom lane
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I was wondering about that too, once it became obvious that (almost?)
>> everything was failing not just some platforms. However, this
>> afternoon's CVS HEAD *does* pass the seg regression test for
Gregory Stark <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Specifically, I think what you missed is that on some platforms C
>>> functions pass or return float values differently from similar-sized
>>> integer or pointer values (typically, the float
Tom Lane <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Since they're v0, they'd have to explicitly know about the pass-by-ref
>>> status of float4.
>> Well, the previous code w
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Since they're v0, they'd have to explicitly know about the pass-by-ref
>> status of float4.
> Well, the previous code was doing some pallocs, and the new code is not:
> http://anoncvs.postgr
loat4.
Did this patch include a compile-time choice of whether things could
remain pass-by-ref? I rather imagine that some people out there will
prefer to stay that way instead of fix their old v0 code.
In the meantime, converting contrib/seg to v1 might be the best
solution.
$REGRESSION_DURATION / 32767`
Uh, where's the randomness coming from?
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
ly zero complaints. It's going to take one hell of a
strong argument to persuade me that determination of the horizontal
dimension should not work exactly the same way.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To mak
h to affect the
output to a file at all.
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
ms like a good idea now that psql deals nicely with multiline output.
The function names in the patch need schema-qualification in case
pg_catalog is not first in the search path.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To
here we stand on the above. To cast, or not to cast?
I dunno. I know there was previously some handwaving about representing
XML values in some more intelligent fashion than a plain text string,
but I have no idea if anyone is likely to do anything about it in the
foreseeable future.
ouched any contrib code, but
>> as far as the main backend goes I think it's ready to apply.
> Patch to all contrib modules:
> http://www.sigaev.ru/misc/contrib.patch.gz
Ooops, we duplicated work :-(. Will compare with your version before
applying.
regards,
g it, and very possibly
fat-fingered the indentation --- I don't recall having explicitly
compared it to the other cases. It surely should be consistent with
everything else.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.or
y contrib code, but
as far as the main backend goes I think it's ready to apply.
regards, tom lane
binI2STY1wRy8.bin
Description: run-time-recheck-1.patch.gz
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscriptio
pretty skeptical about the adequacy of the asm parameters,
though.
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
Gavin Sherry <[EMAIL PROTECTED]> writes:
>> might as well just use PG_RETURN_DATUM instead of casting twice.
> Oh of course. Updated patch attached.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
to accomplish by making it wider on 32-bitters?
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
hing to fix. I think though that the cases
like this:
> ! PG_RETURN_TEXT_P(DatumGetPointer(result));
might as well just use PG_RETURN_DATUM instead of casting twice.
Was this just eyeball inspection or did you find a compiler that would
complain about this?
regards,
gt;> can exit cleanly.
> I have implemented this idea with the attached patch.
It was already explained to you why this is a bad idea.
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
me" concept
seems utterly useless, and what *is* needed is missing: every callback
function needs a pass-through void * pointer so that it can get at
private state.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make cha
x27;s foolish to try to prevent them all. And
bloating one line of code into five or more lines to defend against
can't-happen cases is a good way to end up with unreadable,
unmaintainable software.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-pa
ugh silently if handed a null pointer? I think a crash in
such a case is what we *want*. Silently not locking is surely
not very safe.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www
e use stat() in any place where it's really gonna
matter much ...
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
uft in include/port.h, and put it in include/port/win32.h instead?
Seems cleaner that way, at least for things where there's just an
#ifdef WIN32 hunk and not two cases for Win and not-Win.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@post
way to #undef only the parametrized version.
I don't follow ... there's no such redefinition in our code AFAICS.
Do you mean that the system header files declare it as a macro?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgr
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Ick.
> The reason not to do so was to avoid having to do the two filesystem
> calls for *every* stat, instead just calling them both when we actually
> need to use the st_size member.
I don't th
ve to
override broken Windows syscalls, that is put something like
#define stat(...) pgwin32_stat(...)
into the win32 port header file, so the calls don't have to be
nonstandard.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postg
ts.
You can spend a week inventing some complicated method, and the patch
will be rejected because it adds too much overhead. Anything we do here
has to be cheap enough that no one will object to having it turned on
all the time --- else it'll be useless exactly when they need it.
o be some added effort to
maintain the commit fest queue. Bruce has made it pretty clear
that he doesn't want to put in any extra cycles here. So someone
else has to step up to the plate if this is going to work.
Any volunteers out there?
regards, tom lane
--
Sent via
at new work would
trigger an entry being made in the pending-commit-fest list.)
I've surely got no objection to you hanging on to such threads in your
personal almost-TODO list, and prodding people when appropriate. But
the commit fest queue is not for that purpose.
regar
t I'm not going to be pleased to see those same
threads in the fest queue next time, unless someone's done some actual
work in between.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
ies, I agree it's
harder, but it's still possible. I seem to recall some discussion of
including a low-overhead progress counter of some kind in the
pg_stat_activity state exposed by a backend. The number of rows so far
processed by execMain.c in the current query might do for the
defi
lve his problem
better, especially since he'd not have to abort and restart the long
query to find out if it's making progress. It'd help if pgstattuple
were smarter about "dead" vs uncommitted tuples, though.
regards, tom lane
--
Sent via p
done "#ifdef gcc"
inlines in one or two places where the performance argument for adding
such clutter was compelling. We can do that some more, but you'll need
equally compelling arguments. Do not bother submitting patches to
create a very large number of inlines.
e table would be fine.
I still like the idea of uninstall being just a "DROP MODULE" with
subsequent cascading. If you want to argue that that isn't sufficient
you really need a pretty convincing example why not.
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
ge that this is an issue
for some folk, and that a real solution would be welcomed.
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
201 - 300 of 4175 matches
Mail list logo
