On 09.11.2015 07:46, Amit Kapila wrote:
On Sat, Nov 7, 2015 at 10:23 PM, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
Lock manager is one of the tasks we are currently working on.
There are still a lot of open questions:
1. Should distributed lock manager (DLM) d
Fabrízio de Royes Mello wrote:
> Em domingo, 8 de novembro de 2015, Bruce Momjian escreveu:
>> This git cartoon was too funny not to share:
>>
>> http://xkcd.com/1597/
>>
>> Maybe we need it on our git wiki page. ;-)
>
> I think we need our own cartoon with a funny DB story.
What, lik
On 06.11.2015 21:37, Robert Haas wrote:
On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat
wrote:
The previous patch would not compile on the latest HEAD. Here's updated
patch.
Perhaps unsurprisingly, this doesn't apply any more. But we have
bigger things to worry about.
The recent eXtensible
Em segunda-feira, 9 de novembro de 2015, Albe Laurenz <
laurenz.a...@wien.gv.at> escreveu:
> Fabrízio de Royes Mello wrote:
> > Em domingo, 8 de novembro de 2015, Bruce Momjian > escreveu:
> >> This git cartoon was too funny not to share:
> >>
> >> http://xkcd.com/1597/
> >>
> >> Maybe we
On 2015/11/07 3:55, Robert Haas wrote:
> On Sun, Jun 28, 2015 at 10:43 PM, Amit Langote
> wrote:
>> On 2015-06-29 AM 11:36, Amit Langote wrote:
>>> Hi,
>>>
>>> How about the attached that adjusts errorcode for the error related to
>>> checking the flag bgw_flags in BackgroundWorkerInitializeConnec
On 11/06/2015 08:53 PM, Robert Haas wrote:
On Fri, Nov 6, 2015 at 6:27 AM, Ildus Kurbangaliev
wrote:
There is a patch that splits SLRU LWLocks to separate tranches and
moves them to SLRU Ctl. It does some work from the main patch from
this thread, but can be commited separately. It also simplif
On 8 November 2015 at 23:35, Michael Paquier
wrote:
> > COMMIT PREPARED is a pretty thin layer; the work is all done in the
> PREPARE.
> > With a DTM, the main commit itself is done once only in the DTM, so all
> the
> > COMMIT PREPARED would do is release local node resources.
>
> Sure. Now ima
On 2015/11/09 13:40, Kouhei Kaigai wrote:
Having said that, as I said previously, I don't see much value in adding
the callback routine, to be honest. I know KaiGai-san considers that
that would be useful for custom joins, but I don't think that that would
be useful even for foreign joins, becau
On Mon, 9 Nov 2015 15:14:02 +0800
Craig Ringer wrote:
>
> I'd rather not see convoluted and complex connstrings, per my prior
> post. The JDBC extended URL style seems good enough.
It is what my patch implements.
> IMO the biggest problem is that client-side failover is way more
> complex th
On 09.11.2015 09:59, Ashutosh Bapat wrote:
Since the foreign server (referred to in the slides as secondary
server) requires to call "create extension pg_dtm" and select
dtm_join_transaction(xid);, I assume that the foreign server has to be
a PostgreSQL server and one which has this extens
On Mon, Nov 9, 2015 at 11:08 AM, wrote:
>
> - cost parameter calibration: random_page_cost = 92.89
>
This demands some explanation and raises question of value of seq_page_cost
parameter -- I don't see anything about it your mail.
--
Alex
Hi,
Here is a small patch to update an comment in create_foreignscan_plan;
add fdw_recheck_quals to the list of expressions that need the
replace_nestloop_params processing. I should have updated the comment
when I proposed the patch for the fdw_recheck_quals.
Best regards,
Etsuro Fujita
*** a/s
On 09/11/15 23:08, kawami...@tkl.iis.u-tokyo.ac.jp wrote:
Hi guys,
I’ve been using Postgres for research at an university,
Great!
[...]
・Postgres 9.4.1
[..]
More knowledgeable people are sure to reply in more detail!
However, they would probably appreciate it if you can run with 9.4.5
(th
On 9 November 2015 at 10:08, wrote:
>
> We guessed the cause of this error would be in the cost model of Postgres,
> and investigated the source code of optimizer, and we found the cause of
> this problem. It was in the index cost estimation process. On scanning
> inner table, if loop count is gr
> Any distributed transaction management requires 2PC in some or other form.
> So, we should implement 2PC for FDW keeping in mind various forms of 2PC
> used practically. Use that infrastructure to build XTM like capabilities
> for restricted postgres_fdw uses. Previously, I have requested the aut
On Sunday 08 November 2015 16:49:20 you wrote:
> I'm not necessarily objecting to that, but it's not impossible that it
> could break something for some existing user. We can decide not to
> care about that, though.
We had an idea. You can use ~ to convert the index to the array which always
sta
2015-11-09 12:36 GMT+01:00 YUriy Zhuravlev :
> On Sunday 08 November 2015 16:49:20 you wrote:
> > I'm not necessarily objecting to that, but it's not impossible that it
> > could break something for some existing user. We can decide not to
> > care about that, though.
>
> We had an idea. You can
> On 2015/11/09 13:40, Kouhei Kaigai wrote:
> >> Having said that, as I said previously, I don't see much value in adding
> >> the callback routine, to be honest. I know KaiGai-san considers that
> >> that would be useful for custom joins, but I don't think that that would
> >> be useful even for
On Monday 09 November 2015 12:48:54 you wrote:
> I am sorry - it is looking pretty obscure. Really need this feature?
IMHO yes.
Now for write: array[~2:~-2] you need like:
array[array_lower(array, 1)+3: array_upper(array, 1)-2]
Worse when long names. Besides the extra functions calls.
Thanks.
--
>From: pgsql-hackers-ow...@postgresql.org
>[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Pavel Stehule
>Sent: Montag, 9. November 2015 12:49
>To: YUriy Zhuravlev
>Cc: PostgreSQL Hackers
>Subject: Re: [HACKERS] Some questions about the array.
>
>
>
>2015-11-09 12:36 GMT+01:00 YUriy Zhu
2015-11-09 13:07 GMT+01:00 YUriy Zhuravlev :
> On Monday 09 November 2015 12:48:54 you wrote:
> > I am sorry - it is looking pretty obscure. Really need this feature?
>
> IMHO yes.
> Now for write: array[~2:~-2] you need like:
> array[array_lower(array, 1)+3: array_upper(array, 1)-2]
>
> Worse whe
On 11/9/15, YUriy Zhuravlev wrote:
> On Monday 09 November 2015 12:48:54 you wrote:
>> I am sorry - it is looking pretty obscure. Really need this feature?
>
> IMHO yes.
> Now for write: array[~2:~-2] you need like:
> array[array_lower(array, 1)+3: array_upper(array, 1)-2]
>
> Worse when long name
On Monday 09 November 2015 13:29:30 you wrote:
> It is ugly, but you can wrap it to function - so still I don't see any
> reason, why it is necessary
For example, I'm writing a lot of queries by hands...
This functionality is available in many languages and it's just convenient. Of
course it is po
On Monday 09 November 2015 04:33:28 you wrote:
> You can write it as a separate function instead of changing current syntax.
I do not think, because we have a multi-dimensional arrays.
And why we have [:] syntax now?
--
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian
2015-11-09 13:32 GMT+01:00 YUriy Zhuravlev :
> On Monday 09 November 2015 13:29:30 you wrote:
> > It is ugly, but you can wrap it to function - so still I don't see any
> > reason, why it is necessary
> For example, I'm writing a lot of queries by hands...
> This functionality is available in many
2015-11-09 13:38 GMT+01:00 YUriy Zhuravlev :
> On Monday 09 November 2015 04:33:28 you wrote:
> > You can write it as a separate function instead of changing current
> syntax.
> I do not think, because we have a multi-dimensional arrays.
> And why we have [:] syntax now?
>
The own implementation
2015-11-09 13:50 GMT+01:00 Pavel Stehule :
>
>
> 2015-11-09 13:32 GMT+01:00 YUriy Zhuravlev :
>
>> On Monday 09 November 2015 13:29:30 you wrote:
>> > It is ugly, but you can wrap it to function - so still I don't see any
>> > reason, why it is necessary
>> For example, I'm writing a lot of querie
On Monday 09 November 2015 13:50:20 Pavel Stehule wrote:
> New symbols increase a complexity of our code and our documentation.
>
> If some functionality can be implemented via functions without performance
> impacts, we should not to create new operators or syntax - mainly for
> corner use cases.
2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev :
> On Monday 09 November 2015 13:50:20 Pavel Stehule wrote:
> > New symbols increase a complexity of our code and our documentation.
> >
> > If some functionality can be implemented via functions without
> performance
> > impacts, we should not to create
2015-11-05 7:24 GMT+01:00 Catalin Iacob :
> On Wed, Nov 4, 2015 at 10:12 AM, Pavel Stehule
> wrote:
> > It helped me lot of, thank you
>
> Welcome, I learned quite some from the process as well.
>
> >>
> >>
> >> There's just the doc part left then.
> >
> >
> > done
>
> We're almost there but not
kawami...@tkl.iis.u-tokyo.ac.jp writes:
> - cost parameter calibration: random_page_cost = 92.89
TBH, you lost me there already. I know of no hardware on which that would
be a sane depiction of reality, so I think you've probably overfitted the
model to some particular case it was already i
On Sat, Nov 7, 2015 at 6:38 AM, Kouhei Kaigai wrote:
> Are you suggesting to pass the object name on software build time?
Yes. That's what test_shm_mq and worker_spi already do:
sprintf(worker.bgw_library_name, "test_shm_mq");
> If so, it may load incorrect libraries when DBA renamed i
On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy wrote:
> I'd like to raise a topic about extracting fields from infinite
> timestamps, so much more that it is mentioned in the TODO list:
> "Determine how to represent date/time field extraction on infinite
> timestamps".
>
> Currently extracting any
On Mon, Nov 9, 2015 at 4:06 AM, Amit Kapila wrote:
> On Sat, Nov 7, 2015 at 3:29 AM, Robert Haas wrote:
>> Modify tqueue infrastructure to support transient record types.
>
> I am getting below compiler warning on Windows:
> tqueue.c(662): warning C4715: 'TupleQueueRemap' : not all control paths
On Mon, Nov 9, 2015 at 2:58 PM, Pavel Stehule wrote:
> I needed to understand the support for Python 3.5.
>
> The patch with the fix is attached regress tests 3.5 Python
I wanted to type a reply this morning to explain and then I noticed
there's another file (_0.out) for Python2.4 and older (as e
On Sat, Nov 7, 2015 at 12:07 PM, Corey Huinker wrote:
> Sorry to barge in late, but I was wondering if what we've learned with this
> patch can be applied to the case of asserting a sort order on a query
> returning from dblink().
Nope.
Sorry to the bearer of bad news, but that would be a differ
On Sat, Nov 7, 2015 at 5:42 PM, Greg Stark wrote:
> On Fri, Nov 6, 2015 at 4:54 AM, Ashutosh Bapat
> wrote:
>> PFA patch to get data sorted from the foreign server (postgres_fdw)
>> according to the pathkeys useful for merge join.
>
> An idle thought. There are going to be a lot of cases where di
On Fri, Nov 6, 2015 at 2:03 PM, Kevin Grittner wrote:
> Has anyone taken a close look at what happens if the two sides of
> the merge join have different implementations of the same collation
> name? Is there anything we should do to defend against the
> problem?
The issue of FDWs vs. collations
On Fri, Nov 6, 2015 at 10:13 AM, Robert Haas wrote:
>
> On Thu, Nov 5, 2015 at 10:49 PM, Amit Kapila
wrote:
> > On Thu, Nov 5, 2015 at 11:54 PM, Robert Haas
wrote:
> >> I was thinking about this idea:
> >>
> >> 1. Add a parallel_aware flag to each plan.
> >
> > Okay, so shall we add it in generi
On Monday, November 9, 2015 9:37 AM, Robert Haas wrote:
> On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy
> wrote:
>> I'd like to raise a topic about extracting fields from infinite
>> timestamps, so much more that it is mentioned in the TODO list:
>> "Determine how to represent date/time field
Kevin Grittner writes:
> On Monday, November 9, 2015 9:37 AM, Robert Haas
> wrote:
>> That doesn't seem like enough consensus to commit this patch, which
>> would change everything to +/-infinity. That particular choice
>> wouldn't bother me much, but it sounds like other people aren't sold.
>>
I was unaware that we had +- infinity for numeric.
select pg_typeof(extract(epoch from current_date));
pg_typeof
--
double precision
Given that null is a "special value that is used to indicate the absence of
any data value" and that attributes like month or day-of-week will ha
> On Mon, Nov 9, 2015 at 8:22 AM, Kevin Grittner wrote:
>> My first choice for other things would be NaN, but throwing an
>> error instead would be OK.
On Monday, November 9, 2015 10:41 AM, Tom Lane wrote:
> What about returning NULL for the ill-defined cases? That seems
> to comport with SQL'
On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule
wrote:
> 2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev :
>
>> On Monday 09 November 2015 13:50:20 Pavel Stehule wrote:
>> > New symbols increase a complexity of our code and our documentation.
>> >
>> > If some functionality can be implemented via functi
Ildus Kurbangaliev wrote:
> Thanks for the review. I've attached a new version of SLRU patch. I've
> removed add_postfix and fixed EXEC_BACKEND case.
Thanks.
Please do not use "committs" in commit_ts.c; people didn't like the
abbreviated name without the underscore. But then, why are we
abbrevi
HI,
PostgreSQL 9.5 added skip locked to select for update to improve concurrency
performance, but why not add it to update sql?
this is an application case, some body will update a tuple at the same time,
so the RT for waiter is big, I use function and select for update nowait or
adviso
On 09.11.2015 17:41, Tom Lane wrote:
Kevin Grittner writes:
On Monday, November 9, 2015 9:37 AM, Robert Haas wrote:
That doesn't seem like enough consensus to commit this patch, which
would change everything to +/-infinity. That particular choice
wouldn't bother me much, but it sounds like
Hi,
On 11/06/2015 03:47 PM, Jesper Pedersen wrote:
Did you initdb between tests? Pgbench -i? Restart the database?
I didn't initdb / pgbench -i between the tests, so that it is likely it.
Each graph has a full initdb + pgbench -i cycle now.
I know, I have a brown paper bag somewhere.
Best
=?GBK?B?tcK45w==?= writes:
>PostgreSQL 9.5 added skip locked to select for update to improve
> concurrency performance, but why not add it to update sql?
Seems like you'd have unpredictable results from the update then.
regards, tom lane
--
Sent via pgsql-hackers
Hi
2015-11-05 22:23 GMT+01:00 Robert Haas :
> On Thu, Nov 5, 2015 at 3:53 PM, Catalin Iacob
> wrote:
> > On Thu, Nov 5, 2015 at 5:27 PM, Robert Haas
> wrote:
> >>> I wrote some text. But needs some work of native speaker.
> >>
> >> It does. It would be nice if some kind reviewer could help vol
2015-11-09 17:55 GMT+01:00 Alexander Korotkov :
> On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule
> wrote:
>
>> 2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev :
>>
>>> On Monday 09 November 2015 13:50:20 Pavel Stehule wrote:
>>> > New symbols increase a complexity of our code and our documentation.
>>>
On 9 November 2015 at 17:06, Tom Lane wrote:
> =?GBK?B?tcK45w==?= writes:
> >PostgreSQL 9.5 added skip locked to select for update to improve
> concurrency performance, but why not add it to update sql?
>
> Seems like you'd have unpredictable results from the update then.
>
True, but given
On Fri, Nov 6, 2015 at 8:08 PM, Peter Geoghegan wrote:
> On Wed, Aug 19, 2015 at 7:24 PM, Peter Geoghegan wrote:
> > I'll start a new thread for this, since my external sorting patch has
> > now evolved well past the original "quicksort with spillover"
> > idea...although not quite how I anticip
2015-11-09 16:46 GMT+01:00 Catalin Iacob :
> On Mon, Nov 9, 2015 at 2:58 PM, Pavel Stehule
> wrote:
> > I needed to understand the support for Python 3.5.
> >
> > The patch with the fix is attached regress tests 3.5 Python
>
> I wanted to type a reply this morning to explain and then I noticed
>
On Mon, Nov 9, 2015 at 9:06 AM, Tom Lane wrote:
> =?GBK?B?tcK45w==?= writes:
>>PostgreSQL 9.5 added skip locked to select for update to improve
>> concurrency performance, but why not add it to update sql?
>
> Seems like you'd have unpredictable results from the update then.
But with use of
Hi,
I was testing the compatibility of pg_receivexlog with the previous PostgreSQL
versions and I've discovered that in 9.5 and 9.6, although being compatible
with 9.3, it prints an ugly but harmless error message.
$ 9.5/bin/pg_receivexlog -D /tmp/testx -v -p 5493
*pg_receivexlog: could not ide
On 11/08/2015 11:17 PM, Craig Ringer wrote:
> On 9 November 2015 at 12:40, Adam Brightwell
> wrote:
>> Hi All,
>>
>> While working on an auth hook, I found that I was unable to access the
>> pg_shseclabel system table while processing the hook. I discovered
>> that the only tables that were boots
On Mon, Nov 9, 2015 at 6:31 PM, Pavel Stehule wrote:
> merged your patch
So, I just that tested version 08 is the same as the previous patch +
my change and I already tested that on Python 2.4, 2.5, 2.6, 2.7 and
3.5.
All previous comments addressed so I'll mark this Ready for Committer.
Thanks
On Mon, Nov 9, 2015 at 2:02 AM, Craig Ringer wrote:
> On 25 June 2015 at 00:52, Robert Haas wrote:
>> I agree that we can do much better at testing than we traditionally
>> have done, and I think pretty much everyone in the room for the
>> developer unconference session on testing at PGCon was al
On Sun, Nov 8, 2015 at 6:35 PM, Michael Paquier
wrote:
> Sure. Now imagine that the pg_twophase entry is corrupted for this
> transaction on one node. This would trigger a PANIC on it, and
> transaction would not be committed everywhere.
If the database is corrupted, there's no way to guarantee t
2015-11-09 19:21 GMT+01:00 Catalin Iacob :
> On Mon, Nov 9, 2015 at 6:31 PM, Pavel Stehule
> wrote:
> > merged your patch
>
> So, I just that tested version 08 is the same as the previous patch +
> my change and I already tested that on Python 2.4, 2.5, 2.6, 2.7 and
> 3.5.
>
> All previous commen
Robert Haas writes:
> On Mon, Nov 9, 2015 at 2:02 AM, Craig Ringer wrote:
>> Something that'd really help with that, IMO, would be weakening the
>> requirement that everything be C or be core Perl. Instead require that
>> configure detect whether or not facilities for some tests are present,
>> a
On Mon, Nov 9, 2015 at 5:34 AM, Etsuro Fujita
wrote:
> Here is a small patch to update an comment in create_foreignscan_plan;
> add fdw_recheck_quals to the list of expressions that need the
> replace_nestloop_params processing. I should have updated the comment
> when I proposed the patch for th
Adam Brightwell wrote:
> @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void)
> AuthIdRelationId);
> load_critical_index(AuthMemMemRoleIndexId,
> AuthMemRelationId);
> +
> On Nov 9, 2015, at 7:56 PM, Alvaro Herrera wrote:
>
> Ildus Kurbangaliev wrote:
>
>> Thanks for the review. I've attached a new version of SLRU patch. I've
>> removed add_postfix and fixed EXEC_BACKEND case.
>
> Thanks.
>
> Please do not use "committs" in commit_ts.c; people didn't like the
On 9 November 2015 at 18:46, Robert Haas wrote:
> > I am aware of the fact
> > that by definition PREPARE TRANSACTION ensures that a transaction will
> > be committed with COMMIT PREPARED, just trying to see any corner cases
> > with the approach proposed. The DTM approach is actually rather clo
Hi,
By happenstance I just had slru.h open after lunch and noticed the
following comment:
/*
* Optional array of WAL flush LSNs associated with entries in the SLRU
* pages. If not zero/NULL, we must flush WAL before writing pages
(true
* for pg_clog, false for
Hi,
$subject contains:
> The "clock hand" is a buffer index, nextVictimBuffer, that moves circularly
> through all the available buffers. nextVictimBuffer is protected by the
> buffer_strategy_lock.
>
> The algorithm for a process that needs to obtain a victim buffer is:
>
> 1. Obtain buffer_s
On 2015-11-09 11:54:59 -0500, Jesper Pedersen wrote:
> Hi,
>
> On 11/06/2015 03:47 PM, Jesper Pedersen wrote:
> >>Did you initdb between tests? Pgbench -i? Restart the database?
> >
> >I didn't initdb / pgbench -i between the tests, so that it is likely it.
> >
>
> Each graph has a full initdb +
On 2015/11/10 0:56, Robert Haas wrote:
> On Sat, Nov 7, 2015 at 12:07 PM, Corey Huinker
> wrote:
>> Sorry to barge in late, but I was wondering if what we've learned with this
>> patch can be applied to the case of asserting a sort order on a query
>> returning from dblink().
>
> Nope.
>
> Sorr
I wrote:
> Curiously though, that gets us down to this:
> 30615 strings out of 245828
> 397721 string characters out of 1810780
> which implies that indeed FlowObjectSetup *is* the cause of most of
> the strings being entered. I'm not sure how that squares with the
> observation that there are l
On 2015-11-09 19:46:37 -0500, Tom Lane wrote:
> Well, after much digging, I've found what seems a workable answer.
> It turns out that the original form of FlowObjectSetup is just
> unbelievably awful [...].
>
> This gets us down to ~135000 strings to build HEAD, and not incidentally,
> the resulti
> On Sat, Nov 7, 2015 at 6:38 AM, Kouhei Kaigai wrote:
> > Are you suggesting to pass the object name on software build time?
>
> Yes. That's what test_shm_mq and worker_spi already do:
>
> sprintf(worker.bgw_library_name, "test_shm_mq");
>
OK, I ripped out the portion around dfmgr.c.
On 10 November 2015 at 02:26, Robert Haas wrote:
>> I'd like to see, say, python and the 'unittest' module added, and
>> to see acceptance of tests using psycopg2 to stream and decode WAL
>> from a slot.
>
> I actually kind of hate this sort of thing.
For what it's worth, I don't actually like it
It is a relevant topic of readfuncs support for custom-scan.
Unlike CustomPath and CustomScanState, we don't allow custom-scan
provider to define own and larger structure that embeds CustomScan
at head of the structure, to support copyObject().
Thus, custom-scan provider needs to have own logic to
On Thu, Oct 22, 2015 at 05:14:29PM -0400, Robert Haas wrote:
> On Thu, Oct 22, 2015 at 5:09 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Despite everybody's best efforts, we mess this up more than is really
> >> desirable. Commit b8fe12a83622b350dc6849f8bb933bd8a86c1424 fixed bugs
> >> in a w
>> @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void)
>> AuthIdRelationId);
>> load_critical_index(AuthMemMemRoleIndexId,
>> AuthMemRelationId);
>> + load_cri
On 2015-11-09 23:38:57 -0500, Adam Brightwell wrote:
> >> @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void)
> >> AuthIdRelationId);
> >> load_critical_index(AuthMemMemRoleIndexId,
> >>
>> >> #define NUM_CRITICAL_SHARED_INDEXES 5/* fix if you change list
>> >> above */
>> >>
>> >
>> > Need to bump this #define? If you didn't get the error that this is
>> > supposed to throw, perhaps there's a bug somewhere worth investigating.
>>
>> Hmm... I thought that I had, are you
Adam Brightwell writes:
>>> Need to bump this #define? If you didn't get the error that this is
>>> supposed to throw, perhaps there's a bug somewhere worth investigating.
> Whoops! It must be getting late... updated patch attached.
I'm with Alvaro: the most interesting question here is why th
On 2015/10/29 23:22, Syed, Rahila wrote:
>
> Please find attached an updated patch.
>
Thanks for the v6. A few quick comments:
- duplicate_oids error in HEAD.
- a compiler warning:
pgstat.c:2898: warning: no previous prototype for ‘pgstat_reset_activityflag’
To fix that use void for empty pa
On 10 November 2015 at 01:38, Jeff Janes wrote:
> this would be handy in conjunction with LIMIT
> (which also doesn't exist for UPDATE right now).
... and, in turn, UPDATE ... ORDER BY ..., since LIMIT without ORDER
BY is usually not a great choice.
I'd quite like to see UPDATE ... ORDER BY for
On 10 November 2015 at 01:47, Marco Nenciarini
wrote:
> I've attached a little patch that removes the errors when connected to 9.3.
Looks good to me. No point confusing users.
The other callers of RunIdentifySystem are pg_basebackup and
pg_receivelogical.
pg_basebackup doesn't ask for the db_n
On Tue, Nov 10, 2015 at 3:34 AM, Andres Freund wrote:
>
> Hi,
>
> $subject contains:
>
> > The "clock hand" is a buffer index, nextVictimBuffer, that moves
circularly
> > through all the available buffers. nextVictimBuffer is protected by the
> > buffer_strategy_lock.
> >
> > The algorithm for a
On Mon, Nov 9, 2015 at 2:08 PM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
>
> On 09.11.2015 07:46, Amit Kapila wrote:
>
> I think so. Basically DLM should be responsible for maintaining
> all the lock information which inturn means that any backend process
> that needs to acquire/r
Hello, I have some random comments on this patch addition to
Amit's comments.
- Type of the flag of vacuum activity.
ACTIVITY_IS_VACUUM is the alone entry in the enum, and the
variable to store it is named as *flag. If you don't have any
plan to extend this information, the name of this variable
86 matches
Mail list logo