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 wrote: > Craig Ringer writes: > > On 9 October 2017 at 21:26, Abbas Butt > wrote: > >> In my case this is not true, I am calling InitSharedLatch in _PG_init > >> which gets called at CREATE EX

[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 ot

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 wrote: > On Tue, Aug 1, 2017 at 10:24 AM, Abbas Butt > wrote: > > Can anyone point out to a tutorial or a list of steps required to run PG > TAP > > tests on windows? > > Only MSVC has a special handling: > https:/

[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 Vis

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 wrote: > Abbas Butt 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_CATCH where PG_RE_THROW again jumps > to > >

[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 I

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 > wro

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 wrote: > On 2017/01/31 19:53, Abbas Butt wrote: > >> On Tue, Jan 31, 2017 at 2:25 AM, Etsuro Fujita >> mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> On 2017/01/31 18:24, Abbas Butt wrote: >> > >

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 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 from >> within a pl/pgsql fu

[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
Thanks every body for the detailed advise. Let me try replacing latches by condition variables. I will report the results here. On Wed, Nov 2, 2016 at 11:54 AM, Craig Ringer wrote: > On 2 November 2016 at 02:10, Robert Haas wrote: > > On Tue, Nov 1, 2016 at 12:35 PM, Abbas Butt

[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 thre

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 wrote: > On Mon, May 18, 2015 at 12:35 PM, Josh Berkus wrote: > > Did it ever occur to you, Bruce, that you've turned into the GC daemon > > for the project? > > GC = global coordinator? > -- > Michael > > > -- > Sent via pgs

Re: [HACKERS] varattno remapping

2013-12-23 Thread Abbas Butt
On Tue, Dec 24, 2013 at 11:47 AM, Craig Ringer wrote: > 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 reference to a c

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 wrote: > Andrew Dunstan 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 case by only changing the behavi

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 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 >>

[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 4.4.4-14ubuntu5

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