Re: [HACKERS] Latches API on windows

2017-10-09 Thread Abbas Butt
Thanks for the suggestion. On Mon, Oct 9, 2017 at 6:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Craig Ringer <cr...@2ndquadrant.com> writes: > > On 9 October 2017 at 21:26, Abbas Butt <abbas.b...@enterprisedb.com> > wrote: > >> In my case this is

[HACKERS] Latches API on windows

2017-10-09 Thread Abbas Butt
Hi, I am working on a contrib module that uses RegisterDynamicBackgroundWorker API to create a couple of worker processes. For synchronization between the background worker processes I am using InitSharedLatch, SetLatch, WaitLatch APIs. One of the processes is supposed to wait for the latch, the

Re: [HACKERS] How to run PG TAP tests on windows?

2017-08-02 Thread Abbas Butt
On Tue, Aug 1, 2017 at 7:35 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Aug 1, 2017 at 10:24 AM, Abbas Butt <abbas.b...@enterprisedb.com> > wrote: > > Can anyone point out to a tutorial or a list of steps required to run PG > TAP > > te

[HACKERS] How to run PG TAP tests on windows?

2017-08-01 Thread Abbas Butt
Hi, Can anyone point out to a tutorial or a list of steps required to run PG TAP tests on windows? Regards -- -- *Abbas* Architect Ph: 92.334.5100153 Skype ID: gabbasb www.enterprisedb.co m *Follow us on Twitter* @EnterpriseDB

Re: [HACKERS] PG_TRY & PG_CATCH in FDW development

2017-04-25 Thread Abbas Butt
Thanks for the reply. On Tue, Apr 25, 2017 at 7:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Abbas Butt <abbas.b...@enterprisedb.com> writes: > > What is happening for me is that PG_RE_THROW takes me to PG_TRY in the > same > > function and then PG_TRY jumps to PG

[HACKERS] PG_TRY & PG_CATCH in FDW development

2017-04-25 Thread Abbas Butt
Hi Hackers, I want to share a technical problem that I am facing while writing code for an FDW. The problem is as follows: In the FDW call back functions it is recommended to use PG_TRY PG_CATCH blocks along with PG_RE_THROW to disconnect from the foreign server. I am using the same technique in

Re: [HACKERS] An issue in remote query optimization

2017-01-31 Thread Abbas Butt
Sorry for the confusion. ANALYZE works for the foreign table 'foreign_numbers'. test=# analyze foreign_numbers; ANALYZE test=# On Tue, Jan 31, 2017 at 5:04 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Tue, Jan 31, 2017 at 5:23 PM, Abbas Butt <abbas.b...@ente

Re: [HACKERS] An issue in remote query optimization

2017-01-31 Thread Abbas Butt
On Tue, Jan 31, 2017 at 3:15 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > On 2017/01/31 19:53, Abbas Butt wrote: > >> On Tue, Jan 31, 2017 at 2:25 AM, Etsuro Fujita >> <fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote: &g

Re: [HACKERS] An issue in remote query optimization

2017-01-31 Thread Abbas Butt
On Tue, Jan 31, 2017 at 2:25 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > On 2017/01/31 18:24, Abbas Butt wrote: > >> Postgres_fdw optimizes remote queries by pushing down the where clause. >> This feature does not work consistently when the query is executed f

[HACKERS] An issue in remote query optimization

2017-01-31 Thread Abbas Butt
Hi, Postgres_fdw optimizes remote queries by pushing down the where clause. This feature does not work consistently when the query is executed from within a pl/pgsql function. The optimization works when the function executes the query for the first 5 times, and fails afterwards. Example: Step 1:

Re: [HACKERS] Using a latch between a background worker process and a thread

2016-11-03 Thread Abbas Butt
t; > On Tue, Nov 1, 2016 at 12:35 PM, Abbas Butt <abbas.b...@enterprisedb.com> > wrote: > >> Hi, > >> Consider this situation: > >> 1. I have a background worker process. > >> 2. The process creates a latch, initializes it using InitLatch & rese

[HACKERS] Using a latch between a background worker process and a thread

2016-11-01 Thread Abbas Butt
Hi, Consider this situation: 1. I have a background worker process. 2. The process creates a latch, initializes it using InitLatch & resets it. 3. It then creates a thread and passes the latch created in step 2 to it. To pass it, the process uses the last argument of pthread_create. 4. The

Re: [HACKERS] 9.5 open items

2015-05-17 Thread Abbas Butt
GC=Garbage Collector On Mon, May 18, 2015 at 9:24 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Mon, May 18, 2015 at 12:35 PM, Josh Berkus j...@agliodbs.com wrote: Did it ever occur to you, Bruce, that you've turned into the GC daemon for the project? GC = global coordinator?

Re: [HACKERS] varattno remapping

2013-12-23 Thread Abbas Butt
On Tue, Dec 24, 2013 at 11:47 AM, Craig Ringer cr...@2ndquadrant.comwrote: On 12/24/2013 02:35 PM, Craig Ringer wrote: So the short version: Given the RTE for a simple view with only one base rel and an attribute number for a col in that view, and assuming that the view col is a simple

[HACKERS] A problem with dump/restore of views containing whole row references

2012-04-27 Thread Abbas Butt
Hi, This is the version I used to run the following commands select version(); version PostgreSQL 9.2devel on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro

Re: [HACKERS] A problem with dump/restore of views containing whole row references

2012-04-27 Thread Abbas Butt
On Fri, Apr 27, 2012 at 6:25 PM, Andrew Dunstan and...@dunslane.net wrote: On 04/27/2012 08:25 AM, Abbas Butt wrote: The notation relation.* represents a whole-row reference. While parsing a whole-row reference is transformed into a Var with varno set to the correct range table entry

Re: [HACKERS] A problem with dump/restore of views containing whole row references

2012-04-27 Thread Abbas Butt
On Fri, Apr 27, 2012 at 11:21 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: Right, what I'm asking is whether or not we actually want that side effect in all cases, and specifically in this case where it's clearly not necessary. We could dodge that

Re: [HACKERS] Need more reviewers!

2008-09-06 Thread Abbas Butt
On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote: We currently have 38 patches pending, and only nine people reviewing them. At this rate, the September commitfest will take three months. If you are a postgresql hacker at all, or even want to be one, we need your help reviewing