On Thu, Aug 18, 2016 at 3:37 PM, Michael Paquier
wrote:
> On Tue, Aug 16, 2016 at 11:06 PM, Stephen Frost
> wrote:
> > I could see supporting an additional "pause" option that means "pause at
> > the end of WAL if you don't reach the recovery target point". I'd also
> > be happy with a warning
On 16 August 2016 at 19:46, Andres Freund wrote:
> On 2016-08-15 12:02:18 -0400, Robert Haas wrote:
>> Thanks for taking a stab at this. I'd like to throw out a few concerns.
>>
>> One, I'm worried that adding an additional layer of pointer-jumping is
>> going to slow things down and make Andres'
Thank you for your corrections.
Here is the patch with suggestions taken into account, except 6th.
>6) I'd rather use alignednewsize here.
> +ItemIdSetNormal(tupid, offset + size_diff, newsize);
This behavior is accroding to ubiquitous PageAddItem.
Best regards, Andrey Borodin, Octonica & Ural
On 06/22/2016 04:41 AM, Michael Paquier wrote:
On Tue, Jun 21, 2016 at 10:46 PM, Tom Lane wrote:
Michael Paquier writes:
- mcxt.c uses that, which is surprising:
@@ -704,7 +704,8 @@ MemoryContextCreate(NodeTag tag, Size size,
{
/* Special case for startup: use good ol' malloc */
On 2016/07/25 17:18, Amit Langote wrote:
> The comment seems to have been copied from ATExecAddColumn, which says:
>
> /*
> * If we are told not to recurse, there had better not be any
> - * child tables; else the addition would put them out of step.
>
> For ATExecValidateConstraint, it should
* Venkata B Nagothi (nag1...@gmail.com) wrote:
> On Wed, Aug 17, 2016 at 11:27 PM, Stephen Frost wrote:
> > * Venkata B Nagothi (nag1...@gmail.com) wrote:
> > > Agreed. Additional option like "pause" would. As long as there is an
> > option
> > > to ensure following happens if the recovery target
On 16 August 2016 at 21:44, Craig Ringer wrote:
> On 16 August 2016 at 20:58, Greg Stark wrote:
>
>> On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer
>> wrote:
>> > I'm surprised the 32-bit xid was ever exposed to the user, rather than a
>> > 64-bit epoch-extended xid.
>>
>> Once upon a time we d
> I did *not* push the hunk in citext.sgml, since that was alleging support
> that doesn't actually exist in this patch. To make this work for citext,
> we need to add wrapper functions similar to citext's wrappers for
> regexp_matches. And that in turn means a citext extension version bump,
> wh
On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier
wrote:
> On Tue, Aug 16, 2016 at 6:22 PM, Magnus Hagander
> wrote:
> > I think what we want is basically the UNION ALL of all the different
> active
> > versions. If we just use the definitions from Win10, we will map
> incorrectly
> > on Win7. As
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>
>> I was bored and thought "how hard could it be?", and a few hours'
>> hacking later, I have something that seems to work. It doesn't do IF
>> NOT EXISTS yet, and the error messaging cou
On Tue, Aug 16, 2016 at 2:45 PM, Craig Ringer wrote:
> Hi all
>
> While implementing support for traceable transactions (finding out after the
> fact whether an xact committed or aborted), I've found that Pg is very
> inconsistent with what it considers a transaction ID from a user facing
> point
> Emre, I noticed you modified the commitfest entry
> (https://commitfest.postgresql.org/10/588/) to be for Andrew's
> transactional enum addition patch instead, but didn't change the title.
> I'll revert that as soon as it picks up this latest patch. Do you wish
> to remain a reviewer for this pa
On Thu, Aug 18, 2016 at 10:58 AM, Simon Riggs wrote:
> On 16 August 2016 at 19:46, Andres Freund wrote:
> > On 2016-08-15 12:02:18 -0400, Robert Haas wrote:
> >> Thanks for taking a stab at this. I'd like to throw out a few concerns.
> >>
> >> One, I'm worried that adding an additional layer of
On Wed, Aug 17, 2016 at 10:33 PM, Alvaro Herrera
wrote:
> Anastasia Lubennikova wrote:
>>
>> Except these, there are some pretty strange and unrelated functions in
>> src/backend/catalog.
>> I'm willing to fix them, but I'd like to synchronize our efforts.
>
> I very much would like to stay away f
Aleksander Alekseev wrote:
> $ cat ~/.psqlrc
> select (case when pg_is_in_recovery() then 'r' else 'm' end) as mor
> \gset
>
> \set PROMPT1 '%p (%:mor:) =# '
Okay, this seems moderately reasonable, but ...
> Besides I figured out that replica promotion case could also be properly
> handled wit
On Thu, Aug 18, 2016 at 7:38 PM, Magnus Hagander wrote:
> Thanks, pushed for master and 9.6.
Cool. Thanks for the commit.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/22/2016 03:02 AM, Tom Lane wrote:
Michael Paquier writes:
On Fri, Jul 22, 2016 at 8:48 AM, Tom Lane wrote:
I'm confused. We need that code in both libpq and backend, no?
src/common is the place for stuff of that description.
Not necessarily. src/interfaces/libpq/Makefile uses a set
Hello, Alvaro.
> ... this is terrible. Not only because it's a lot of code dependent
> on an external tool which will be rather heavyhanded for something
> that should probably be very lightweight, but also because the code
> itself is (no offense) an unreadable mess.
>
> I think your general id
On Thu, Aug 18, 2016 at 9:28 PM, Heikki Linnakangas wrote:
>> # This makefile generates two outputs:
>> #
>> # libpgcommon.a - contains object files with FRONTEND defined,
>> # for use by client application and libraries
>> #
>> # libpgcommon_srv.a - contains object files
Magnus Hagander writes:
> On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier
> wrote:
>> OK, so after re-running that on my Win10 station and a newly updated
>> Win7 station I am finishing with the attached that combines all the
>> changes.
> Thanks, pushed for master and 9.6.
My thought was to p
On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >> OK, so after re-running that on my Win10 station and a newly updated
> >> Win7 station I am finishing with the attached t
On 8/17/16 7:56 PM, Michael Paquier wrote:
> On Thu, Aug 18, 2016 at 1:35 AM, Alvaro Herrera
> wrote:
>> I don't remember how pg_snapshot works, but it's probably fine
>> to start with an empty subdir (is it possible to export a snapshot from
>> a prepared transaction?)
>
> From xact.c:
> /*
Magnus Hagander writes:
> On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote:
>> If we got this done in the next couple weeks, any resulting changes
>> could go out in 9.6rc1. Given that we've not done this routinely,
>> that seems like a better plan than having them first hit the field
>> in minor
On Thu, Aug 18, 2016 at 3:34 PM, Magnus Hagander
wrote:
>
>
> On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane wrote:
>
>> Magnus Hagander writes:
>> > On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote:
>> >> If we got this done in the next couple weeks, any resulting changes
>> >> could go out in 9.6r
Magnus Hagander writes:
> Done. I skipped 9.1 given it's status and that the backpatch didn't apply
> cleanly there (we moved code around).
I think the same code exists in a different file in 9.1, but I concur
that it's probably not worth a lot of effort.
regards, tom lan
On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote:
> >> If we got this done in the next couple weeks, any resulting changes
> >> could go out in 9.6rc1. Given that we've not done this routinely,
> >> that seems like a
On 08/17/2016 11:50 AM, Aleksander Alekseev wrote:
That doesn't really solve the problem, because OTHER backends won't be
able to see them. So, if I create a fast temporary table in one
session that depends on a permanent object, some other session can
drop the permanent object. If there were R
On 08/15/2016 12:23 PM, Pavel Stehule wrote:
2016-08-15 12:18 GMT+02:00 Aleksander Alekseev
mailto:a.aleks...@postgrespro.ru>>:
> The global temporary tables has persistent rows in the catalogue. The
> mapping to files can be marked as special and real mapping should be
> only in m
On Tue, Aug 16, 2016 at 9:46 PM, Andres Freund wrote:
> On 2016-08-15 12:02:18 -0400, Robert Haas wrote:
>> I am somewhat inclined to
>> believe that we need to restructure the executor in a bigger way so
>> that it passes around datums instead of tuples; I'm inclined to
>> believe that the curren
Emre Hasegeli writes:
>> I did *not* push the hunk in citext.sgml, since that was alleging support
>> that doesn't actually exist in this patch. To make this work for citext,
>> we need to add wrapper functions similar to citext's wrappers for
>> regexp_matches. And that in turn means a citext e
2016-08-18 16:33 GMT+02:00 Tomas Vondra :
> On 08/15/2016 12:23 PM, Pavel Stehule wrote:
>
>>
>>
>> 2016-08-15 12:18 GMT+02:00 Aleksander Alekseev
>> mailto:a.aleks...@postgrespro.ru>>:
>>
>> > The global temporary tables has persistent rows in the catalogue.
>> The
>> > mapping to files c
Aleksander Alekseev wrote:
> Peter has a good point that in general case it's more complicated than
> just master or replica. I also agree with David that what actually
> would be nice to have is a some syntax that allows user to execute
> arbitrary commands before displaying a prompt. This way us
On August 18, 2016 7:44:50 AM PDT, Ants Aasma wrote:
>On Tue, Aug 16, 2016 at 9:46 PM, Andres Freund
>wrote:
>> On 2016-08-15 12:02:18 -0400, Robert Haas wrote:
>>> I am somewhat inclined to
>>> believe that we need to restructure the executor in a bigger way so
>>> that it passes around datums
Gerdan Santos writes:
> I did some tests and found nothing special. The stated resource is
> implemented correctly.
> He passes all regression tests and enables the use of the new features
> specified.
> The new status of this patch is: Ready for Committer
Pushed, thanks.
Gerdan Santos writes:
> I did some tests and found nothing special. The stated resource is
> implemented correctly.
> He passes all regression tests and enables the use of the new features
> specified.
> The new status of this patch is: Ready for Committer
Pushed, thanks.
On 2016-08-18 08:58:11 +0100, Simon Riggs wrote:
> On 16 August 2016 at 19:46, Andres Freund wrote:
> > On 2016-08-15 12:02:18 -0400, Robert Haas wrote:
> >> Thanks for taking a stab at this. I'd like to throw out a few concerns.
> >>
> >> One, I'm worried that adding an additional layer of point
Attached is a patch I'd fooled around with back in July but not submitted.
The idea is that, if our initial scan of the query tree found only
parallel-safe functions, there is no need to rescan subsets of the tree
looking for parallel-restricted functions. We can mechanize that by
saving the "maxi
On 08/18/2016 03:45 PM, Michael Paquier wrote:
On Thu, Aug 18, 2016 at 9:28 PM, Heikki Linnakangas wrote:
Let's take the opportunity and also move src/backend/libpq/ip.c and md5.c
into src/common. It would be weird to have sha.c in src/common, but md5.c in
src/backend/libpq. Looking at ip.c, it
The regex library used to have a notion of a "collating element"
that was distinct from a "character", but Henry Spencer never
actually implemented support for multi-character collating elements,
and the Tcl crew ripped out most of the stubs for it years ago.
The only thing left that distinguished
On Sat, Mar 12, 2016 at 12:38 PM, Peter Geoghegan wrote:
> Only insofar as it helps diagnose the underlying issue, when it is a
> more subtle issue. Actually fixing the index is almost certainly a
> REINDEX. Once you're into the messy business of diagnosing a
> problematic opclass, you have to be
Hi Yury,
I'm interested in helping with your CMake effort. I don't have any
experience contributing to PG, but I do have some free time at the
moment. Please let me know if I can help.
I have an intermediate level of experience with CMake, Python, and
Bash scripting. My native environment is M
On 03/22/2016 03:27 PM, Aleksander Alekseev wrote:
diff --git a/src/backend/commands/tablespace.c
b/src/backend/commands/tablespace.c
index 1ff5728..a10c078 100644
--- a/src/backend/commands/tablespace.c
+++ b/src/backend/commands/tablespace.c
@@ -669,6 +669,11 @@ destroy_tablespace_directories(
I was looking at this TODO item from 2009:
https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no
I have implemented this in the attached patch. It does two things:
o compares words in columns that can only support keywords as
case-insensitive, double-quoted or not
o comp
Bruce Momjian writes:
> I was looking at this TODO item from 2009:
> https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no
> I have implemented this in the attached patch. It does two things:
Is there really enough demand for this to justify subtle breakage
of existing pg_hba.
On Tue, Aug 16, 2016 at 9:29 PM, Tom Lane wrote:
> Jim Nasby writes:
> > I can't think of any reason you'd want two different range types on a
> > single element type.
>
> We would not have built it that way if there were not clear use-cases.
> An easy example is you might want both a continuous
On 8/17/16 9:46 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial does
> not specify -c for any of the rsync commands. That's maybe safe for
> WAL, but I don't think it's safe for any of the other uses, right?
>
On 8/17/16 11:22 PM, Thomas Munro wrote:
Hi hackers,
To do something about the confusion I keep seeing about what exactly
"on" means, I've often wished we had "remote_flush". But it's not
obvious how the backwards compatibility could work, ie how to keep the
people happy who use "local" vs "on"
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 8/17/16 9:46 PM, Stephen Frost wrote:
> >* Jim Nasby (jim.na...@bluetreble.com) wrote:
> >>> https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial does
> >>> not specify -c for any of the rsync commands. That's maybe safe for
> >>> WAL, but
On 8/18/16 5:46 AM, Amit Kapila wrote:
I think there is a value in exposing such a variant which takes bigint
and internally converts it to xid. I am not sure the semantics for
I think that's a bad idea because you have the exact same problems we
have now: bigint is signed, epoch is not.
t
On Wed, Aug 17, 2016 at 3:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> I don't understand why you think this would create non-trivial
>> portability issues.
>
> The patch as submitted breaks entirely on platforms without pread/pwrite.
> Yes, we can add a configure test and some shim functions
On Wed, Aug 17, 2016 at 10:35 AM, amul sul wrote:
> Hmm. I haven't really looked into the code, but with applying both patches it
> looks precisely imitate Oracle's behaviour. Thanks.
This is good to hear, but for us to consider applying something like
this, somebody would need to look into the
On 8/18/16 10:05 AM, Alvaro Herrera wrote:
Bash has PROMPT_COMMAND, which is executed prior to issuing each prompt.
What about introducing such a feature into psql? Then the \gset command
you had in your first post could be used to set the variable correctly
just before each prompt.
As someone
On 06/29/2016 06:23 PM, Yury Zhuravlev wrote:
> Hello Hackers.
>
> I decided to talk about the current state of the project:
> 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql
> all work correctly (all tests pass).
> 3. Works done for all contrib modules. 4. You can use gett
On Thu, Aug 18, 2016 at 02:06:39PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I was looking at this TODO item from 2009:
> > https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no
> > I have implemented this in the attached patch. It does two things:
>
> Is there really e
On 8/18/16 1:31 PM, Stephen Frost wrote:
To have proper incremental backups done requires a lot more than just
throwing "-c" into the rsyncs. For my 2c, I'm at the point where I'd
prefer we discourage people from using rsync, cp, or generally try to
set up their own hand-rolled backup system wit
On 8/18/16 1:06 PM, Corey Huinker wrote:
You might also find some gleanable gems in:
https://github.com/moat/range_type_functions/blob/master/doc/range_type_functions.md
Well crap, I searched for range stuff on PGXN before creating
http://pgxn.org/dist/range_tools/ and the only thing that came
Hi Stefan,
I think I've seen similar errors when a project's CMake files assumed
a newer version of CMake than the one being run.
Which version of CMake gave you those errors? (Sorry if you provided
that detail and I'm just missing it.)
Kind regards,
Christian
On Thu, Aug 18, 2016 at 2:45 PM,
Bruce Momjian writes:
> On Thu, Aug 18, 2016 at 02:06:39PM -0400, Tom Lane wrote:
>> Is there really enough demand for this to justify subtle breakage
>> of existing pg_hba.conf entries? It'd probably have been fine if
>> we did it like that originally, but I think it's a bit late now.
> Well, i
On 8/18/16 1:59 PM, Bruce Momjian wrote:
> o compares words in columns that can only support keywords as
> case-insensitive, double-quoted or not
>
> o compares words in columns that can contain user/db names or keywords
> as case-sensitive if double-quoted, case-insensitive if not
I can maybe
On 08/18/2016 08:57 PM, Christian Convey wrote:
> Hi Stefan,
>
> I think I've seen similar errors when a project's CMake files assumed
> a newer version of CMake than the one being run.
>
> Which version of CMake gave you those errors? (Sorry if you provided
> that detail and I'm just missing it
Thanks,
But I don't think my question was clear enough.
I already managed the connection pooling, and what I need is to serialize
the result.
If PGresult was a contiguous block, I could have just create buffer and
call memcpy for serialization, but structure of result seems much more
complicated.
Robert Haas writes:
> Well, I think you're pointing out some things that need to be figured
> out, but I hardly think that's a good enough reason to pour cold water
> on the whole approach.
If somebody feels like doing the legwork to find out if those performance
hazards are real (which I freely
Stefan Kaltenbrunner writes:
> On 08/18/2016 08:57 PM, Christian Convey wrote:
>> Which version of CMake gave you those errors? (Sorry if you provided
>> that detail and I'm just missing it.)
> % cmake --version
> cmake version 2.8.10.2
> a quick look in the docs does not seem to reveal any kin
Hi Karl,
I'll need to let Yury answer your original question regarding the best
way to report CMake-related bugs.
Regarding the errors you're getting... I just looked at CMake's
online documentation regarding your "target_compile_definitions"
error.
>From what I can tell, the "target_compile_de
On 3/22/16 9:27 AM, Aleksander Alekseev wrote:
> diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
> index 28f9fb5..45aa802 100644
> --- a/src/backend/libpq/hba.c
> +++ b/src/backend/libpq/hba.c
> @@ -1008,14 +1008,9 @@ parse_hba_line(List *line, int line_num, char
> *raw_line)
>
Andres Freund wrote:
> This commit also adds a isolationtester spec test, exercising the
> relevant code path. Unfortunately 9.5 cannot handle two waiting
> sessions, and thus cannot execute this test.
This test seems to fail randomly, depending on which session is awakened
first. Annoying ...
Juergen Hannappel writes:
> A new option -T --exlude-table for pg_dumpall. This option is then
> passed through to the pg_dump which really does the work.
> This feature can be used to exclude large tables that are known not
> to change from a database backup dump so that only the changing parts
>
On 08/18/2016 09:30 PM, Christian Convey wrote:
> Hi Karl,
>
> I'll need to let Yury answer your original question regarding the best
> way to report CMake-related bugs.
>
> Regarding the errors you're getting... I just looked at CMake's
> online documentation regarding your "target_compile_defi
Hi Tom,
Thanks for that information.
Is there some document I can read that explains which platform
versions (e.g., OpenBSD 5.3) are considered strongly supported?
I ask because I'm curious if/how someone in Yury's situation could
predict which minimum version of CMake must be supported in order
On Aug 18, 2016, at 11:49 AM, Jim Nasby wrote:
> Well crap, I searched for range stuff on PGXN before creating
> http://pgxn.org/dist/range_tools/ and the only thing that came up was your
> range_partitioning stuff, which AFAICT is unrelated.
> http://pgxn.org/dist/range_type_functions/still d
Stefan Kaltenbrunner wrote:
> On 08/18/2016 09:30 PM, Christian Convey wrote:
> > Yury: Would it make sense to add a call to "cmake_minimum_required" in
> > one or more of your CMakeLists.txt files?
>
> it would make sense nevertheless but I dont think that 2.8.11 is old
> enough - looking at the
On 08/18/2016 09:42 PM, Christian Convey wrote:
> Hi Tom,
>
> Thanks for that information.
>
> Is there some document I can read that explains which platform
> versions (e.g., OpenBSD 5.3) are considered strongly supported?
well not sure we have very clear document on that - I would say that the
Hi Stefan,
>> Yury: Would it make sense to add a call to "cmake_minimum_required" in
>> one or more of your CMakeLists.txt files?
>
> it would make sense nevertheless but I dont think that 2.8.11 is old
> enough - looking at the release information and the feature compatibily
> matrix it would see
On 08/18/2016 09:52 PM, Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
>> On 08/18/2016 09:30 PM, Christian Convey wrote:
>
>>> Yury: Would it make sense to add a call to "cmake_minimum_required" in
>>> one or more of your CMakeLists.txt files?
>>
>> it would make sense nevertheless but I don
Hi Tom,
>> I ask because I'm curious if/how someone in Yury's situation could
>> predict which minimum version of CMake must be supported in order for
>> his patch to be accepted. (And if he accepts my offer to pitch in,
>> I'll actually need that particular detail.)
>
> well I personally think t
Christian Convey wrote:
> * Allow the CMake-based build system to assume a fairly modern version
> of CMake. (Maybe 2.8.12, or 3.0.)
>
> * For systems where the minimum CMake version isn't readily available,
> have an alternative build system which is just a simplistic Bash
> script that naively
>
> I don't think we're interested in maintaining more build systems than we
> already are. If cmake can replace the current MSVC tooling and
> autoconf, all in one, my impression is that we're in. If we're
> replacing two tools we've hammered pretty well over the years with two
> tools that we h
On Wed, Aug 17, 2016 at 10:54 PM, Claudio Freire wrote:
> The attached patch tries to maintain the initial status of B-Tree
> indexes, which are created with equal-key runs in physical order,
> during the whole life of the B-Tree, and make key-tid pairs
> efficiently searchable in the process.
I
Christian Convey wrote:
> I see. In other projects I've worked on, the configuration of a build
> farm has been driven by some list of platforms that were considered
> important to support.
Build farm members are systems that somebody has seen as interesting
enough that they deserve enough effor
On 2016-08-18 15:55:20 -0400, Christian Convey wrote:
> * Allow the CMake-based build system to assume a fairly modern version
> of CMake. (Maybe 2.8.12, or 3.0.)
>
> * For systems where the minimum CMake version isn't readily available,
> have an alternative build system which is just a simplist
On Wed, Aug 17, 2016 at 11:18 PM, Andres Freund wrote:
> On August 17, 2016 8:15:56 PM PDT, Michael Paquier
> wrote:
>
>>+{ /* pg_ctl command w path, properly quoted */
>>+PQExpBuffer pg_ctl_path = createPQExpBuffer();
>>+printfPQExpBuffer(pg_ctl_path, "%s%spg_ctl
On 2016-08-18 16:11:27 -0400, Robert Haas wrote:
> On Wed, Aug 17, 2016 at 11:18 PM, Andres Freund wrote:
> > On August 17, 2016 8:15:56 PM PDT, Michael Paquier
> > wrote:
> >
> >>+{ /* pg_ctl command w path, properly quoted */
> >>+PQExpBuffer pg_ctl_path = createPQExpBuffer
On Thu, Aug 18, 2016 at 4:15 PM, Andres Freund wrote:
> On 2016-08-18 16:11:27 -0400, Robert Haas wrote:
>> On Wed, Aug 17, 2016 at 11:18 PM, Andres Freund wrote:
>> > On August 17, 2016 8:15:56 PM PDT, Michael Paquier
>> > wrote:
>> >
>> >>+{ /* pg_ctl command w path, properly quoted *
Hi Stefan,
>> I ask because I'm curious if/how someone in Yury's situation could
>> predict which minimum version of CMake must be supported in order for
>> his patch to be accepted. (And if he accepts my offer to pitch in,
>> I'll actually need that particular detail.)
>
> well I personally thin
On Thu, Aug 18, 2016 at 12:22 AM, Thomas Munro
wrote:
> To do something about the confusion I keep seeing about what exactly
> "on" means, I've often wished we had "remote_flush". But it's not
> obvious how the backwards compatibility could work, ie how to keep the
> people happy who use "local"
Christian Convey writes:
>> well I personally think the level to meet would be that all the systems
>> on the buildfarm that can build -HEAD at the time the patch is proposed
>> for a commit should be able to build using the new system with whatever
>> cmake version is available in those by defaul
On Thu, Aug 18, 2016 at 3:22 PM, Robert Haas wrote:
> On Thu, Aug 18, 2016 at 4:15 PM, Andres Freund wrote:
> > On 2016-08-18 16:11:27 -0400, Robert Haas wrote:
> >> On Wed, Aug 17, 2016 at 11:18 PM, Andres Freund
> wrote:
> >> > On August 17, 2016 8:15:56 PM PDT, Michael Paquier <
> michael.pa
On Thu, Aug 18, 2016 at 5:15 AM, Amit Langote
wrote:
> On 2016/07/25 17:18, Amit Langote wrote:
>> The comment seems to have been copied from ATExecAddColumn, which says:
>>
>> /*
>> * If we are told not to recurse, there had better not be any
>> - * child tables; else the addition would put th
On Thu, Aug 18, 2016 at 5:05 PM, Robert Haas wrote:
> On Wed, Aug 17, 2016 at 10:54 PM, Claudio Freire
> wrote:
>> The attached patch tries to maintain the initial status of B-Tree
>> indexes, which are created with equal-key runs in physical order,
>> during the whole life of the B-Tree, and ma
Ryan Murphy writes:
> On Thu, Aug 18, 2016 at 3:22 PM, Robert Haas wrote:
+{ /* pg_ctl command w path, properly quoted */
+PQExpBuffer pg_ctl_path = createPQExpBuffer();
+printfPQExpBuffer(pg_ctl_path, "%s%spg_ctl",
>> I think it's worth reducing th
On 8/18/16 4:23 PM, Christian Convey wrote:
> What standard would you suggest for those platforms which don't have
> an obvious default version of CMake?
In the olden days, when many platforms we supported didn't come with GNU
make or other GNU tools or even a compiler, we collected a lot of
pract
On Thu, Aug 18, 2016 at 03:01:48PM -0400, Peter Eisentraut wrote:
> On 8/18/16 1:59 PM, Bruce Momjian wrote:
> > o compares words in columns that can only support keywords as
> > case-insensitive, double-quoted or not
> >
> > o compares words in columns that can contain user/db names or keywords
On Thu, Aug 18, 2016 at 3:44 PM, Tom Lane wrote:
> Ryan Murphy writes:
> > On Thu, Aug 18, 2016 at 3:22 PM, Robert Haas
> wrote:
> +{ /* pg_ctl command w path, properly quoted */
> +PQExpBuffer pg_ctl_path = createPQExpBuffer();
> +printfPQExpBuffe
On Thu, Aug 18, 2016 at 12:39 PM, Tom Lane wrote:
> Attached is a patch I'd fooled around with back in July but not submitted.
> The idea is that, if our initial scan of the query tree found only
> parallel-safe functions, there is no need to rescan subsets of the tree
> looking for parallel-restr
I have a query which contains a where clause like:
aid =ANY(VALUES (1),(45),(87), <6948 more>, (447))
for example:
perl -le 'print "explain (analyze) select sum(abalance) from
pgbench_accounts where aid=ANY(VALUES "; print join ",", map "($_)", sort
{$a<=>$b} map int(rand(500)), 1..6952
On Thu, Aug 18, 2016 at 3:41 PM, Claudio Freire wrote:
> It also makes index scans of the form
>
> SELECT * FROM t WHERE some_col = some_const;
>
> Scan the heap in sequential order, even if some_col has low
> cardinality (ie: the query returns lots of tuples), which is a nice
> performance side
Robert Haas writes:
> I have reviewed this and it looks good to me. My only comment is that
> this comment is slightly confusing:
> ! * Returns the first of PROPARALLEL_UNSAFE, PROPARALLEL_RESTRICTED, or
> ! * PROPARALLEL_SAFE that can be found in the given parsetree. We use this
> "First" m
On Thu, Aug 18, 2016 at 6:04 PM, Kevin Grittner wrote:
> On Thu, Aug 18, 2016 at 3:41 PM, Claudio Freire
> wrote:
>
>> It also makes index scans of the form
>>
>> SELECT * FROM t WHERE some_col = some_const;
>>
>> Scan the heap in sequential order, even if some_col has low
>> cardinality (ie: th
On Thu, Aug 18, 2016 at 1:41 PM, Claudio Freire wrote:
> In fact, that's why non-leaf index tuples need a different format,
> because while leaf index tuples contain the heap pointer already,
> non-leaf ones contain only the downlink, not the pointer into the
> heap. To be able to do comparisons a
Claudio Freire wrote:
> Unique indexes still need to scan all duplicates to check visibility
> and will become O(N^2) there.
That scenario doesn't matter, because on unique indexes there aren't
many duplicate values anyway -- only one can be a live tuple.
--
Álvaro Herrerahttp:/
1 - 100 of 141 matches
Mail list logo
