l lock on t_unit, which
is blocking whatever the "update t_unit_status_log" command wants to do
with t_unit. Looks like a classic lock-strength-upgrade mistake to me.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
adlock error, there
should be more information about it in the postmaster log.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ttps://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
fix.
It's probably making some progress but not much. You need to fix that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
tself certainly does no such thing. Maybe it's being done in
some wrapper script you're using?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the whole, though, it's starting to sound like that system has
got major problems. You'd be well advised to focus all your efforts
on getting a valid dump, not bringing it back into production.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-gene
REINDEX on whatever table equates to
> "base/1029860192/1029863651"? If so how do I determine the db and table
> for "base/1029860192/1029863651"?
1029860192 is the OID of the database's pg_database row.
1029863651 is the relfilenode in the relation's pg_class row.
efault privileges that
exist in the *current* database. You need to do DROP OWNED BY
in that database (and maybe other ones, but start there).
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.p
ped because some objects depend on it
> DETAIL: privileges for default privileges on new types belonging to role
> role_main
See DROP OWNED BY.
https://www.postgresql.org/docs/9.6/static/role-removal.html
regards, tom lane
--
Sent via pgsql-general mailing list (
tallation. Or maybe the bad value for
TCLSH is somehow causing this, though I'm not sure how.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ble Python. Looking into config.log to see what the stderr
output of this test was might be informative.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
generated.)
> configure: error: Perl not found
> Why does it say, "Perl version 5.8 or later is required, but this is ."?
It's trying to extract the Perl version number from the output of
"perl -v", and evidently failing to find one. What does "perl -v"
pri
other databases. See
https://www.postgresql.org/docs/9.6/static/role-removal.html
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Simon Riggs <si...@2ndquadrant.com> writes:
> On 18 October 2016 at 19:34, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> If you don't want to have an implicit bias towards earlier blocks,
>> I don't think that either standard tablesample method is really what
>
the rows it grabs will be consecutive.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Thomas Kellerer <spam_ea...@gmx.net> writes:
> Tom Lane schrieb am 18.10.2016 um 15:20:
>> Personally, I'd try looking in pg_depend to see if the column's default
>> expression has a dependency on a relation of type sequence. That avoids
>> all the fun of parsi
> parser of our own will do? Googling found no candidates.
Personally, I'd try looking in pg_depend to see if the column's default
expression has a dependency on a relation of type sequence. That avoids
all the fun of parsing the expression and turns it into a simple SQL
join problem.
Sebastian Luque <splu...@gmail.com> writes:
> Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Are you in a position to apply patches? It's a one-line fix:
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dca25c2562199ce1e7e26367613912a8eadbbde8
> I'd
g file might offer some insight as to
why the server's not running.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
aster, and I'd tend to believe that over any other evidence.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
execution. Use the || operator instead.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e size,
but I've not heard that mmap() might succeed and then munmap() fail.
That seems like what's happening to you though.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s to specify that it wants to log in as mailman,
and likewise mattermost needs to specify mmuser.
If it's not practical to make the client applications send non-default
user names, you'll need to rename the Postgres roles to match the
external user names.
regards, tom lane
licit about the fact that the implied CTE just
has the base name of the view; but since CTE names can't be qualified,
that's not that hard to guess. Short answer is that you don't qualify the
view's internal self-reference, even if you are using a schema name in the
CREATE.
Andres Freund <and...@anarazel.de> writes:
> On 2016-10-10 18:21:48 -0400, Tom Lane wrote:
>> Chris Richards <ch...@infinite.io> writes:
>>> LOG: munmap(0x7fff8000) failed: Invalid argument
>> [ digs in code... ] One theory is that PGSharedMemoryDetach
sely? What nondefault settings
have you got in postgresql.conf?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
if the postmaster weren't already expecting the
children to die, it would have reacted differently.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
anything but Postgres.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e Linux OOM killer
has decided to target some database process. You need to do something to
reduce memory pressure and/or disable memory overcommit so that that
doesn't happen.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To ma
"Sebastian P. Luque" <splu...@gmail.com> writes:
> Tom Lane <t...@sss.pgh.pa.us> wrote:
>> On closer inspection, the error is only in the
>> aggregate-used-as-window-function case, not plain aggregation.
> Yes, I see the same phenomenon. Could someone su
Adrian Klaver <adrian.kla...@aklaver.com> writes:
> On 10/09/2016 08:46 AM, Tom Lane wrote:
>> Clearly a bug --- the wrong type OIDs are being passed down to
>> array_append. It should be told that it's getting called as
> For my edification, why does this work?:
On clos
de in the
aggregate/windowfunction area. Possibly me :-(. Haven't found
exactly where things are going off the rails, but it's clearly
a PG bug. Thanks for the report!
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes t
g
in the community git repo.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ere the table doesn't exist.
Is there more DDL going on that you have not shown us?
regards, tom lane
[1] at least, since PG 9.2 or thereabouts.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Darren Lafreniere wrote:
>> We found a pgsql-hackers thread from about a year ago about optimizing
>> ORDER BY for BRIN indexes. Tom Lane suggested that he was working on it:
>> https://www.postgresql.org/
rns out to be,
it might be something we choose to fix only in HEAD.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Num. It should be showing you
something like "16MB" in the unit column, I think.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
g_constraint WHERE conrelid = 'js_activity_20110101'::regclass;
and likewise for the parent table.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Benedikt Grundmann <bgrundm...@janestreet.com> writes:
> On 3 October 2016 at 14:12, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> You're going to need to manually drop that operator from the source
>> database, as "=>" isn't a legal operator name anymore. This a
e going to need to manually drop that operator from the source
database, as "=>" isn't a legal operator name anymore. This appears
to be left over from a pre-9.0 version of hstore.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
001"
> Output in psql
>
> \x4130303030303030303030303030303030303030303030303030303030303031
> is there some setting in psql output I need to take care of.
See "bytea_output" parameter.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general
Rich Shepard <rshep...@appl-ecosys.com> writes:
> On Fri, 30 Sep 2016, Tom Lane wrote:
>> Wrong permissions on /dev/shm, perhaps?
>Yes. I keep forgetting about this since I don't reboot this
> server/workstation often.
You ought to do some investigation and figur
David Rowley <david.row...@2ndquadrant.com> writes:
> On 1 October 2016 at 05:47, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Somebody will need to trace through this on Windows and see where it's
>> going off the rails.
> I tried the test case on 9.6.0 on a Windows 8.
e asking yourself is why
you're running *any* java application with root privileges, which is
what I think would be needed to let this happen.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
htt
looks platform dependent.
Somebody will need to trace through this on Windows and see where it's
going off the rails.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s just going to do pg_fatal
anyway. We should rewrite these functions to just error out internally,
which will make it much easier to provide decent error reporting
indicating which call failed.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@po
sn't garbage?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
bly that won't fly.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
happy if it runs out of WAL space. Hitting a limit
on table size per se behaves a bit more sanely, though even there you
can get into trouble --- for instance, in some situations VACUUM will
try to allocate additional disk space, making recovery harder.
regards, tom lane
-
Tom van Tilburg <tom.van.tilb...@gmail.com> writes:
> Good to know and I agree that it is not an urgent case.
> I think this practice might be more common in the POSTGIS community where
> there are plenty of set-returning-functions used in this way. My use was
> taki
client side? The most recent
related bugfix I can find in the 9.2 commit history was in libpq, and
it came out in 9.2.8.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
at stackexchange.
thanks,
Tom
On Mon, 26 Sep 2016 at 21:38 Tom Lane <t...@sss.pgh.pa.us> wrote:
> Tom van Tilburg <tom.van.tilb...@gmail.com> writes:
> > I'm often using the WHERE clause random() > 0.5 to pick a random subset
> of
> > my data. Now I noticed that wh
Tom van Tilburg <tom.van.tilb...@gmail.com> writes:
> I'm often using the WHERE clause random() > 0.5 to pick a random subset of
> my data. Now I noticed that when using a set-returning function in a
> sub-query, I either get the whole set or none (meaning that the WHERE
>
nother function to test apart from random(), but likely
there is some
-
I tested with generate_series and as well
-
My real use case works with postgis and pgpointcloud where a range of
set-returning functions is used in this manner
Thanks,
Tom
size. The latter is a PostgreSQL extension."
> Does that trick remove the overhead (length check) Tom mentioned upstream?
Partly. It should get rid of actual calls to the varchar length checking
function. There's still some distributed overhead arising from the fact
that text, not varchar, is
ALYZE'ing the partition
parent tables in your first pass, but I'm betting on the all-visible
fractions as being the issue.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
etter be one that you
can trace to crystal-clear application requirements. varchar(n) where
n has been plucked from the air is a good sign of bad database design.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make cha
literals.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
oroutine situation.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Ian Campbell <ianr...@gmail.com> writes:
> Thanks for personally replying, Tom. I appreciate it.
> You are correct. In the interim, I found the following change solved the
> issue:
> SPI_finish(); // move to here
> SRF_RETURN_DONE(funcctx);
That might work under light u
that way.
There are some other things I could criticize here, like labeling the
function IMMUTABLE when its results depend on table contents, but
they probably aren't causing your crashes.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
he GiST range opclass, but I would not be surprised if
having lots of those is pretty destructive to the index's ability to be
selective about && searches.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to yo
ould drop template0 and re-create
it from template1. Otherwise, pg_dumpall/initdb/reload would seem to be
called for. A cautious person might want to do the latter anyway in case
there's more problems than just this one.
regards, tom lane
--
Sent via pgsql-general mailing li
point, that will
take quite a while, so it's a last resort ... but it ought to work.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Jeff Janes <jeff.ja...@gmail.com> writes:
> On Tue, Sep 13, 2016 at 6:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Having said that, the amount of slop involved is only enough for a
>> few hundred lock entries. Not sure how you're managing to get to
>> nearly
any other shared structures that grow at runtime.
So there's room for the lock table to grow a bit beyond its nominal
capacity.
Having said that, the amount of slop involved is only enough for a
few hundred lock entries. Not sure how you're managing to get to
nearly 2 extra entries.
kernels (~2009) might've had issues
with setting this up wrong, but anything in current support ought to
get it right ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the
permissions on /dev/shm are bollixed?
As a temporary workaround, you could probably set
dynamic_shared_memory_type = none in postgresql.conf (I'm assuming
it's set to posix now). I do not think that disables any very
critical functionality in 9.5, but it's a hack not a solution.
';
You definitely want to reindex after the data cleanup, since presumably
it's corruption of a unique index that got you into this mess in the
first place. But as long as it's only the index and not the table that's
damaged, recovery is pretty straightforward.
regards, t
t;: 2}, {"labeltext":
> "Other", "labelvalue": 3}, {"labeltext": "Don''t know", "labelvalue": 4}],
> "target": {"place": "Sweden"}, "askfreq": "once", "whydesc": "Because I
, and that there
isn't another trigger undoing its work? (psql's \d command on the table
should show these things.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ries
from applications because they invariably drop notices on the floor.
I'd try RAISE LOG instead, and again watch the server log to see what
the application is really doing.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chan
/lib/pgq_lowlevel.so: undefined symbol: oid_hash
Looks like you built against a set of backend headers that is older than
the server you're trying to run in.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscripti
or that, it just hasn't gotten the
love the other PLs have.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ke JSON definitely has lots to recommend it --- eg, it
probably won't break when you find out your initial spec for the transport
format was too simplistic.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
other
> users');
Hm? That would be passing a timestamp not an interval.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
didn't last I heard, I might be out of date.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ct on his being
a member of PUBLIC.
IOW, revoke only revokes a previous matching grant, and there was
no such grant in this case. What there was was a grant to PUBLIC;
see the relevant bit in initdb.c:
"GRANT CREATE, USAGE ON SCHEMA public TO PUBLIC;\n\n",
s, just like you can't do
"create table foo (f1 int, f1 int)". They can be reading the same
values, though.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
rt) in ('2016-08-10')
> but it doesn't work.. I get 0 rows... what am I doing wrong?
Are you sure you're not getting an error? The query is specifying fields
in "tasks" but the FROM clause only lists "jobs".
Either one of those two cast-to-date syntaxes should work, so y
817.GO1663%40alvh.no-ip.org#20150120161817.go1...@alvh.no-ip.org
which would suggest that you're trying to build some fairly old PG version
with some fairly new C compiler. Whether that's actually the case, well,
you didn't give enough info to tell.
regards, tom lane
--
Sent via
RETURN, per se, has exactly
zero impact on the number of rows produced; it just stops execution.
I think you can say RETURNS RECORD with a few OUT parameters
to get the effect you're looking for.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@po
ly this
is indicating a problem.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ing
> against an 8.* headers.
Hm, where are you reading that? I forget when the requirement was added,
but it's certainly never been dropped.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscriptio
s ago and nothing new has been
submitted, I wouldn't hold my breath.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ound that most other browsers don't present that
message :-(
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
nd if so why? A plain old bigint
column is smaller, cheaper to index, and the natural mechanism for
generating it (ie a sequence) will tend to preserve ordering for free.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
expand the "*". The column
definition list is exactly a hack for telling it that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
line. Those are getting
taken as arguments, not quotes.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ds_games, words_moves AS
> How would you recommend to fix my declaration problem please?
I think you are looking for the RETURNS TABLE syntax.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to
ve with it or upgrade. Or I guess
you could turn off enable_hashagg when using array_agg() plus GROUP BY,
though you'd want to remember to undo that whenever you do upgrade.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
a self-contained test case?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the
postmaster with its stderr directed to a file, not to /dev/null.)
That would provide a better clue about what's eating space.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
more of the shared buffer arena. (If your
shared_buffers settings is not somewhere near 100MB, then this theory
breaks down.)
It would be worth using plain old top to watch this process. We have
enough experience with that to be pretty sure how to interpret its
numbers: "RES minus SHR"
f the same query, repeated over and over, causes memory to continue
to grow, I'd call it a leak (ie bug). If repeat executions consume
no additional memory then it's probably intentional caching behavior.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-
ould probably have helped you diagnose this. But I think the
problem is that you're required to specify a netmask or masklen;
so "127.0.0.1/32" not just "127.0.0.1".
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
urce. Or just ignore these errors.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
601 - 700 of 14105 matches
Mail list logo
