On Wed, Jul 5, 2017 at 11:03 AM, AP <a...@zip.com.au> wrote:
> On Wed, Jul 05, 2017 at 10:29:09AM +0530, Amit Kapila wrote:
>> >> bitmappages. Can you try to use pgstattuple extension and get us the
>> >> results of Select * from pgstathashindex('index_name');? I
On Wed, Jul 5, 2017 at 9:53 AM, AP <a...@zip.com.au> wrote:
> On Wed, Jul 05, 2017 at 08:10:10AM +0530, Amit Kapila wrote:
>> On Tue, Jul 4, 2017 at 4:27 PM, AP <a...@zip.com.au> wrote:
>> > There is one index that caused an issue. Towards the end of an import
f on this workload.
> I'll see if I can get the table reloaded a-fresh to see if that's what
> it takes to trigger the error.
>
Thanks. I suggest when an error occurs, don't throw away that index
because we can get some useful information from it to diagnose the
reason of error.
--
Wit
On Tue, Jul 4, 2017 at 1:23 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Mon, Jul 3, 2017 at 7:40 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>
> It seems to me that this qualifies as an open item for 10. WAL-logging
> is new for hash tables. Amit, cou
On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 30 June 2017 at 05:14, Amit Kapila <amit.kapil...@gmail.com> wrote:
>
>> This is explained in section 15.2 [1], refer below para:
>> "The query might be suspended during exec
On Mon, Jul 3, 2017 at 6:15 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Mar 23, 2017 at 1:18 PM, Ashutosh Sharma <ashu.coe...@gmail.com>
> wrote:
>>
>> Conclusion:
>> As seen from the test results mentioned above, there is some performance
>
d wait event for group lock
waits in this patch as is done by Robert in commit
d4116a771925379c33cf4c6634ca620ed08b551d for ProcArrayGroupUpdate.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
group_update_clog_v12.patch
Description: Binary data
--
Sent via pgsql-ha
On Mon, Jul 3, 2017 at 3:24 PM, Ashutosh Sharma <ashu.coe...@gmail.com> wrote:
> On Mon, Jul 3, 2017 at 9:12 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> The basic issue was that the WAL logging for Create Index operation
>> was oblivion of the fact that for unlo
for short operations. Refer text atop AllocateFile(). If the
number of blocks to be dumped is large, then the file can remain open
for the significant period of time.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
n", num_blocks);
+ if (ret < 0)
+ {
+ int save_errno = errno;
+
+ FreeFile(file);
I think you don't need to close the file in case of error, it will be
automatically taken care in case of error (via transaction abort
path).
9.
+ /* Register autoprewarm load. */
+ setup_autoprewarm(_worker, &qu
be
unpredictable whether the user will get the error or there will be
only a server log for the same.
> I think that
> is okay as the objective was to get one worker up and running.
>
You are right that the objective will be met, but still, I feel the
behavior of this API will be unpredictab
On Thu, Jun 29, 2017 at 6:57 AM, Bruce Momjian <br...@momjian.us> wrote:
> On Sat, Jun 24, 2017 at 09:24:21AM +0530, Amit Kapila wrote:
>> > I was not clear. I was not saying there can be only one extra WAL file.
>> > I am saying the "Latest checkpoint
which make it difficult to follow that
approach.
I think this should be considered a PostgreSQL 10 open item.
[1] - https://www.postgresql.org/message-id/20170630005634.GA4448%40momjian.us
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
fix_unlogged_hash_index_issue_v1.patch
D
>
> This doesn't fail on PG 10 since we WAL-log hash indexes.
>
> I think we have two questions:
>
> 1. do we fix this in the server
If we want to fix this in the server then we need to log (write WAL)
the init fork for hash indexes.
> 2. if not, do we fix pg_upgrade
>
r for users to understand.
[1] -
https://www.postgresql.org/docs/devel/static/when-can-parallel-query-be-used.html
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jun 28, 2017 at 7:43 AM, Haribabu Kommi
<kommi.harib...@gmail.com> wrote:
>
> On Wed, Jun 28, 2017 at 12:00 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
>>
>> On Tue, Jun 27, 2017 at 4:19 PM, Amit Kapila <amit.kapil...@gmail.com>
>
On Tue, Jun 27, 2017 at 7:23 PM, Alexander Korotkov
<a.korot...@postgrespro.ru> wrote:
> On Tue, Jun 27, 2017 at 4:08 PM, Amit Kapila <amit.kapil...@gmail.com>
> wrote:
>>
>> Similarly,
>> if the page format is changed you need to consider all page sc
acuum
> algorithm?
>
Probably, some other algorithm for vacuum. I am not sure current
vacuum with its parameters can be used so easily. One thing that
might need some thoughts is that is it sufficient to say that keep
autovacuum as off and call some different API for places where the
vacuum
ic for
> scanning heap, doing updates and so on...
>
If you are changing tuple format then you do need to worry about
places wherever we are using HeapTuple like TupleTableSlots,
Visibility routines, etc. (just think if somebody changes tuple
header, then all such places are susceptible to ch
On Mon, Jun 26, 2017 at 8:09 PM, Andrew Dunstan
<andrew.duns...@2ndquadrant.com> wrote:
>
>
> On 06/26/2017 10:36 AM, Amit Kapila wrote:
>> On Fri, Jun 23, 2017 at 9:12 AM, Andrew Dunstan
>> <andrew.duns...@2ndquadrant.com> wrote:
>>>
>>> On 06/22
;>
>>
>
>
> See attached log and stacktrace
>
Is this all the log contents or is there something else? The attached
log looks strange to me in the sense that the first worker that gets
invoked is Parallel worker number 2 and it finds that somebody else
has already set the s
On Fri, Jun 23, 2017 at 8:18 PM, Bruce Momjian <br...@momjian.us> wrote:
> On Fri, Jun 23, 2017 at 08:10:17AM +0530, Amit Kapila wrote:
>> On Wed, Jun 21, 2017 at 10:03 PM, Bruce Momjian <br...@momjian.us> wrote:
>> > On Wed, Jun 21, 2017 at 07:49:21PM +0530, Amit K
On Fri, Jun 23, 2017 at 8:47 PM, Sergey Burladyan <eshkin...@gmail.com> wrote:
> Bruce Momjian <br...@momjian.us> writes:
>
>> On Wed, Jun 21, 2017 at 07:49:21PM +0530, Amit Kapila wrote:
>> > On Tue, Jun 20, 2017 at 7:24 PM, Amit Kapila <amit.kapil...@gmail.co
ne as part of taking flush calls out of walwritelock. Can you
share patch or some details about how you have done it and how have
you measured the contention you are seeing?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hac
r request is still valid.
>
Yeah, that makes and also maybe we can try to print dsm_segment handle
value both before launching the worker and in parallel worker
(ParallelWorkerMain). That might help us in identifying the reason of
error "could not map dynamic shared memory segment".
On Wed, Jun 21, 2017 at 10:03 PM, Bruce Momjian <br...@momjian.us> wrote:
> On Wed, Jun 21, 2017 at 07:49:21PM +0530, Amit Kapila wrote:
>> On Tue, Jun 20, 2017 at 7:24 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> > Hmm. I think we need something that wo
On Tue, Jun 20, 2017 at 7:24 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Tue, Jun 20, 2017 at 7:05 PM, Sergey Burladyan <eshkin...@gmail.com> wrote:
>> Amit Kapila <amit.kapil...@gmail.com> writes:
>>
>>> On Tue, Jun 20, 2017 at 3:40 PM, Sergey
On Wed, Jun 21, 2017 at 12:15 AM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 6/20/17 09:23, Amit Kapila wrote:
>> To avoid that why can't we use the same icu path for executing uconv
>> as we are using for linking?
>
> Yeah, you'd need to use pr
On Tue, Jun 20, 2017 at 7:05 PM, Sergey Burladyan <eshkin...@gmail.com> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>
>> On Tue, Jun 20, 2017 at 3:40 PM, Sergey Burladyan <eshkin...@gmail.com>
>> wrote:
> I use pg 9.2 and "skipping resta
gt; Okay, I think, you are talking about the case where we may have
> multiple ICU versions installed on our system and there might be a
> possibility that the uconv command may get executed from the ICU
> version that we are not trying to link with postgres.
>
To avoid that why can't we use
On Tue, Jun 20, 2017 at 1:50 PM, Amit Langote
<langote_amit...@lab.ntt.co.jp> wrote:
> On 2017/06/19 23:31, Tom Lane wrote:
>> Amit Kapila <amit.kapil...@gmail.com> writes:
>>> On Mon, Jun 19, 2017 at 11:37 AM, Amit Langote
>>> <langote_amit...@lab.ntt.
t; Uh, as I understand it the rsync is going to copy the missing WAL file
>> > from the new master to the standby, right, and I think pg_controldata
>> > too, so it should be fine. Have you tested to see if it fails?
>
> It need old WAL files from old version for correct
) has similar check to skip metapage in certain code
paths.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> working fine. With the help of attached patch,
>
Did you intended to attach the patch to this e-mail or are you
referring to Kuntal's patch up thread? If later, then it is better to
mention the link of mail which has a patch that you have verified.
--
With Regards,
Amit Kapila
On Sat, Jun 17, 2017 at 8:27 PM, Ashutosh Sharma <ashu.coe...@gmail.com> wrote:
> Hi,
>
> On Sat, Jun 17, 2017 at 6:38 PM, Peter Eisentraut
> <peter.eisentr...@2ndquadrant.com> wrote:
>> On 6/16/17 23:46, Amit Kapila wrote:
>>> I have just posted one way
>
On Sat, Jun 17, 2017 at 6:57 AM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 6/16/17 10:12, Peter Eisentraut wrote:
>> On 6/16/17 06:30, Amit Kapila wrote:
>>> How will this compare UTF-8 strings in UTF-8 encoding? It seems to me
>>
On Fri, Jun 16, 2017 at 7:42 PM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 6/16/17 06:30, Amit Kapila wrote:
>> How will this compare UTF-8 strings in UTF-8 encoding? It seems to me
>> that ideally, it should use ucol_strcollUTF8 to compare the same,
&
On Fri, Jun 16, 2017 at 11:03 PM, Sergey Burladyan <eshkin...@gmail.com> wrote:
> Bruce Momjian <br...@momjian.us> writes:
>
>> On Fri, Jun 16, 2017 at 08:10:13PM +0530, Amit Kapila wrote:
>> > On Fri, Jun 16, 2017 at 7:03 AM, Sergey Burladyan <eshkin...@
f53ac8673ea67c4e467. However, it is not clear to
me neither it is mentioned in comments why we have done it that way.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-8 encoding? It seems to me
that ideally, it should use ucol_strcollUTF8 to compare the same,
however, with patch, it will always ucol_strcoll as we never define
HAVE_UCOL_STRCOLLUTF8 flag on Windows. We have some multi-byte tests
in src/test/mb directory, see if we can use those to verify the
[59404dec.2d9c:7] DETAIL: Failed process
was running: select stringu1::int2 from tenk1 where unique1 = 1;
2017-06-13 16:45:02.652 EDT [59404dec.2d9c:8] LOG: terminating any
other active server processes
Error "could not map dynamic shared memory segment" is due to query
"E
t to screw memcmp optimization we have in
this function, so do this ICU specific checking after memcmp check.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
at we are seeing in
this case.
[1] -
https://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On Wed, Jun 14, 2017 at 8:44 PM, Bruce Momjian <br...@momjian.us> wrote:
> On Wed, Jun 14, 2017 at 07:45:17PM +0530, Amit Kapila wrote:
>> > Now, it seems we later added a doc section early on that talks about
>> > "Verify standby servers" so I have moved the w
is required for the master
cluster (probably it is clear for users) /"on the new cluster."/"on
the new master cluster.". Do we need something different for v10 where
default wal_level is 'replica'
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jun 12, 2017 at 9:01 PM, Vladimir Borodin <r...@simply.name> wrote:
>
> 12 июня 2017 г., в 13:19, Amit Kapila <amit.kapil...@gmail.com> написал(а):
>
> On Sun, Jun 11, 2017 at 11:59 PM, Vladimir Borodin <r...@simply.name> wrote:
>
>
> 8 июня 20
if (write(fd, buf, buflen) < buflen)
+ {
+ int save_errno = errno;
+
+ CloseTransientFile(fd);
+ unlink(transient_dump_file_path);
+ errno = save_errno;
+ ereport(ERROR,
+ (errcode_for_file_access(),
+ errmsg("could not write to file \"%s\": %m",
+ transient_dump_file_path)));
+ }
It se
On Sun, Jun 11, 2017 at 11:59 PM, Vladimir Borodin <r...@simply.name> wrote:
>
> 8 июня 2017 г., в 17:03, Amit Kapila <amit.kapil...@gmail.com> написал(а):
>
> On Thu, Jun 8, 2017 at 6:49 PM, Dmitriy Sarafannikov
> <dsarafanni...@yandex.ru> wrote:
>
>
>
On Fri, Jun 9, 2017 at 7:48 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote:
> On 9 June 2017 at 19:10, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Thu, Jun 8, 2017 at 10:40 PM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Thu, Jun 8, 2017
ereport(LOG,
+ (errmsg("saved metadata info of %d blocks", num_blocks)));
It doesn't seem like a good idea to log this info at each dump
interval. How about making this as a DEBUG1 message?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via p
On Thu, Jun 8, 2017 at 10:40 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 7:01 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Thu, Jun 8, 2017 at 1:33 AM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Wed, Jun 7, 2017
rol file has been
copied, but not updated data files due to which the WAL has not been
replayed on replicas? If so, why the pg_control file is copied, it's
size shouldn't have changed?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
think it is safe to use them for fixing
> corrupted pages
> or is there a better way not to loose data?
>
I haven't looked in detail, but it sounds slightly risky proposition
to manipulate the tuples by writing C functions of the form you have
in your code. I would have preferred some way to a
On Thu, Jun 8, 2017 at 1:33 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Jun 7, 2017 at 5:46 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> As far as I understand, it is to ensure that for deleted rows, nothing
>> more needs to be done. For e
mprovement.
>
No objections from me, updated patch looks good.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
are interested in evaluating the same,
then we can request the author to post a rebased version if it doesn't
apply.
[1] -
https://www.postgresql.org/message-id/CAD__OuiwEi5sHe2wwQCK36Ac9QMhvJuqG3CfPN%2BOFCMb7rdruQ%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.en
y obvious how that
> would cause a problem.
>
> Another idea is that the commit in question is managing to corrupt
> BackgroundWorkerList somehow.
>
I don't think so because this problem has been reported previously as
well [1][2] even before the commit in question.
[1] -
https://
anything but create an additional risk of postmaster startup
> failure.
>
I think it won't create an additional risk, because the idea is that
if we fail to map the shm segment at a predefined address, then we
will allow the system to choose the initial address as we are d
On Tue, Jun 6, 2017 at 11:54 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Jun 5, 2017 at 2:51 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> Greg/Amit's idea of using the CTID field rather than an infomask bit
>>> seems like a possibly pr
On Mon, Jun 5, 2017 at 7:26 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>> Sure. I think it is slightly tricky because specs don't say clearly
>> how ASLR can impact the behavior of any API and in my last attempt I
>&
On Mon, Jun 5, 2017 at 4:58 PM, Magnus Hagander <mag...@hagander.net> wrote:
> On Mon, Jun 5, 2017 at 1:16 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>
>> On Mon, Jun 5, 2017 at 9:15 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> > Amit Kapila <
On Mon, Jun 5, 2017 at 9:15 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>
>> I think the same problem can happen during reattach as well.
>> Basically, MapViewOfFileEx can fail to load image at predefined
>> addres
On Thu, Jun 1, 2017 at 3:25 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, May 29, 2017 at 5:26 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> But I think, we can also take step-by-step approach even for v11. If
>>> we agree that it is ok to sile
LETE +
INSERT triggers for an Update statement (when row movement happens) on
the argument of code simplicity, but it sounds slightly odd behavior.
> But I think we want to wait for other's
> opinion because it is quite understandable that two triggers firing on
> the same partition sounds
On Mon, Jun 5, 2017 at 4:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>> Okay, I have added the comment to explain the same. I have also
>> modified the patch to adjust the looping as per your suggestion.
>
> I took a
On Sat, Jun 3, 2017 at 9:34 PM, Andres Freund <and...@anarazel.de> wrote:
> Hi,
>
> On 2017-06-03 17:40:08 +0530, Amit Kapila wrote:
>> The standard_planner check is sufficient to not generate parallel
>> plans for such statements, but it won't prevent if such c
On Sun, Jun 4, 2017 at 10:11 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>> In order to avoid losing track of this patch, I think it is better to
>> add it in open items list for 10.
>
> This is an entirely new feature,
t;
>
> Please, find it in attached patch.
>
> I decided to forbid referencing columns by numbers for tables, because those
> numbers could contain gaps. Also, I forbid altering statistics target for
> non-expression index columns, because it has no effect.
>
In order to avoid l
On Fri, Jun 2, 2017 at 7:20 PM, Petr Jelinek
<petr.jeli...@2ndquadrant.com> wrote:
> On 02/06/17 15:37, Amit Kapila wrote:
>>
>> No, it is to avoid calling free of memory which is not reserved on
>> retry. See the comment:
>> + * On the first try, release memory
On Thu, Jun 1, 2017 at 10:16 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2017-06-01 21:37:56 +0530, Amit Kapila wrote:
>> On Thu, Jun 1, 2017 at 9:34 PM, Andres Freund <and...@anarazel.de> wrote:
>> > On 2017-06-01 21:23:04 +0530, Amit Kapila wrote:
>> &g
lse block IMHO.
>
I felt that it is easier to understand the code in the way it is
currently written, but I can invert the check if you find it is easier
to read and understand that way.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jun 2, 2017 at 6:38 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Jun 2, 2017 at 9:01 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> Your reasoning sounds sensible to me. I think the other way to attack
>> this problem is that we can mainta
t stall if shm queues are full and workers can do batched
writes in shm queue to avoid the shm queue communication overhead) in
a similar way.
[1] -
https://www.postgresql.org/message-id/CAOGQiiMwhOd5-iKZnizn%2BEdzZmB0bc3xa6rKXQgvhbnQ29zCJg%40mail.gmail.com
--
With Regards,
Amit Kapila.
this patch,
then it is better to submit those as a separate patch in a new thread.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 1, 2017 at 9:34 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2017-06-01 21:23:04 +0530, Amit Kapila wrote:
>> On a related note, I think it might be better to have an
>> IsInParallelMode() check in this case as we have at other places.
>> This is to
tion runs is the
parallel mode, it will act as a safeguard.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
databases
not only current database.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
such an option to *prewarm
functionality, it should be added as a separate patch as it has its
own set of problems that needs to be solved.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 29, 2017 at 9:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>> I think this happens due to commit
>> f82ec32ac30ae7e3ec7c84067192535b2ff8ec0e which renames pg_xlog to
>> pg_wal. It does take care o
On Mon, May 29, 2017 at 3:20 PM, tushar <tushar.ah...@enterprisedb.com> wrote:
> On 05/29/2017 03:10 PM, Amit Kapila wrote:
>>
>> What makes you think above is a valid usage and should
>> pass?
>
> with earlier versions ,for instance - v.96 v/s v9.5 ,pg_resetw
On Fri, May 26, 2017 at 8:21 PM, Magnus Hagander <mag...@hagander.net> wrote:
>
> On Fri, May 26, 2017 at 8:24 AM, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>>
>> On Fri, May 26, 2017 at 8:20 AM, Amit Kapila <amit.kapil...@gmail.com>
>&g
l -D /tmp/pg9.6/bin/data/
> pg_resetwal: pg_control exists but is broken or unknown version; ignoring it
>
This appears to be an expected error as you are trying to use a
version of binaries that doesn't match the version stored in
pg_control. What makes you think above is a valid usage and should
On Mon, May 29, 2017 at 11:20 AM, Amit Khandekar <amitdkhan...@gmail.com> wrote:
> On 24 May 2017 at 20:16, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Wed, May 24, 2017 at 8:14 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> Apart fr
On Sat, May 27, 2017 at 10:18 PM, Vladimir Borodin <r...@simply.name> wrote:
>
> 26 мая 2017 г., в 21:39, Amit Kapila <amit.kapil...@gmail.com> написал(а):
>
> I think you somehow need
> to ensure before switchover that all the WAL is replicated to ensure
> this is n
rallelPlan that might help you in
your work.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s quite suspicious. This seems to indicate that
not all WAL records are replicated before the switchover. What is the
value of "synchronous_commit" you are using? I think you somehow need
to ensure before switchover that all the WAL is replicated to ensure
this is not a setup problem.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 26, 2017 at 5:30 AM, Tsunakawa, Takayuki
<tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila
>> Yes, I also share this opinion, the shm attach failures are du
On Thu, May 25, 2017 at 8:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
>> Yes, I also share this opinion, the shm attach failures are due to
>> randomization behavior, so sleep won't help much. So, I will change
>> th
help much. So, I will change
the patch to use 100 retries unless people have other opinions.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 24, 2017 at 6:59 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Tue, May 23, 2017 at 8:14 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> So it seems both you and Tom are leaning towards some sort of retry
>> mechanism for shm reattac
On Wed, May 24, 2017 at 8:14 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Wed, May 24, 2017 at 2:47 PM, Amit Khandekar <amitdkhan...@gmail.com>
> wrote:
>>
>> By now, majority of the opinions have shown that they do not favour
>> two triggers gettin
On Wed, May 24, 2017 at 2:47 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote:
> On 18 May 2017 at 16:52, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
>>> On Wed, May 17, 2017
EXEC_BACKEND
builds). I think it makes sense to have retry mechanism for
EXEC_BACKEND builds, so done that way in the patch. Yet another point
which needs some thought is for reattach operation, before retrying do
we want to reserve the shm by using VirtualAllocEx?
--
With Regards,
Amit Kapila.
E
On Mon, May 22, 2017 at 2:54 PM, Rafia Sabih
<rafia.sa...@enterprisedb.com> wrote:
> On Wed, May 17, 2017 at 2:57 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Tue, May 16, 2017 at 2:14 PM, Ashutosh Bapat
>> <ashutosh.ba...@enterprisedb.com> wrote:
&g
Applied to a hash index, that might offer another useful
> kind of multicolumn support, which otherwise seems limited to queries
> where you have the exact values of all indexed columns.
>
Agreed, but even if we have any such syntax, making it work for hash
indexes is tricky, because
On Sun, May 21, 2017 at 5:26 AM, Bruce Momjian <br...@momjian.us> wrote:
> On Fri, May 19, 2017 at 04:54:27PM -0400, Robert Haas wrote:
>> On Tue, May 16, 2017 at 9:25 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> > On Tue, May 16, 2017 at 5:14 PM, Robert Haas
On Wed, May 17, 2017 at 9:43 PM, Remi Colinet <remi.coli...@gmail.com> wrote:
>
> 2017-05-13 14:38 GMT+02:00 Amit Kapila <amit.kapil...@gmail.com>:
>>
>> On Wed, May 10, 2017 at 10:10 PM, Remi Colinet <remi.coli...@gmail.com>
>> wrote:
>> >
&g
On Thu, May 18, 2017 at 7:56 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, May 17, 2017 at 6:57 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> +1. Why not similar behavior for any other statements executed in
>> this module by do_sql_command?
>
&
On Sat, May 20, 2017 at 2:24 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, May 16, 2017 at 9:25 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Tue, May 16, 2017 at 5:14 PM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Tue, May 16, 2017
rk out, but I guess Rafia hasn't shared those with
the intuition that nobody would be interested in hearing what didn't
work out.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
201 - 300 of 3337 matches
Mail list logo
