On 2/13/15 8:52 AM, Michael Paquier wrote:
On Sun, Nov 23, 2014 at 8:23 PM, David Rowley wrote:
As the patch stands there's still a couple of FIXMEs in there, so there's
still a bit of work to do yet.
Comments are welcome
Hm, if there is still work to do, we may as well mark this patch as
re
On Wed, Dec 17, 2014 at 5:35 PM, Simon Riggs wrote:
> On 16 December 2014 at 21:17, Simon Riggs wrote:
>
> >>> This patch is a WIP version of doing that, but only currently attempts
>
> >> With the patch, XLogSendLogical uses the same logic to calculate
> SendRqstPtr
> >> that XLogSendPhysical d
On Thu, Jan 15, 2015 at 5:02 AM, Tomas Vondra
wrote:
> Maybe we can try later again, but there's no poin in keeping this in the
> current CF.
>
> Any objections?
>
None, marked as rejected.
--
Michael
On Sun, Nov 23, 2014 at 8:23 PM, David Rowley wrote:
>
> As the patch stands there's still a couple of FIXMEs in there, so there's
> still a bit of work to do yet.
> Comments are welcome
>
Hm, if there is still work to do, we may as well mark this patch as
rejected as-is, also because it stands
On Mon, Dec 22, 2014 at 10:26 PM, Robert Haas wrote:
> On Fri, Dec 19, 2014 at 8:40 AM, Petr Jelinek
> wrote:
> > What I hope to get from this is agreement on the general approach and
> > protocol so that we can have common base which will both make it easier
> to
> > create external logical rep
On Tue, Dec 23, 2014 at 9:43 AM, Peter Geoghegan wrote:
> On Mon, Dec 22, 2014 at 4:34 PM, Peter Geoghegan wrote:
> > To put it another way, creating a separate object obfuscates
> > scanRTEForColumn(), since it's the only client of
> > updateFuzzyAttrMatchState().
>
>
> Excuse me. I mean *not*
On Tue, Jan 6, 2015 at 10:51 PM, Kouhei Kaigai wrote:
> Jim, Thanks for your reviewing the patch.
>
> The attached patch is revised one according to your suggestion,
> and also includes bug fix I could found.
>
> * Definitions of TIDOperator was moved to pg_operator.h
> as other operator do
On Thu, Jan 15, 2015 at 8:02 AM, Kouhei Kaigai wrote:
> > On Fri, Jan 9, 2015 at 10:51 AM, Kouhei Kaigai
> wrote:
> > > When custom-scan node replaced a join-plan, it shall have at least two
> > > child plan-nodes. The callback handler of PlanCustomPath needs to be
> > > able to call create_plan
On Mon, Feb 2, 2015 at 10:42 PM, Robert Haas wrote:
> On Tue, Jan 20, 2015 at 4:01 AM, Fabien COELHO
> wrote:
> >> I had a look at this patch. This patch adds some text below a table
> >> of functions. Immediately above that table, there is this existing
> >> language:
> >>
> >> The function
On Sat, Jan 24, 2015 at 5:58 AM, Alvaro Herrera
wrote:
> Here's v0.5. (Why did you use that weird decimal versioning scheme? You
> could just say "v4" and save a couple of keystrokes). This patch makes
> perfect sense to me now. I was ready to commit, but I checked the
> regression test you ad
On Wed, Dec 17, 2014 at 5:39 PM, Simon Riggs wrote:
> On 15 December 2014 at 20:26, Jeff Janes wrote:
>
> > I still get the compiler error in contrib:
> >
> > pgstattuple.c: In function 'pgstat_heap':
> > pgstattuple.c:279: error: too few arguments to function
> > 'heap_beginscan_strat'
> >
> >
On Thu, Feb 12, 2015 at 3:59 AM, Robert Haas wrote:
> We're not seeing eye to eye here yet, since I don't accept your
> example scenario and you don't accept mine. Let's keep discussing.
>
> Meanwhile, here's an updated patch.
>
A lot of cool activity is showing up here, so moved the patch to C
On Thu, Dec 18, 2014 at 6:43 PM, Fujii Masao wrote:
> On Tue, Dec 16, 2014 at 3:51 AM, Simon Riggs
> wrote:
> > Currently, WALReceiver writes and fsyncs data it receives. Clearly,
> > while we are waiting for an fsync we aren't doing any other useful
> > work.
> >
> > Following patch starts WALW
Hi All,
I have a question on PG smart shutdown mode.
When shutdown Postgres by issuing *Smart Shutdown *mode (SIGTERM) request,
is there a way for client to be notified of this shutdown event? I tried
PG_NOTIFY, but I cannot get any notification events when this happens. BTW,
I am relative new
On Mon, Dec 22, 2014 at 12:19 PM, Michael Paquier wrote:
> On Mon, Dec 15, 2014 at 3:10 PM, Peter Eisentraut wrote:
> > fixed
> This patch needs a rebase, it does not apply correctly in a couple of
> places on latest HEAD (699300a):
> ./src/include/catalog/catversion.h.rej
> ./src/include/catalo
On Wed, Jan 21, 2015 at 6:02 AM, Andrew Gierth
wrote:
> Updated patch (mostly just conflict resolution):
>
> - fix explain code to track changes to deparse context handling
>
> - tiny expansion of some comments (clarify in nodeAgg header
>comment that aggcontexts are now EContexts rather th
On Tue, Feb 10, 2015 at 10:32 PM, Michael Paquier wrote:
> Patch updated is attached.
>
Patch moved to CF 2015-02 with same status.
--
Michael
On Thu, Jan 15, 2015 at 4:35 PM, Etsuro Fujita
wrote:
> As I said before, that seems to me like a good idea. So I'll update the
> patch based on that if you're okey with it. Or you've found any problem
> concerning the above idea?
>
Patch moved to CF 2015-02 with same status, "Ready for commit
On Thu, Feb 12, 2015 at 4:18 PM, Andres Freund wrote:
> No need for debugging. It's plain and simply a (cherry-pick) conflict I
> resolved wrongly during backpatching. 9.3, 9.4 and master do not have
> that problem. That whole fix was quite painful because every single
> release had significantly
On Thu, Feb 12, 2015 at 8:08 PM, Syed, Rahila
wrote:
>
>
>
> Thank you for comments. Please find attached the updated patch.
>
>
>
> >This patch fails to compile:
> >xlogreader.c:1049:46: error: extraneous ')' after condition, expected a
statement
> >blk->wi
On 2015/02/11 4:06, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/10 7:23, Dean Rasheed wrote:
Sorry, I didn't have time to look at this properly. My initial thought
is that expand_security_qual() needs to request a lock on rows coming
>from the relation
Two different CLOBBER_CACHE_ALWAYS critters recently reported exactly
the same failure pattern on HEAD:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=markhor&dt=2015-02-06%2011%3A59%3A59
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tick&dt=2015-02-12%2010%3A22%3A57
I'd say we h
On Thu, Feb 12, 2015 at 07:40:12AM -0500, Robert Haas wrote:
> On Thu, Feb 12, 2015 at 12:16 AM, Noah Misch wrote:
> > That is a major mark against putting the check in simplify_function(),
> > agreed.
>
> I do see one way to rescue that idea, which is this: put two flags,
> parallelModeOK and p
Hi all,
When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
Assert((vacstmt->options & VACOPT_VACUUM) ||
!(vacstmt->options & (VACOPT_FULL | VACOPT_FREEZE)));
I think that this should be changed with sanity checks based on the
parameter values of freeze_* in VacuumStmt
On Fri, Feb 13, 2015 at 10:16 AM, Naoya Anzai
wrote:
>>> You mean that ...
>>> Log_autovacuum_min_duration assumes a role of VACOPT_VERBOSE.
>>> Even if this parameter never use currently for manual vacuum,
>>> log_autovacuum_min_duration should be set zero(anytime output)
>>> when we executes "VA
>> You mean that ...
>> Log_autovacuum_min_duration assumes a role of VACOPT_VERBOSE.
>> Even if this parameter never use currently for manual vacuum,
>> log_autovacuum_min_duration should be set zero(anytime output)
>> when we executes "VACUUM(or ANALYZE) VERBOSE".
>> Is my understanding correct?
On Sun, Feb 8, 2015 at 10:05 AM, Andreas Karlsson wrote:
> On 01/30/2015 07:48 AM, Michael Paquier wrote:
>>
>> Looking at the latest patch, it seems that in
>> AlterTableGetLockLevel@tablecmds.c we ought to put AT_ReAddConstraint,
>> AT_AddConstraintRecurse and AT_ProcessedConstraint under the sa
On Thu, Jan 15, 2015 at 4:05 PM, Michael Paquier
wrote:
> We are soon entering in the money time for this CF. The last month has
> been mainly a vacation period, the progress being fantomatic on many
> fronts, still there are a couple of patches that are marked as ready
> for committer:
> - Foreig
On 2015-02-12 11:44:05 -0800, Sergey Konoplev wrote:
> On Thu, Feb 12, 2015 at 11:40 AM, Andres Freund
> wrote:
> > This obviously should not be the case. I'll have a look in a couple of
> > hours. Until then you can likely just work around the problem by creating
> > the archive_status direct
On Thu, Feb 12, 2015 at 6:16 PM, Tom Lane wrote:
> I wrote:
>> Christoph Berg writes:
>>> gcc5 is lurking in Debian experimental, and it's breaking initdb.
>
>> Yeah, I just heard the same about Red Hat as well:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1190978
>> Not clear if it's an outrig
I wrote:
> Christoph Berg writes:
>> gcc5 is lurking in Debian experimental, and it's breaking initdb.
> Yeah, I just heard the same about Red Hat as well:
> https://bugzilla.redhat.com/show_bug.cgi?id=1190978
> Not clear if it's an outright compiler bug or they've just found some
> creative new
On 2/12/15 5:28 AM, Kyotaro HORIGUCHI wrote:
Hello, I changed the subject.
This mail is to address the point at hand, preparing for
registering this commitfest.
15 17:29:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20150204.172914.52110711.horiguchi.kyot...@lab.ntt.co.jp>
Tue,
Hi, dear pgsql-hackers
*1. environment*
*DB Master*
$ cat /etc/issue
CentOS release 6.5 (Final)
Kernel \r on an \m
$ uname -av
Linux l-x1.xx.cnx 3.14.29-3.centos6.x86_64 #1 SMP Tue Jan 20 17:48:32
CST 2015 x86_64 x86_64 x86_64 GNU/Linux
$ psql -U postgres
psql (9.3.5)
Type "help" for help
On 12/2/15 18:29, Tom Lane wrote:
> Ravi Kiran writes:
>> I am sorry for the late reply, when I disabled the hash join command
>> "enable_hashjoin=off" in the postgresql.conf file, it was not working. But
>> I when I used the command "set enable_hashjoin=off" command in the back
>> end. It worked
On 2/12/15 3:34 PM, Ravi Kiran wrote:
sorry for the inconvenience if caused to anyone, but as David G johnston
said, I was trying to change how the postgresql works and was not able
to figure out how it should be done. I will make sure it will be clear
from the next time. Thank you very much.
A
On 2/12/15 3:20 PM, David G Johnston wrote:
>>Does "show enable_hashjoin" say it's off? If not, I think you must've
>>fat-fingered the postgresql.conf change somehow.
>
>For future reference, posts like this belong on pgsql-performance.
>but postgres is still using the hash join algorithm ev
sorry for the inconvenience if caused to anyone, but as David G johnston
said, I was trying to change how the postgresql works and was not able to
figure out how it should be done. I will make sure it will be clear from
the next time. Thank you very much.
@Tom lane Sir, I forgot to remove the #
Ravi Kiran writes:
> I am sorry for the late reply, when I disabled the hash join command
> "enable_hashjoin=off" in the postgresql.conf file, it was not working. But
> I when I used the command "set enable_hashjoin=off" command in the back
> end. It worked.
> I am not able to understand why it
Jim Nasby-5 wrote
> On 2/10/15 9:29 AM, Tom Lane wrote:
>> Ravi Kiran <
> ravi.kolanpaka@
> > writes:
>>> yes sir, I did try the pg_ctl reload command, but its still using the
>>> hash
>>> join algorithm and not the nested loop algorithm. I even restarted the
>>> server, even then its still using
I am sorry for the late reply, when I disabled the hash join command
"enable_hashjoin=off" in the postgresql.conf file, it was not working. But
I when I used the command "set enable_hashjoin=off" command in the back
end. It worked.
I am not able to understand why it did not get disabled when I ch
On Thu, Feb 12, 2015 at 3:52 PM, Amit Kapila wrote:
>> Probably not, because many queries will scan multiple relations, and
>> we want to do all of this work just once per query.
>
> By this, do you mean to say that if there is any parallel-unsafe
> expression (function call) in query, then we won
On 2/10/15 9:29 AM, Tom Lane wrote:
Ravi Kiran writes:
yes sir, I did try the pg_ctl reload command, but its still using the hash
join algorithm and not the nested loop algorithm. I even restarted the
server, even then its still using the hash join algorithm
Does "show enable_hashjoin" say it
Christoph Berg writes:
> gcc5 is lurking in Debian experimental, and it's breaking initdb.
Yeah, I just heard the same about Red Hat as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1190978
Not clear if it's an outright compiler bug or they've just found some
creative new way to make an opt
On Thu, Feb 12, 2015 at 10:07 PM, Robert Haas wrote:
>
> On Thu, Feb 12, 2015 at 6:40 AM, Amit Kapila
wrote:
> > If we have to go this way, then isn't it better to evaluate the same
> > when we are trying to create parallel path (something like in the
> > parallel_seq scan patch - create_parallel
Hi,
gcc5 is lurking in Debian experimental, and it's breaking initdb.
There's bug reports for 9.1 and 9.4:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778070 (9.1)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778071 (9.4)
but I could reproduce it with 9.5devel (from last week) as well:
On Thu, Feb 12, 2015 at 11:40 AM, Andres Freund wrote:
> This obviously should not be the case. I'll have a look in a couple of hours.
> Until then you can likely just work around the problem by creating the
> archive_status directory.
Thank you. Just let me know if you need some extra info or
Hi.
This obviously should not be the case. I'll have a look in a couple of hours.
Until then you can likely just work around the problem by creating the
archive_status directory.
--
Please excuse brevity and formatting - I am writing this on my mobile phone.
Andres Freund
On Thu, Feb 12, 2015 at 11:13 AM, Andres Freund wrote:
>>I started getting these errors after upgrading from 9.2.8 to 9.2.10.
>>Is it something critical that requires version downgrade or I can just
>>ignore that errors?
>
> What errors are you getting in precisely which circumstances? You're usin
On 02/11/2015 04:20 PM, Abhijit Menon-Sen wrote:
At 2015-02-11 13:20:29 +0200, hlinnakan...@vmware.com wrote:
I don't follow. I didn't change configure at all, compared to your
patch.
OK, I extrapolated a little too much. Your patch didn't actually include
crc_instructions.h;
Oh, I'm sorry.
On February 12, 2015 8:11:05 PM CET, Sergey Konoplev wrote:
>Hi,
>
>On Mon, Jan 5, 2015 at 4:34 AM, Andres Freund
>wrote:
>>> >> pg_receivexlog: could not create archive status file
>>> >> "mmm/archive_status/00010003.done": No such file
>or
>>> >> directory
>>> >
>>> > Dang. Stup
Hi,
On Mon, Jan 5, 2015 at 4:34 AM, Andres Freund wrote:
>> >> pg_receivexlog: could not create archive status file
>> >> "mmm/archive_status/00010003.done": No such file or
>> >> directory
>> >
>> > Dang. Stupid typo. And my tests didn't catch it, because I had
>> > archive_direc
On 2/4/15 8:20 PM, Andrew Dunstan wrote:
>
> On 02/04/2015 06:53 PM, Tom Lane wrote:
>>> Or maybe use a make variable, like NO_DOC. I think that's preferable to
>>> adding more targets.
>> Unless we can come up with a new target name that obviously means
>> "world minus docs", the make-variable i
On 2/3/15 11:00 AM, Robert Haas wrote:
> Crazy ideas: Could we make wal_level something other than
> PGC_POSTMASTER? PGC_SIGHUP would be nice... Could we, maybe, even
> make it a derived value rather than one that is explicitly configured?
> Like, if you set max_wal_senders>0, you automatically
On Thu, Feb 12, 2015 at 3:07 PM, Thom Brown wrote:
>
> On 12 February 2015 at 16:40, Heikki Linnakangas
wrote:
>>
>> On 02/12/2015 12:40 PM, Anastasia Lubennikova wrote:
>>>
>>> Thanks for answer.
>>> Now it seems to be applied correctly.
>>
>>
>> * Documentation is missing.
>
>
> Anastasia provi
On 12 February 2015 at 16:40, Heikki Linnakangas
wrote:
> On 02/12/2015 12:40 PM, Anastasia Lubennikova wrote:
>
>> Thanks for answer.
>> Now it seems to be applied correctly.
>>
>
> * Documentation is missing.
>
Anastasia provided a documentation patch in the first email.
Thom
On Wed, Feb 11, 2015 at 3:21 PM, Robert Haas wrote:
> I think we may want a dedicated parallel-safe property for functions
> rather than piggybacking on provolatile ...
I went through the current contents of pg_proc and tried to assess how
much parallel-unsafe stuff we've got. I think there are
On 02/12/2015 12:40 PM, Anastasia Lubennikova wrote:
Thanks for answer.
Now it seems to be applied correctly.
Thanks, it would be great to get this completed.
This still leaks memory with the same test query as earlier. The leak
seems to be into a different memory context now; it used to be t
On Thu, Feb 12, 2015 at 6:40 AM, Amit Kapila wrote:
> If we have to go this way, then isn't it better to evaluate the same
> when we are trying to create parallel path (something like in the
> parallel_seq scan patch - create_parallelscan_paths())?
Probably not, because many queries will scan mul
On 12 February 2015 at 10:40, Anastasia Lubennikova wrote:
> Thanks for answer.
> Now it seems to be applied correctly.
>
(please avoid top-posting)
Thanks for the updated patch. I can confirm that it now cleanly applies
and compiles fine. I've run the tested in the SQL file you provided, and
On Thu, Feb 12, 2015 at 9:56 AM, Thom Brown wrote:
> On 12 February 2015 at 13:56, Robert Haas wrote:
>>
>> On Wed, Feb 11, 2015 at 12:55 PM, Thom Brown wrote:
>> > Today I witnessed a situation which appears to have gone down like this:
>> >
>> > - The primary server starting streaming WAL data
On Thu, Feb 12, 2015 at 9:50 AM, Tom Lane wrote:
>> My first thought is that we should form some kind of TOAST-like
>> backronym, like Serialization Avoidance Loading and Access Device
>> (SALAD) or Break-up, Read, Edit, Assemble, and Deposit (BREAD). I
>> don't think there is anything per se wro
Hi!
On Mon, Feb 9, 2015 at 11:52 PM, Thom Brown wrote:
> Google Summer of Code 2015 is approaching. I'm intending on registering
> PostgreSQL again this year.
>
> Before I do that, I'd like to have an idea of how many people are
> interested in being either a student or a mentor.
>
I'm ready t
On 12 February 2015 at 13:56, Robert Haas wrote:
> On Wed, Feb 11, 2015 at 12:55 PM, Thom Brown wrote:
> > Today I witnessed a situation which appears to have gone down like this:
> >
> > - The primary server starting streaming WAL data from segment 00A8 to the
> > standby
> > - The standby serv
Robert Haas writes:
> On Tue, Feb 10, 2015 at 3:00 PM, Tom Lane wrote:
>> BTW, I'm not all that thrilled with the "deserialized object" terminology.
>> I found myself repeatedly tripping up on which form was serialized and
>> which de-. If anyone's got a better naming idea I'm willing to adopt i
>> Hi, I need help.
>>
>> In "46.6.4.5 Change Callback"
>>
>>Note: Only changes in user defined tables that are not unlogged
>>(see UNLOGGED) and not temporary (see TEMPORARY or TEMP) can be
>>extracted using logical decoding.
>>
>> I cannot parse the sentence above. Maybe logical de
Il 02/02/15 21:48, Robert Haas ha scritto:
> On Sat, Jan 31, 2015 at 8:28 AM, Marco Nenciarini
> wrote:
>> Il 30/01/15 03:54, Michael Paquier ha scritto:
>>> On Fri, Jan 30, 2015 at 2:49 AM, Tom Lane wrote:
There is at least one other bug in that function now that I look at it:
in event
On 02/06/2015 11:50 AM, Andres Freund wrote:
On 2015-02-05 16:45:50 +0200, Heikki Linnakangas wrote:
I propose the attached, which pulls all the wait-retry logic up to
secure_read() and secure_write(). This makes the code a lot more
understandable.
Generally a good idea. Especially if we get m
Hi,
On 2015-02-12 22:55:33 +0900, Tatsuo Ishii wrote:
> Hi, I need help.
>
> In "46.6.4.5 Change Callback"
>
>Note: Only changes in user defined tables that are not unlogged
>(see UNLOGGED) and not temporary (see TEMPORARY or TEMP) can be
>extracted using logical decoding.
>
> I can
On Wed, Feb 11, 2015 at 12:55 PM, Thom Brown wrote:
> Today I witnessed a situation which appears to have gone down like this:
>
> - The primary server starting streaming WAL data from segment 00A8 to the
> standby
> - The standby server started receiving that data
> - Before 00A8 is finished, the
Hi, I need help.
In "46.6.4.5 Change Callback"
Note: Only changes in user defined tables that are not unlogged
(see UNLOGGED) and not temporary (see TEMPORARY or TEMP) can be
extracted using logical decoding.
I cannot parse the sentence above. Maybe logical decoding does not
decode a ta
On Tue, Feb 10, 2015 at 3:00 PM, Tom Lane wrote:
> I've now taken this idea as far as building the required infrastructure
> and revamping a couple of array operators to use it. There's a lot yet
> to do, but I've done enough to get some preliminary ideas about
> performance (see below).
Very im
Hi,
I've attached an updated version of the patch. This fixes the issue on
checksum calculation for segments after the first one.
To solve it I've added an optional uint32 *segno argument to
parse_filename_for_nontemp_relation, so I can know the segment number
and calculate the block number corre
On 02/12/2015 01:33 AM, Andres Freund wrote:
On 2015-02-11 14:54:03 +0200, Heikki Linnakangas wrote:
Thoughts? Can you reproduce any errors with this?
I'm on battery right now, so I can't really test much.
Did you test having an actual standby instead of pg_receivexlog? I saw
some slightly di
On Thu, Feb 12, 2015 at 12:16 AM, Noah Misch wrote:
> That is a major mark against putting the check in simplify_function(), agreed.
I do see one way to rescue that idea, which is this: put two flags,
parallelModeOK and parallelModeRequired, into PlannerGlobal. At the
beginning of planning, set
Jan Urbański writes:
> Andres Freund writes:
>
>> On 2015-02-12 09:31:27 +0100, Jan Urbański wrote:
>>> That doesn't solve the problem of the Python deadlock, where you're not at
>>> leisure to call a C function at the beginning of your module.
>>
>> We could just never unload the hooks...
>
> Th
Andres Freund writes:
> On 2015-02-12 09:31:27 +0100, Jan Urbański wrote:
>> That doesn't solve the problem of the Python deadlock, where you're not at
>> leisure to call a C function at the beginning of your module.
>
> We could just never unload the hooks...
That's what we did before 4e8162865
On Thu, Feb 12, 2015 at 1:51 AM, Robert Haas wrote:
>
>
> I think we may want a dedicated parallel-safe property for functions
> rather than piggybacking on provolatile, but that will probably also
> be changeable via ALTER FUNCTION, and stored rules won't get
> miraculously updated. So this defi
Hello, I changed the subject.
This mail is to address the point at hand, preparing for
registering this commitfest.
15 17:29:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20150204.172914.52110711.horiguchi.kyot...@lab.ntt.co.jp>
> Tue, 03 Feb 2015 10:12:12 -0500, Tom Lane wrote in
On Thu, Feb 12, 2015 at 5:44 PM, Naoya Anzai
wrote:
> Hi, Michael-san
>
> > An updated patch is attached,
>
> I'm sorry for confusing you.
>
> I think you don't have to implement this code to disable this
> feature with using value "-2".Because this use case is a rare case,
> and there is a pract
Thank you for comments. Please find attached the updated patch.
>This patch fails to compile:
>xlogreader.c:1049:46: error: extraneous ')' after condition, expected a
>statement
>blk->with_hole && blk->hole_offset <=
> 0))
This has been rectified.
>Note
On Thu, Feb 12, 2015 at 2:19 AM, Robert Haas wrote:
>
> On Tue, Feb 10, 2015 at 3:56 PM, Andres Freund
wrote:
> > On 2015-02-10 09:23:02 -0500, Robert Haas wrote:
> >> On Tue, Feb 10, 2015 at 9:08 AM, Andres Freund
wrote:
> >
> > As pointed out above (moved there after reading the patch...) I do
Thanks for answer.
Now it seems to be applied correctly.
2015-02-12 3:12 GMT+04:00 Thom Brown :
> On 11 February 2015 at 22:50, Anastasia Lubennikova <
> lubennikov...@gmail.com> wrote:
>
>> Finally there is a new version of patch (in attachments).
>> It provides multicolumn index-only scan for G
On 2015-02-12 09:31:27 +0100, Jan Urbański wrote:
>
> Andres Freund writes:
>
> > On 2015-02-09 18:17:14 +0100, Jan Urbański wrote:
> >> First of all, the current behaviour is crazy. We're setting and unsetting
> >> the
> >> locking callback every time a connection is made/closed, which is not h
Andres Freund writes:
> On 2015-02-09 18:17:14 +0100, Jan Urbański wrote:
>> First of all, the current behaviour is crazy. We're setting and unsetting the
>> locking callback every time a connection is made/closed, which is not how
>> OpenSSL is supposed to be used. The *application* using libpq
Hi, Michael-san
> An updated patch is attached,
I'm sorry for confusing you.
I think you don't have to implement this code to disable this
feature with using value "-2".Because this use case is a rare case,
and there is a practical workaround using huge value like "2e9".
(You suggested "2e9" to
85 matches
Mail list logo
