On Thu, Jun 16, 2016 at 12:06 PM, Robert Haas wrote:
> [ 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
>>
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 time and I'm hacking it that way. The new patch
>> is at
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 talking about that?
>> https://www.postgresql.o
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 seems to have a stray
conditional form where I would e
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?
> https://www.postgresql.org/message-id/20110707213401.GA27098%40alvh.no-ip.org
> This is
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 stage, full of WIPs and TODOs
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 failure-to-apply-proper-
>>> pathtarget issue we're looking at in t
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 a patch handling
>> this problem by adding a new
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. What we've discussed in the past is to store NOT NU
[ 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 can't figure out in what case we'd actually te
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 there shouldn't
> be a prob
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 to
hide
> >> > the
> >> > context, we can except
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: snapsho
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 there
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 PM, Andres Freund wrote:
> We mi
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 format string to
>> something
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 like something for later (or
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 c
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
necessarily unencrypted under this scheme?
>>
>>> Yes, by necessity. The username must be sent in
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 done testing to prove that. I
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 toast tuple which
> >> > since have been re-p
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 that we shouldn't. For example VACUUM doesn't try
>>
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 a different type.
>>
>> How would that ha
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
>> magic_setseed(42) just before I ran the offe
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 v
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 complaints.)
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 tables independently. O
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 many that we shouldn't. For example VACUUM doesn't tr
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 tables that
> wants the encry
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. What bothers me is that a function used
>> > in an ex
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) beh
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 values in each deleted tuple;
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 via pgsql-hackers mail
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 ANALYZE) is
> >> > identical to what you descr
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.
>> > b. Modify the test su
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 bothers me is that a function used
>>> in an expre
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 - it can read any
>> table
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 all - it can read any
> >
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 the database.
It *can*,
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 where it is. What bothers me
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 sees a page with an LSN
>> > recent enough that
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 rather than
only using val
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)
> > pruned. Why wo
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 index is extremely long-running.
>>> 2. Eventu
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 than the configured
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 off
of a couple of count
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.
>> When reading pages for the random sample for A
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 ready after specific us
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 docker-postgr
On 06/15/2016 09:30 AM, David G. Johnston wrote:
On Wed, Jun 15, 2016 at 12:09 PM, Jimmy
*2. retry*
This is something I can do via unix script, but ideally it would be
nice if there would be retry mechanism. For example if I say
retry=30 then pg_isready would try 30x with x se
(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 container and APP containe
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
>> forcibly closed by the remote host.
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 the process registering the
>
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 pos
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 corre
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 nee
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 >=
> max_worker_processes).
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 an age check; so AN
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
>
> Queries raising the fi
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. T
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)))
> {
> all_visible_cleared
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 changing collect_corrupt
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 keep
track of what hadn
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. Using the
>> line numbers from cae1c788 [1], I see the f
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, Merlin Moncure
>> > wrote:
>> >>
>> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim
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 Nasby
> >> wrote:
> >> > On 6/14/16 3:56 PM, Tom Lane wrote:
> >> >>
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
> >> wrote:
> >> > I spent some time chasing down the exact circumstances. I su
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 circumstances. I suspect
>> > that there may be an interlocking problem in heap_upda
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 heap_update. Using the
> > line numbers from cae1c788 [1], I see
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 only),
Probably if you we
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:
>> >>
>> >> Jim Nasby writes:
>> >>>
>> >>> On 6/14/16 3:01 PM, Robert Haas wrot
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 function in pg_inherits.c to fetch
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.
> >
>
> Fair enough, let me try to explain the problem a
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
> between the VACUUM, UPDATE and SELECT
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 managemen
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.
Regards,
Amul Sul.
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 of
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 $$begin
> > Perfor
Hello,
At Tue, 14 Jun 2016 21:24:58 +0900, Michael Paquier
wrote in
> On Tue, Jun 14, 2016 at 8:31 PM, Kyotaro HORIGUCHI
> wrote:
> >> +# Take a second backup of the standby while the master is offline.
> >> +$node_master->stop;
> >> +$node_standby_1->backup('my_backup_2');
> >> +$node_master-
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: parallel worker, PID 44
84 matches
Mail list logo
