On 6/15/16, Michael Paquier wrote:
> On Thu, Jun 16, 2016 at 12:10 PM, Vitaly Burovoy
> wrote:
>> In the initial letter[1] I posted a digest from the SQL-2011 standard
>> and a conclusion as a design of a new patch.
>> Now I have more free
On Thu, Jun 16, 2016 at 1:27 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane wrote:
>
>> > IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the
>> > current state is.
>>
>> Are you
On Tue, Jun 7, 2016 at 12:00 AM, Robert Haas wrote:
> On Sun, Jun 5, 2016 at 4:39 PM, Jim Nasby wrote:
>> I'm pretty sure this is a typo...
>
> Sure is. Thanks.
The same typo appears in heap_update.
PS Far be it from me, but postgres_fdw.c
Michael Paquier wrote:
> On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane wrote:
> > IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the
> > current state is.
>
> Are you talking about that?
>
On Thu, Jun 16, 2016 at 12:10 PM, Vitaly Burovoy
wrote:
> In the initial letter[1] I posted a digest from the SQL-2011 standard
> and a conclusion as a design of a new patch.
> Now I have more free time and I'm hacking it that way. The new patch
> is at the very early
On Tue, Jun 14, 2016 at 12:18 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane wrote:
>>> ... I got a core dump in the window.sql test:
>>> which I think may be another manifestation of the
On 6/15/16, Tom Lane wrote:
> Michael Paquier writes:
>> To put it short, it should not be possible to drop a NOT NULL
>> constraint on a child relation when its parent table is using it, this
>> should only be possible from the parent. Attached is
On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane wrote:
> Michael Paquier writes:
> This doesn't sound like the right approach; in particular, it won't really
> help for deciding whether to propagate a DROP NOT NULL on a parent rel to
> its children.
[ Changing subject line in the hopes of keeping separate issues in
separate threads. ]
On Mon, Jun 6, 2016 at 11:00 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm intuitively sympathetic to the idea that we should have an option
>> for this, but I
On Wed, Jun 15, 2016 at 10:48 PM, Amit Kapila wrote:
> exec_stmt_execsql() is used to execute SQL statements insider plpgsql which
> includes dml statements as well, so probably you wanted to play safe by not
> allowing parallel option from that place. However, I think
On Thu, Jun 16, 2016 at 12:46 AM, Robert Haas wrote:
>
> On Wed, Jun 15, 2016 at 5:23 AM, Amit Kapila
wrote:
> >> > Considering above analysis is correct, we have below options:
> >> > a. Modify the test such that it actually generates an error and
Kevin Grittner wrote:
> test=# -- connection 1
> analyze verbose t1; -- when run after threshold, STO error occurs
> INFO: analyzing "public.t1"
> INFO: "t1": scanned 45 of 45 pages, containing 8999 live rows and
> 1001 dead rows; 8999 rows in sample, 8999 estimated total rows
> ERROR:
On 2016-06-15 20:22:24 -0500, Kevin Grittner wrote:
> I'm not clear where you see this as being in any way different with
> STO. Above it seemed that you saw this as an issue related to
> ANALYZE. If there is not early pruning for the table being
> analyzed, nothing is at all different. If
On Wed, Jun 15, 2016 at 5:34 PM, Andres Freund wrote:
> On 2016-06-15 16:58:25 -0500, Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund wrote:
>>> On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote:
On Wed, Jun 15, 2016 at 2:20
Thanks, I agree that strftime() is better then asctime().
regards, Ioseph
2016년 06월 16일 08:37에 Tom Lane 이(가) 쓴 글:
> Alvaro Herrera writes:
>> +1 to strftime("%c"). If we wanted to provide additional flexibility we
>> could have a \pset option to change the strftime
Alvaro Herrera writes:
> +1 to strftime("%c"). If we wanted to provide additional flexibility we
> could have a \pset option to change the strftime format string to
> something other than %c, but I don't think there's enough demand to
> justify it.
Agreed, that seems
Stephen Frost wrote:
> Greetings,
>
> Looks like we might not be entirely out of the woods yet regarding
> MultiXactId's. After doing an upgrade from 9.2.6 to 9.3.4, we saw the
> following:
>
> ERROR: MultiXactId 6849409 has not been created yet -- apparent wraparound
>
> The table
Michael Paquier writes:
> On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote:
>> Robbie Harwood writes:
>>> Tom Lane writes:
>>>
Wait a second. So the initial connection-request packet is
Tomas Vondra writes:
> Attached is a reworked patch, mostly following the new design proposal
> from this thread.
I've whacked this around quite a bit and am now reasonably happy with it.
The issue of planning speed hit should be pretty much gone, although I've
not
On 2016-06-15 16:58:25 -0500, Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund wrote:
> > On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote:
> >> On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote:
> >>
> >> > We might fetch a
On Wed, Jun 15, 2016 at 2:40 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
>> wrote:
>
>> > We actually go quite some lengths to support this case, even when it's
>> > the opinion of many
On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund wrote:
> On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote:
>>
>> > We might fetch a toast tuple which
>> > since have been re-purposed for a datum of
On Wed, Jun 15, 2016 at 4:59 PM, Peter Eisentraut
wrote:
> On 6/14/16 12:37 PM, Robert Haas wrote:
>> ERROR: can't generate random numbers because you haven't specified a seed
>>
>> ...to which the user will reply, "oh yes I did; in fact I ran SELECT
>>
On 6/14/16 12:37 PM, Robert Haas wrote:
ERROR: can't generate random numbers because you haven't specified a seed
...to which the user will reply, "oh yes I did; in fact I ran SELECT
magic_setseed(42) just before I ran the offending query!". They'll
then contact an expert (hopefully) who will
Tom Lane wrote:
> I wrote:
> > Well, we did part of that, but it's still using asctime(). Should we
> > change that to strftime(..."%c"...) to be less English-centric?
> > (The result seems to be the same in C locale. pg_controldata has done
> > it that way for a long time, with few
On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote:
>
> > We might fetch a toast tuple which
> > since have been re-purposed for a datum of a different type.
>
> How would that happen?
Autovac vacuums toast and heap
On Wed, Jun 15, 2016 at 3:40 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
> > On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
> > wrote:
>
> > > We actually go quite some lengths to support this case, even when it's
> > > the opinion of
On 06/14/2016 09:59 PM, Jim Nasby wrote:
On 6/12/16 2:13 AM, Ants Aasma wrote:
On Fri, Jun 10, 2016 at 5:23 AM, Haribabu Kommi
wrote:
> 1. Instead of doing the entire database files encryption, how about
> providing user an option to protect only some particular
On Wed, Jun 15, 2016 at 2:59 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote:
>>
>> > The expression index case is the one to worry about; if there is a
>> > problem, that's where it is.
Right now, the optimizer chooses the path with the cheapest cost.
However, do we take into account the behavior of the plan in handling
mis-estimated row counts? For example, if a path has a log(n) behavior
for changes in the row count, and another plan that is slightly cheaper
has a log(n^2)
Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
> wrote:
> > We actually go quite some lengths to support this case, even when it's
> > the opinion of many that we shouldn't. For example VACUUM doesn't try
> > to find index entries using the
On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote:
> We might fetch a toast tuple which
> since have been re-purposed for a datum of a different type.
How would that happen?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent
On 2016-06-15 14:50:46 -0400, Robert Haas wrote:
> On Wed, Jun 15, 2016 at 2:45 PM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
> >> wrote:
> >> > The test I showed creates a situation which (to
On Wed, Jun 15, 2016 at 5:23 AM, Amit Kapila wrote:
>> > Considering above analysis is correct, we have below options:
>> > a. Modify the test such that it actually generates an error and to hide
>> > the
>> > context, we can exception block and raise some generic error.
On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote:
>>
>>> The expression index case is the one to worry about; if there is a
>>> problem, that's where it is. What
On Wed, Jun 15, 2016 at 1:54 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> The expression index case is the one to worry about; if there is a
>> problem, that's where it is. What bothers me is that a function used
>> in an expression index could do anything at all
Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote:
>
> > The expression index case is the one to worry about; if there is a
> > problem, that's where it is. What bothers me is that a function used
> > in an expression index could do anything at
On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote:
> The expression index case is the one to worry about; if there is a
> problem, that's where it is. What bothers me is that a function used
> in an expression index could do anything at all - it can read any
> table in
Robert Haas wrote:
> On Wed, Jun 15, 2016 at 2:45 PM, Alvaro Herrera
> wrote:
> > Maybe it is possible to get into trouble if you're taking a sample for
> > an expression index.
>
> The expression index case is the one to worry about; if there is a
> problem, that's
On Wed, Jun 15, 2016 at 2:45 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
>> wrote:
>> > The test I showed creates a situation which (to ANALYZE) is
>> > identical to what you describe -- ANALYZE
On Wed, Jun 15, 2016 at 1:45 PM, Alvaro Herrera
wrote:
> Maybe it is possible to get into trouble if you're taking a sample for
> an expression index.
Maybe -- if you are using a function for an index expression which
does an explicit SELECT against some database table
Robert Haas wrote:
> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
> wrote:
> > The test I showed creates a situation which (to ANALYZE) is
> > identical to what you describe -- ANALYZE sees a page with an LSN
> > recent enough that it could have been (and actually has been)
On Wed, Jun 15, 2016 at 1:29 PM, Robert Haas wrote:
> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
> wrote:>> So what happens in this scenario:
>>> 1. ANALYZE runs really slowly - maybe the user-defined function it's
>>> running for the expression
On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
wrote:>> So what happens in this scenario:
>> 1. ANALYZE runs really slowly - maybe the user-defined function it's
>> running for the expression index is extremely long-running.
>> 2. Eventually, the snapshot for ANALYZE is older
On 15/06/2016 18:14, Julien Rouhaud wrote:
> On 15/06/2016 17:49, Robert Haas wrote:
>> On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud
>> wrote:
I don't entirely like the new logic in
RegisterDynamicBackgroundWorker.
>>>
I wonder if we can't drive this
On Wed, Jun 15, 2016 at 10:46 AM, Robert Haas wrote:
> On Sat, Jun 11, 2016 at 11:29 AM, Kevin Grittner wrote:
>> I have reviewed the code and run tests to try to find something
>> here which could be considered a bug, without finding any problem.
>>
yup, it does for (1)
:-)
On Wed, Jun 15, 2016 at 9:53 AM Imre Samu wrote:
> >Why I need it? There is tiny window between postgres being ready to
> accept connections
> >and final scripts which create initial user/database.
> >Ideally having option to say "postgres is
We need to reach a consensus here, since there is no way to say "I don't know".
I inclined to agree with you, that returning false is better in such a
case.That will
indicate user to the source of problem.
Here is a patch, now phrase operation returns false if there is not postion
information.
>Why I need it? There is tiny window between postgres being ready to accept
connections
>and final scripts which create initial user/database.
>Ideally having option to say "postgres is ready after specific user can
login to specific database" would be ideal.
temporary - the official
On 06/15/2016 09:30 AM, David G. Johnston wrote:
On Wed, Jun 15, 2016 at 12:09 PM, Jimmy
(1) I can (and do) use psql, pg_isready seems lighter and since it already
supports credentials and DB name, I see very little harm for pg_isready to
say back whether user logged IN or not using these credentials.
(2) timeout is not the same - timeout does not retry, its a simple timeout
in case
On Wed, Jun 15, 2016 at 12:09 PM, Jimmy wrote:
> Not sure if this was discussed in the past and decided it does not belong
> to pg_isready utility
>
> I am using pg_isready in dockerized development environment as part of
> docker-compose. Simply say I have POSTGRES
On Thu, Jun 2, 2016 at 4:51 AM, Kyotaro HORIGUCHI
wrote:
> After a process termination without PQfinish() of a client,
> server emits the following log message not seen on Linux boxes.
>
>> LOG: could not receive data from client: An existing connection was
>>
On 15/06/2016 17:49, Robert Haas wrote:
> On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud
> wrote:
>>> I don't entirely like the new logic in
>>> RegisterDynamicBackgroundWorker.
>>
>>> I wonder if we can't drive this off
>>> of a couple of counters, instead of having
Not sure if this was discussed in the past and decided it does not belong
to pg_isready utility
I am using pg_isready in dockerized development environment as part of
docker-compose. Simply say I have POSTGRES container and APP container. I
use pg_isready inside app container and wait till
what's about word with several infinitives
select to_tsvector('en', 'leavings');
to_tsvector
'leave':1 'leavings':1
(1 row)
select to_tsvector('en', 'leavings') @@ 'leave <0> leavings'::tsquery;
?column?
--
t
(1 row)
Second example is not
On 6/15/16 9:04 AM, Merlin Moncure wrote:
We could stand to be more explicit here. The docs for version()
>> > indicated
>> > the server_version_num should be used for "machine processing".
On a somewhat related note, any objection to adding server_version_num
to pg_config? It's common to
On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud
wrote:
>> I don't entirely like the new logic in
>> RegisterDynamicBackgroundWorker.
>
> I'm not that happy with it too. We can avoid iterating over every slots
> if the feature isn't activated though (max_parallel_workers
On Sat, Jun 11, 2016 at 11:29 AM, Kevin Grittner wrote:
> I have reviewed the code and run tests to try to find something
> here which could be considered a bug, without finding any problem.
> When reading pages for the random sample for ANALYZE (or
> auto-analyze) there is not
On Tue, Jun 14, 2016 at 5:01 PM, Andreas Seltenreich wrote:
> Digging through the sqlsmith logging db, I noticed the following errors:
>
> ERROR: cannot update SecondarySnapshot during a parallel operation
> ERROR: cannot assign XIDs during a parallel operation
>
>
On Wed, Jun 15, 2016 at 03:02:15PM +0300, Teodor Sigaev wrote:
> On Wed, Jun 15, 2016 at 02:54:33AM -0400, Noah Misch wrote:
> > On Mon, Jun 13, 2016 at 10:44:06PM -0400, Noah Misch wrote:
> > > On Fri, Jun 10, 2016 at 03:10:40AM -0400, Noah Misch wrote:
> > > > [Action required within 72 hours.
On Wed, Jun 15, 2016 at 9:59 AM, Amit Kapila wrote:
>> That just kicks the can down the road. Then you have PD_ALL_VISIBLE
>> clear but the VM bit is still set.
>
> I mean to say clear both as we are doing currently in code:
> if (PageIsAllVisible(BufferGetPage(buffer)))
On Wed, Jun 15, 2016 at 10:03 AM, Masahiko Sawada wrote:
>> I'm not sure what to do about this: this part of the heap_update()
>> logic has been like this forever, and I assume that if it were easy to
>> refactor this away, somebody would have done it by now.
>
> How about
On 06/14/2016 07:51 PM, Robert Haas wrote:
On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson wrote:
I have rebased all my patches on the current master now (and skipped the
extensions I previously listed).
Thanks, this is really helpful. It was starting to get hard to
On Wed, Jun 15, 2016 at 9:56 PM, Robert Haas wrote:
> On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro
> wrote:
>> I spent some time chasing down the exact circumstances. I suspect
>> that there may be an interlocking problem in heap_update.
On Wed, Jun 15, 2016 at 8:59 AM, David G. Johnston
wrote:
> On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure wrote:
>>
>> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
>> wrote:
>> > On Tue, Jun 14, 2016 at 5:58 PM,
On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure wrote:
> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
> wrote:
> > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure
> wrote:
> >>
> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim
On Wed, Jun 15, 2016 at 7:13 PM, Robert Haas wrote:
>
> On Wed, Jun 15, 2016 at 9:43 AM, Amit Kapila
wrote:
> > On Wed, Jun 15, 2016 at 6:26 PM, Robert Haas
wrote:
> >> On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro
> >>
On Wed, Jun 15, 2016 at 9:43 AM, Amit Kapila wrote:
> On Wed, Jun 15, 2016 at 6:26 PM, Robert Haas wrote:
>> On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro
>> wrote:
>> > I spent some time chasing down the exact
On Wed, Jun 15, 2016 at 6:26 PM, Robert Haas wrote:
>
> On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro
> wrote:
> > I spent some time chasing down the exact circumstances. I suspect
> > that there may be an interlocking problem in
Bernd Helmle writes:
> Currently pg_dump doesn't turn off idle_in_transaction_session_timeout.
Definitely an oversight, since it turns off other timeout settings.
> Okay, the window of failure here is very narrow (on my machine it breaks
> with an insane setting of 1ms
On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
wrote:
> On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure wrote:
>>
>> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby
>> wrote:
>> > On 6/14/16 3:56 PM, Tom Lane wrote:
>> >>
Michael Paquier writes:
> To put it short, it should not be possible to drop a NOT NULL
> constraint on a child relation when its parent table is using it, this
> should only be possible from the parent. Attached is a patch handling
> this problem by adding a new
On Tue, Jun 14, 2016 at 4:48 PM, Amit Kapila
wrote:
> On Mon, Jun 13, 2016 at 8:11 PM, Tom Lane wrote:
>
> > I do
> > not share your confidence that using apply_projection_to_path within
> > create_grouping_paths is free of such a hazard.
> >
>
>
On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro
wrote:
> I spent some time chasing down the exact circumstances. I suspect
> that there may be an interlocking problem in heap_update. Using the
> line numbers from cae1c788 [1], I see the following interaction
>
IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 9.6 open item is long past due
for your status update. Please reacquaint yourself with the policy on open
item ownership[1] and then reply immediately. If I do not hear from you by
2016-06-16 07:00 UTC, I will transfer this item to release
On Monday, 13 June 2016 9:57 PM, Robert Haas wrote:
>I think a space in the format string should skip a whitespace
>character in the input string, but not a non-whitespace character.
+1, enough the benefit is we are giving correct output.
PFA patch proposing this fix.
Currently pg_dump doesn't turn off idle_in_transaction_session_timeout.
Okay, the window of failure here is very narrow (on my machine it breaks
with an insane setting of 1ms only), but for the sake of reliable backups
and protection against over motivated DBA it looks better to me to turn
that
On Wed, Jun 15, 2016 at 12:07 PM, Noah Misch wrote:
>
> On Wed, Jun 15, 2016 at 11:50:33AM +0530, Amit Kapila wrote:
> > In short, this test doesn't serve it's purpose which is to generate an
> > error from worker.
>
> That's bad. Thanks for figuring out the problem.
>
> > do
Hello,
At Tue, 14 Jun 2016 21:24:58 +0900, Michael Paquier
wrote in
Hi all,
A couple of months back the $subject has been mentioned, though nobody
actually wrote a patch to prevent that:
http://www.postgresql.org/message-id/21633.1448383...@sss.pgh.pa.us
So here is one..
To put it short, it should not be possible to drop a NOT NULL
constraint on a child relation
Amit Langote is working on supporting declarative partitioning in
PostgreSQL [1]. I have started working on supporting partition-wise join.
This mail describes very high level design and some insight into the
performance improvements.
An equi-join between two partitioned tables can be broken down
On Wed, Jun 15, 2016 at 12:07 PM, Noah Misch wrote:
>
> On Wed, Jun 15, 2016 at 11:50:33AM +0530, Amit Kapila wrote:
> > do $$begin
> > Perform stringu1::int2 from tenk1 where unique1 = 1;
> > end$$;
> >
> > ERROR: invalid input syntax for integer: "BA"
> > CONTEXT:
On Mon, Jun 13, 2016 at 10:44:06PM -0400, Noah Misch wrote:
> On Fri, Jun 10, 2016 at 03:10:40AM -0400, Noah Misch wrote:
> > On Tue, Jun 07, 2016 at 06:05:10PM -0400, Tom Lane wrote:
> > > Jean-Pierre Pelletier writes:
> > > > I wanted to test if phraseto_tsquery(),
Amit Kapila writes:
> Right, so I have moved "Failed assertion in parallel worker
> (ExecInitSubPlan)" item to CLOSE_WAIT state as I don't think there is any
> known pending issue in that item. I have moved it to CLOSE_WAIT state
> because we have derived our queries to reproduce the problem
On Wed, Jun 15, 2016 at 11:50:33AM +0530, Amit Kapila wrote:
> In short, this test doesn't serve it's purpose which is to generate an
> error from worker.
That's bad. Thanks for figuring out the problem.
> do $$begin
> Perform stringu1::int2 from tenk1 where unique1 = 1;
> end$$;
>
> ERROR:
On Wed, Jun 15, 2016 at 1:42 AM, Robert Haas wrote:
>
> On Tue, Jun 14, 2016 at 1:14 PM, Tom Lane wrote:
> >
> > I have not dug into the code enough to find out exactly what's happening
> > in Peter's complaint, but it seems like it would be a good idea
87 matches
Mail list logo