Thanks for the commit. I have tested it again. Not getting server crash now.
Thanks & Regards,
Rajkumar Raghuwanshi
QMG, EnterpriseDB Corporation
On Mon, May 16, 2016 at 9:38 PM, Robert Haas wrote:
> On Fri, May 13, 2016 at 6:40 PM, Michael Paquier
> wrote:
> > On Fri, May 13, 2016 at 11:14 PM
On 14 May 2016 at 02:49, Tom Lane wrote:
>
> * This year's major release will be 9.6.0, with minor updates 9.6.1,
> 9.6.2, etc. It's too late to do otherwise for this release cycle.
>
> * Next year's major release will be 10.0, with minor updates 10.1,
> 10.2, etc.
>
> * The year after, 11.0.
Joshua D. Drake wrote:
> On 05/16/2016 06:32 PM, Alvaro Herrera wrote:
> >Joshua D. Drake wrote:
> >
> >>Alvaro,
> >>
> >>Thank you for bringing this to light. Is there a contributor FAQ for
> >>PgLogical so that people can help?
> >
> >Hmm, I don't think there's any contributor FAQ. It's supposed
On Mon, May 16, 2016 at 06:20:34PM -0700, Joshua D. Drake wrote:
> On 05/16/2016 05:52 PM, David Fetter wrote:
> > Folks,
>
> > This path would, of course, run either locally or across a
> > network, and be testable in both cases. There would be a
> > downgrade path, namely switching origin nodes
On 05/16/2016 06:32 PM, Alvaro Herrera wrote:
Joshua D. Drake wrote:
Alvaro,
Thank you for bringing this to light. Is there a contributor FAQ for
PgLogical so that people can help?
Hmm, I don't think there's any contributor FAQ. It's supposed to be a
regular patch submission, after all -- i
Joshua D. Drake wrote:
> Alvaro,
>
> Thank you for bringing this to light. Is there a contributor FAQ for
> PgLogical so that people can help?
Hmm, I don't think there's any contributor FAQ. It's supposed to be a
regular patch submission, after all -- it needs user interface review, a
review o
On 05/16/2016 06:22 PM, Alvaro Herrera wrote:
David Fetter wrote:
As a relatively (to our users) minor course correction, I would like
to propose the following:
- Develop a logical upgrade path as a part of the (Yay! Sexy!) logical
replication that's already in large part built.
This pat
David Fetter wrote:
> As a relatively (to our users) minor course correction, I would like
> to propose the following:
> - Develop a logical upgrade path as a part of the (Yay! Sexy!) logical
> replication that's already in large part built.
>
> This path would, of course, run either locally
On 05/16/2016 05:52 PM, David Fetter wrote:
Folks,
This path would, of course, run either locally or across a network,
and be testable in both cases. There would be a downgrade path,
namely switching origin nodes.
What say?
What happens when the database is 5TB in size and you only have 50
Folks,
We have a problem.
With all due respect to the valiant efforts of people over the years
who have tried to make an upgrade-in-place system work, I would like
to note that such a system faces what I believe are insurmountable
barriers to being done correctly. I will then propose an alternat
Instead of allocating this memory unconditionally for each buffer,
wouldn't it be better to set all the page pointers to NULL in
GenericXLogStart and allocate memory only once a buffer is registered
in GenericXLogRegisterBuffer when finding a free slot? This patch is
wasting many cycles.
Generi
On Tue, May 17, 2016 at 6:01 AM, Teodor Sigaev wrote:
> Correctly align page's images in generic wal API
>
> Page image should be MAXALIGN'ed because existing code could directly align
> pointers in page instead of align offset from beginning of page.
>
> Found during play with indexes as extensti
On Tue, May 17, 2016 at 12:07 AM, Palle Girgensohn wrote:
> pg_restore: creating TABLE "public.cal_event"
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 205; 1259 3538451239 TABLE
> cal_event nobody
> pg_restore: [archiver (db)] could
On Tue, May 17, 2016 at 6:01 AM, Michael Paquier
wrote:
> EACCES is a bit too low-level... I had in mind to check GetLastError
> with only ERROR_ACCESS_DENIED, and retry only in this case, which is
> the case where one postmaster is trying to access the segment of
> another.
s/low/high/.
--
Mich
On Tue, May 17, 2016 at 4:16 AM, Amit Kapila wrote:
> On Mon, May 16, 2016 at 9:45 AM, Michael Paquier
> wrote:
>>
>> On Sun, May 15, 2016 at 3:34 PM, Amit Kapila
>> wrote:
>> > Sounds sensible, but if we want to that route, shall we have some
>> > mechanism
>> > such that if retrying it for 10
On Tue, May 17, 2016 at 4:40 AM, Piotr Stefaniak
wrote:
> while investigating the shm_mq code and its testing module I made some
> cosmetic improvements there. You can see them in the attached diff file.
-toc_bytes = offsetof(shm_toc, toc_entry) +nentry * sizeof(shm_toc_entry)
+toc_bytes
Hello,
while investigating the shm_mq code and its testing module I made some
cosmetic improvements there. You can see them in the attached diff file.
commit 0e202cb6e0eca2e7fb3e1353b550f3d2ace9680e
Author: Piotr Stefaniak
Date: Thu Apr 28 18:36:16 2016 +0200
Cosmetic improvements around
On Mon, May 16, 2016 at 9:45 AM, Michael Paquier
wrote:
>
> On Sun, May 15, 2016 at 3:34 PM, Amit Kapila
wrote:
> > Sounds sensible, but if we want to that route, shall we have some
mechanism
> > such that if retrying it for 10 times (10 is somewhat arbitrary, but we
> > retry 10 times in PGShare
On Sat, May 14, 2016 at 8:37 PM, Tom Lane wrote:
> Jeff Janes writes:
>> There are lots of improvement which get done to in-memory data
>> structures that wouldn't require a pg_dump/pg_upgrade, which could in
>> principle be ported into prior major versions if we had the resources
>> (reviewing,
On Mon, May 16, 2016 at 8:28 AM, Andres Freund wrote:
> On 2016-05-10 17:58:33 -0700, Andres Freund wrote:
>> FWIW, I've commented out the relevant sections from xlog_redo and since
>> then I've not been able to reproduce the issue.
>
> A couple days of running later, and it hasn't yet re-triggere
I never know how to spell the various derived forms of "cancel" that
come up from time to time.
[rhaas pgsql]$ for a in canceled cancelled canceling cancelling
cancelation cancellation; do echo -n $a:; git grep $a | wc -l; done
canceled: 161
cancelled: 10
canceling: 141
cancelling:
On Fri, May 13, 2016 at 6:40 PM, Michael Paquier
wrote:
> On Fri, May 13, 2016 at 11:14 PM, Robert Haas wrote:
>> So, barring objections, I intend to apply the attached fixup patch,
>> which replaces Michael's logic with Ashutosh's logic and rewrites the
>> comments such to be much more explicit.
On 2016-05-10 17:58:33 -0700, Andres Freund wrote:
> FWIW, I've commented out the relevant sections from xlog_redo and since
> then I've not been able to reproduce the issue.
A couple days of running later, and it hasn't yet re-triggered. So I
assume that's indeed the fix.
--
Sent via pgsql-hac
On Wed, May 11, 2016 at 3:44 AM, Etsuro Fujita
wrote:
> I'll add this to the next CF.
Makes sense. I think this is basically a new feature, so let's treat
it that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailin
On Wed, May 11, 2016 at 3:20 AM, Etsuro Fujita
wrote:
> Thanks for the review!
>
> I'll add this to the next CF. I think this should be addressed in advance
> of the release of 9.6, though.
I agree. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
Hi,
When trying an upgrade from postgresql94 -> postgresql96 (beta1) using
pg_upgrade:
pg_upgrade -p 5433 -P 5434 -b /usr/local/bin -B /home/girgen/postgres96/bin -d
/tank/opt96/pgsql/data94 -D /tank/opt96/pgsql/data96 -U pgsql96 -k
I eventually get this:
pg_restore: creating TABLE "public.
On Tue, May 10, 2016 at 10:40 PM, Masahiko Sawada wrote:
> Or second way I came up with is having tool to remove particular _vm
> file safely, which is executed via SQL or client tool like
> pg_resetxlog.
>
> Attached updated VACUUM SCAN_ALL patch.
> Please find it.
We should support scan_all onl
Peter Eisentraut writes:
> On 5/16/16 9:53 AM, Greg Stark wrote:
>> I thought the idea was that Berkeley tossed an source tree over the
>> wall with no version number and then the first five releases were
>> Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
>> Postgres95 1.0.9. T
On 5/16/16 9:53 AM, Greg Stark wrote:
On Sat, May 14, 2016 at 1:00 AM, Tom Lane wrote:
If that were the standard, we'd never have bumped the major version at
all, and would still be on 4.something (or whatever Berkeley was using
when they tossed it over the wall; I'm not too clear on whether t
On Sat, May 14, 2016 at 1:00 AM, Tom Lane wrote:
> If that were the standard, we'd never have bumped the major version at
> all, and would still be on 4.something (or whatever Berkeley was using
> when they tossed it over the wall; I'm not too clear on whether there was
> ever a 5.x release).
I
If I read gram.y code for insert statement, I see that there is an optional
USING keyword before opclass name
opt_class: any_name{ $$ = $1; }
| USING any_name{ $$ = $2; }
| /*EMPTY*/ { $
Hi Amit,
I'm running some experiments based on your infrastructure trying to
optimize SELECT queries. At some point I need to get PartitionDesc for
relation and to do it I'm using RelationGetPartitionDesc() function.
Problem is that this function copies relcache data and it can be quite
slow
Hi,
Attached patch adds missing "is" in a sentence in backup.sgml.
Thanks,
Amit
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index b036183..96fc9a0 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -906,8 +906,8 @@ SELECT * FROM pg_stop_backup(false);
Hi,all
I have a query that is very slow,and the reason may be in the rewritting of
join conditions.
this is the simplied version table and the key part of the sql.
level1_table and level2_table hold the tree data nodes,
and all_level_status table holds the current status all all nodes of all le
On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote:
> 2) There's no ability at all to revert, other than restore a backup. That
> means if you pull the trigger and discover some major performance problem,
> you have no choice but to deal with it (you can't switch back to the old
> version wi
35 matches
Mail list logo
