On 2014-06-03 23:37:28 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I thought the reason why this hasn't been implemented before now is
that sending an ErrorResponse to the client will result in a loss of
protocol sync.
Hmm ... you are right that this isn't as simple
On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh gurj...@singh.im wrote:
On Tue, Jun 3, 2014 at 7:57 AM, Robert Haas robertmh...@gmail.com wrote:
It seems like it would be best to try to do this at cluster startup
time, rather than once
Hi,
Following (commit 2985e16) has not been backpatched, I guess.
ANALYZE hs1;
-ERROR: cannot execute VACUUM during recovery
+ERROR: cannot execute ANALYZE during recovery
Attached is a patch for this.
--
Amit
hs-regress-expected-out-typo-fix-backpatch.patch
Description: Binary data
--
On Wed, Jun 4, 2014 at 11:50 AM, Noah Misch n...@leadboat.com wrote:
On Wed, May 28, 2014 at 08:39:32PM +1200, David Rowley wrote:
The attached patch allows join removals for both sub queries with left
joins and also semi joins where a foreign key can prove the existence of
the record.
Hi,
examine_attribute() function accept Relation type argument, and extract
attribute from it.
For more granularity, I think passing Form_pg_attribute to examine_attribute()
function rather than passing Relation will be more relevant makes it simple
to understand.
Thinking to change
Hi.
Here's a patch to make pg_xlogdump print summary statistics instead of
individual records.
By default, for each rmgr it shows the number of records, the size of
rmgr-specific records, the size of full-page images, and the combined
size. With --stats=record it shows these figures for each
On Wed, Jun 4, 2014 at 2:08 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh gurj...@singh.im wrote:
On Tue, Jun 3, 2014 at 7:57 AM, Robert Haas robertmh...@gmail.com wrote:
It seems like it would
On 2014-06-04 09:51:36 -0400, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:08 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
Incase of recovery, the shared buffers saved by this utility are
from previous shutdown which doesn't seem to be of
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an existing database, even though it would
completely misinterpret and mangle any data in pg_largeobject.
I think there ought to be a
On Wed, Jun 4, 2014 at 3:26 PM, Amit Langote amitlangot...@gmail.com wrote:
Hi,
Following (commit 2985e16) has not been backpatched, I guess.
ANALYZE hs1;
-ERROR: cannot execute VACUUM during recovery
+ERROR: cannot execute ANALYZE during recovery
Attached is a patch for this.
Why did
David Rowley dgrowle...@gmail.com writes:
On Wed, Jun 4, 2014 at 11:50 AM, Noah Misch n...@leadboat.com wrote:
When a snapshot can see modifications that queued referential integrity
triggers for some FK constraint, that constraint is not guaranteed to hold
within the snapshot until those
On 06/04/2014 10:03 AM, Tom Lane wrote:
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an existing database, even though it would
completely misinterpret and mangle any data in
amul sul sul_a...@yahoo.co.in writes:
For more granularity, I think passing Form_pg_attribute to
examine_attribute() function rather than passing Relation will be more
relevant makes it simple to understand.
I don't find that to be a good idea at all. It makes examine_attribute
On 2014-06-04 10:25:07 -0400, Andrew Dunstan wrote:
If we did an initdb-requiring change for 9.4 could we piggy-back this onto
it?
Do you know of a problem requiring that?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development,
* Andrew Dunstan (and...@dunslane.net) wrote:
On 06/04/2014 10:03 AM, Tom Lane wrote:
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an existing database, even though it would
On 06/04/2014 10:27 AM, Andres Freund wrote:
On 2014-06-04 10:25:07 -0400, Andrew Dunstan wrote:
If we did an initdb-requiring change for 9.4 could we piggy-back this onto
it?
Do you know of a problem requiring that?
No, just thinking ahead.
cheers
andrew
--
Sent via pgsql-hackers
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
On 06/04/2014 10:03 AM, Tom Lane wrote:
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop
Stephen Frost sfr...@snowman.net writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
On 06/04/2014 10:03 AM, Tom Lane wrote:
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an
On 2014-06-04 10:03:09 -0400, Tom Lane wrote:
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an existing database, even though it would
completely misinterpret and mangle any
Greetings,
I've recently discovered a peculiar problem on one of our big databases
(more than 1TB). The database has been upgraded from 9.2 to 9.3.4 (using
hardlinks to speedup the process) on April 7th around 22:00 local time.
When doing vacuum on any table, the system fails with the following
Tim Kane tim.k...@gmail.com writes:
Iâm migrating a database from 9.2.4 to 9.3.0 and encountering an issue with
an XML field failing to restore.
Hm, can you restore it into 9.2 either?
AFAICS, pg_dump has absolutely no idea that it should be worried about the
value of xmloption, despite the
Andres Freund and...@2ndquadrant.com writes:
Btw, I had wondered before if we shouldn't also add sizeof(long) to
pg_control to catch cases where a database is copied between a LLP64
(64bit windows) and an LP64 (nearly every other 64bit system) system. I
have my doubts that we're completely
On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Yeah, that is a clear advantage of that method. Didn't read up on pax
format backwards compatibility, does it have some trick to achieve
something similar?
I didn't read the
Hi,
On 2014-06-04 16:59:10 +0200, Alexey Klyukin wrote:
I've recently discovered a peculiar problem on one of our big databases
(more than 1TB). The database has been upgraded from 9.2 to 9.3.4 (using
hardlinks to speedup the process) on April 7th around 22:00 local time.
When doing vacuum
Magnus Hagander mag...@hagander.net writes:
On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another thought is we could make pg_basebackup simply skip any files that
exceed RELSEG_SIZE, on the principle that you don't really need/want
enormous log files to get copied anyhow.
On Wed, Jun 4, 2014 at 7:26 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-04 09:51:36 -0400, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:08 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
Incase of recovery, the shared buffers
Andres Freund wrote:
On 2014-06-04 16:59:10 +0200, Alexey Klyukin wrote:
I've recently discovered a peculiar problem on one of our big databases
(more than 1TB). The database has been upgraded from 9.2 to 9.3.4 (using
hardlinks to speedup the process) on April 7th around 22:00 local time.
On Tue, Jun 3, 2014 at 8:37 PM, Haribabu Kommi kommi.harib...@gmail.com
wrote:
On Wed, Jun 4, 2014 at 5:46 AM, Keith Fiske ke...@omniti.com wrote:
Andres's changes on June 3rd to
https://github.com/postgres/postgres/commits/master/src/test/regress/expected/create_function_3.out
are
Hello
updated patch - only one change: query is prefixed by QUERY:
current state:
[pavel@localhost ~]$ src/postgresql/src/bin/psql/psql postgres -q -f
data.sql
psql:data.sql:6: ERROR: value too long for type character varying(3)
Show only errors mode:
[pavel@localhost ~]$
From: Tom Lane t...@sss.pgh.pa.us
Hm, can you restore it into 9.2 either?
AFAICS, pg_dump has absolutely no idea that it should be worried about the
value of xmloption, despite the fact that that setting affects what is
considered valid XML data. What's worse, even if it were
On 6/4/14, 11:54 AM, Pavel Stehule wrote:
updated patch - only one change: query is prefixed by QUERY:
In the backend server log, this is called STATEMENT: .
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
2014-06-04 18:16 GMT+02:00 Peter Eisentraut pete...@gmx.net:
On 6/4/14, 11:54 AM, Pavel Stehule wrote:
updated patch - only one change: query is prefixed by QUERY:
In the backend server log, this is called STATEMENT: .
good idea
updated patch
Pavel
commit
On Mon, Jun 2, 2014 at 2:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
Could you let me know the link to the page explaining this?
That would even protect against another
restore on the same host.
What about the case where we restore the backup to another server and
start the recovery? In
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I've not heard one either, but there was just somebody asking in
pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
That's not a big enough sample size to make me panic about getting a
hasty fix
On Wed, Jun 4, 2014 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I've not heard one either, but there was just somebody asking in
pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
That's not a
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 4, 2014 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, just comparing the handling of TOAST_MAX_CHUNK_SIZE and LOBLKSIZE,
I noticed that the tuptoaster.c functions are reasonably paranoid about
checking that toast chunks are the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
There are at least two places in inv_api.c where we have
Assert(pagelen = LOBLKSIZE) that is protecting a subsequent memcpy
into a local variable of size LOBLKSIZE, so that the only thing standing
between us and a stack-smash security issue that's
On Wed, Jun 4, 2014 at 9:56 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-04 09:51:36 -0400, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:08 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
Incase of recovery, the shared buffers
On 2014-06-04 14:50:39 -0400, Robert Haas wrote:
The thing I was concerned about is that the system might have been in
recovery for months. What was hot at the time the base backup was
taken seems like a poor guide to what will be hot at the time of
promotion. Consider a history table, for
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
but the question is what do we do now?
Quick experimentation says that you don't really
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Of course, if we do fix this then the door opens for pushing other
initdb-forcing fixes into 9.4beta2, such as the LOBLKSIZE addition
that I
On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Of course, if we do fix this then the door opens for pushing other
initdb-forcing fixes
On Jun 4, 2014 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
but the question is what
On Fri, May 30, 2014 at 5:04 AM, Ali Akbar the.ap...@gmail.com wrote:
While developing some XML processing queries, i stumbled on an old bug
mentioned in http://wiki.postgresql.org/wiki/Todo#XML: Fix Nested or
repeated xpath() that apparently mess up namespaces.
Source of the bug is that
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
but the question is
On 2014-06-03 15:08:15 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
In 9.4. COSTS OFF for EXPLAIN prevents 'Planning time' to be
printed. Should we perhaps do the same for 'Execution time'? That'd make
it possible to use EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) in
Hi Jeff,
On 2014-05-29 09:39:56 -0700, Jeff Janes wrote:
What features in 9.4 need more beta testing for recovery?
Another thing I'd like to add to the list is wal_level=logical. Not such
much the logical decoding side, but that we haven't screwed up normal
crash recovery/wal replay.
I also
Robert Haas wrote
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane lt;
tgl@.pa
gt; wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
On 06/04/2014 03:50 PM, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of
Hi,
On 2014-06-04 14:52:35 -0400, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Agreed. Additionally I also agree with Stefan that the price of a initdb
during beta isn't that high these days.
Of course, if we do
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-04 14:52:35 -0400, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Agreed. Additionally I also agree with Stefan that the price of a initdb
during beta isn't
On Wed, Jun 4, 2014 at 9:52 PM, Andres Freund and...@2ndquadrant.com wrote:
Other things I'd like to change in that case:
Fwiw I tried to use the pg_lsn data type the other day and pretty much
immediately ran into the lack of the btree operator class. Pretty much
the first thing I did when I
On 2014-06-04 17:03:52 -0400, Tom Lane wrote:
Actually, that statement makes me realize that if we fix
PG_CONTROL_VERSION then it's a good idea to *also* do some regular catalog
changes, or at least bump catversion. Otherwise pg_upgrade won't be able to
cope with upgrading non-default
Greg Stark st...@mit.edu writes:
Fwiw I tried to use the pg_lsn data type the other day and pretty much
immediately ran into the lack of the btree operator class. Pretty much
the first thing I did when I loaded the data was select ... order by
lsn.
Agreed, now that we're going to force an
2014-06-05 2:37 GMT+07:00 Robert Haas robertmh...@gmail.com:
Please add your patch here so we don't forget about it:
https://commitfest.postgresql.org/action/commitfest_view/open
Added: https://commitfest.postgresql.org/action/patch_view?id=1461
Please see also:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
There are at least two places in inv_api.c where we have
Assert(pagelen = LOBLKSIZE) that is protecting a subsequent memcpy
into a local variable of size LOBLKSIZE, so that the only thing standing
between us and a
On 2014-06-03 10:37:53 -0400, Tom Lane wrote:
It hasn't even got a comment saying why changes here should
receive any scrutiny; moreover, it's not in a file where changes would be
likely to excite suspicion. (Probably it should be in opr_sanity, if
we're going to have such a thing at all.)
On Wed, Jun 04, 2014 at 09:16:36PM +0200, Stefan Kaltenbrunner wrote:
On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Of course, if we do
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-03 10:37:53 -0400, Tom Lane wrote:
It hasn't even got a comment saying why changes here should
receive any scrutiny; moreover, it's not in a file where changes would be
likely to excite suspicion. (Probably it should be in opr_sanity, if
2014-06-01 20:48 GMT+07:00 Marc Mamin m.ma...@intershop.de:
On Sat, May 31, 2014 at 12:31 AM, Marc Mamin m.ma...@intershop.de wrote:
I have patched intarray with 3 additional functions in order to
count[distinct] event IDs
into arrays, whereas the array position correspond to the integer
Hi,
On 2014-06-04 10:37:48 +1000, Haribabu Kommi wrote:
Thanks for the test. Patch is re-based to the latest head.
Did you look at the source of the conflict? Did you intentionally mark
the functions as leakproof and reviewed that that truly is the case? Or
was that caused by copy paste?
On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan and...@dunslane.net wrote:
On 06/04/2014 03:50 PM, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan and...@dunslane.net wrote:
I agree it's scary but in a few minutes thinking about it I haven't been
able to come up with a good way of checking it. Maybe we could build
sizeof(ControlData) into the version
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've recently been pointed
towards:
Namely that replication slots are named 'slot_name' in one half of the
cases and 'slotname' in the other. That's in views, SRF columns,
function
On 2014-05-14 12:20:55 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-14 10:07:18 -0400, Tom Lane wrote:
I think that's an OK restriction as long as we warn people about it
(you could update a replication pair as long as you shut them both
down cleanly at
I wrote:
Robert Haas robertmh...@gmail.com writes:
I think that's worth considering. Another idea is: suppose we set up
a PostgreSQL database somewhere that contained information about what
controldata layout corresponded to what control version:
That seems possibly workable.
BTW, a
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-14 12:20:55 -0400, Tom Lane wrote:
Yeah, I don't think we want to bump the WAL version code post-beta1.
Probably better to assign the modified spgist record a new xl_info ID
number, so that a beta1 slave would throw an error for it.
All,
Can we get this patch going again for 9.5?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2014-06-04 16:32:33 -0700, Josh Berkus wrote:
Can we get this patch going again for 9.5?
A patch gets going by somebody working on it.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
On 06/04/2014 04:35 PM, Andres Freund wrote:
Hi,
On 2014-06-04 16:32:33 -0700, Josh Berkus wrote:
Can we get this patch going again for 9.5?
A patch gets going by somebody working on it.
Well yes, but it is also great to have someone remind others that it is
of interest.
JD
On Wed, Jun 04, 2014 at 10:14:42AM -0400, Tom Lane wrote:
David Rowley dgrowle...@gmail.com writes:
On Wed, Jun 4, 2014 at 11:50 AM, Noah Misch n...@leadboat.com wrote:
When a snapshot can see modifications that queued referential integrity
triggers for some FK constraint, that constraint
On 2014-06-04 20:04:07 -0400, Noah Misch wrote:
On Wed, Jun 04, 2014 at 10:14:42AM -0400, Tom Lane wrote:
It's possible that we could apply the optimization only to queries that
have been issued directly by a client, but that seems rather ugly and
surprise-filled.
... such as this idea.
On Wed, 2014-05-07 at 03:08 +0200, Andres Freund wrote:
As an additional issue it currently doesn't seem to work in VPATH
builds. That's imo a must fix.
A cd $(srcdir) .. in prove_installcheck and prove_check seems to do
the trick.
Here is my proposed patch for this.
diff --git
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-09 22:14:25 +0900, Michael Paquier wrote:
[ patch ]
I've committed a revised version of Andres' patch. Mostly cosmetic
fixes, but the hash implementation was still wrong:
return DirectFunctionCall1(hashint8, PG_GETARG_LSN(0));
Peter Eisentraut pete...@gmx.net writes:
On Wed, 2014-05-07 at 03:08 +0200, Andres Freund wrote:
As an additional issue it currently doesn't seem to work in VPATH
builds. That's imo a must fix.
A cd $(srcdir) .. in prove_installcheck and prove_check seems to do
the trick.
Here is my
On Thu, Jun 5, 2014 at 9:12 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2014-06-04 10:37:48 +1000, Haribabu Kommi wrote:
Thanks for the test. Patch is re-based to the latest head.
Did you look at the source of the conflict? Did you intentionally mark
the functions as leakproof
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've recently been pointed
towards:
Namely that replication slots are named 'slot_name' in one half of
On Thu, Jun 5, 2014 at 9:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-09 22:14:25 +0900, Michael Paquier wrote:
[ patch ]
I've committed a revised version of Andres' patch.
Thanks!
I thought even that was kind of overkill; but a bigger
Hi,
On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao masao.fu...@gmail.com wrote:
I like using slot_name everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.
Stefan Kaltenbrunner wrote
On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Of course, if we do fix this then the door opens for pushing
David G Johnston david.g.johns...@gmail.com writes:
If we are planning on keeping this rule, which it seems like at least a few
people feel is too stringent, maybe we can consider releasing an Alpha
version and communicate the expectation that an initdb will be required to
go from the alpha to
81 matches
Mail list logo
