On 13/08/16 05:44, Jeff Janes wrote:
On Fri, Aug 12, 2016 at 1:40 AM, Mark Kirkwood
However your index rebuild gets you from 5 to 3 GB - does that really help
performance significantly?
It can make a big difference, depending on how much RAM you have.
Yeah - I suspect this is the issue - loa
On 14.08.2016 01:52, Andreas 'ads' Scherbaum wrote:
Attached is a patch to "do the right thing". The verification is in
"to_date()" now, the extra function is removed. Regression tests are
updated - two or three of them returned a wrong date before, and still
passed. They fail now. Documentation
>So on average in a large randomly filled index, pages
spend more time nearer 50% full than 100% full.
I think we can make this number more...controllable.
Before split we can check whether left and right pages both are in
shared buffer and if they are seriously under certain fillfactor, say
under
> > >>> I think the whole idea of a fast temporary table is that there
> > >>> are no catalog entries. If there are no catalog entries, then
> > >>> dependencies are not visible. If there ARE catalog entries, to
> > >>> what do they refer? Without a pg_class entry for the table,
> > >>> there's n
2016-08-15 11:01 GMT+02:00 Aleksander Alekseev :
> > > >>> I think the whole idea of a fast temporary table is that there
> > > >>> are no catalog entries. If there are no catalog entries, then
> > > >>> dependencies are not visible. If there ARE catalog entries, to
> > > >>> what do they refer?
> But we can change this discussion little bit different. I believe so
> solution should be *global temporary tables*. These tables has
> persistent catalogue entries. Data are joined with session. These
> tables can be effective solution of problem with temporary tables,
> can be strong benefit fo
2016-08-15 12:00 GMT+02:00 Aleksander Alekseev :
> > But we can change this discussion little bit different. I believe so
> > solution should be *global temporary tables*. These tables has
> > persistent catalogue entries. Data are joined with session. These
> > tables can be effective solution of
> 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 memory.
>
> So the changes in catalogue related to global temporary tables are
> pretty less frequently.
I'm afraid I still don't get it. Let sa
2016-08-15 12:18 GMT+02:00 Aleksander Alekseev :
> > 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 memory.
> >
> > So the changes in catalogue related to global temporary tables are
> > pre
Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us>
> In short, I think that the way to make something like this work is to
> figure out how to have "virtual" catalog rows describing a temp table.
> Or maybe to partition the catalogs so that vacuuming away temp-table
> rows is easier/cheaper th
Re: To Tom Lane 2016-08-15 <20160815111057.v2mqqjp4aabvw...@msg.df7cb.de>
> Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us>
> > In short, I think that the way to make something like this work is to
> > figure out how to have "virtual" catalog rows describing a temp table.
> > Or maybe to pa
Hi All,
While working on pg_hba_lookup function that can be used to lookup for an client
authentication that can be matched for given input parameters, Tom raised some
concrete use case issues in the following mail [1]. In this same
thread, he raised
some advantages of having a view similar like p
Thanks a lot for taking a look at this.
On 2016/08/11 3:22, Robert Haas wrote:
> On Wed, Aug 10, 2016 at 7:09 AM, Amit Langote
> wrote:
>> Attached is the latest set of patches to implement declarative
>> partitioning.
>
> Cool. I would encourage you to give some thought to what is the least
>
On 15.08.2016 10:24, Artur Zakirov wrote:
On 14.08.2016 01:52, Andreas 'ads' Scherbaum wrote:
Attached is a patch to "do the right thing". The verification is in
"to_date()" now, the extra function is removed. Regression tests are
updated - two or three of them returned a wrong date before, and
On 15.08.2016 14:33, Andreas 'ads' Scherbaum wrote:
Is it right and "true" way to validate date by extra transforming and
comparison?
Maybe validate date by using ValidateDate(). Attached sample patch.
This does not solve the problem at hand, and let's wrong dates/formats
slip through:
./buil
Why are you sending this off-list? Please let's keep the discussion
on the mailing list. I suggest resending this there.
On Mon, Aug 15, 2016 at 5:01 AM, Aleksander Alekseev
wrote:
>> > >>> I think the whole idea of a fast temporary table is that there
>> > >>> are no catalog entries. If there
On Sat, Aug 13, 2016 at 2:15 AM, Alvaro Herrera
wrote:
> Many have expressed their interest in this topic, but I haven't seen any
> design of how it should work.
That's it. My design presented at PGCon was very sketchy, and I didn't
deliver any prototype yet.
> Here's my attempt; I've been p
On 15.08.2016 13:44, Artur Zakirov wrote:
On 15.08.2016 14:33, Andreas 'ads' Scherbaum wrote:
Is it right and "true" way to validate date by extra transforming and
comparison?
Maybe validate date by using ValidateDate(). Attached sample patch.
This does not solve the problem at hand, and let'
> Why are you sending this off-list? Please let's keep the discussion
> on the mailing list. I suggest resending this there.
Sorry for that. I accidentally removed pgsql-hackers@ from CC list or
maybe my email client somehow did it for me. Short after that I realized
my mistake and sent a copy t
On Sat, Aug 13, 2016 at 4:36 AM, Amit Kapila wrote:
> AFAICS, your patch seems to be the right fix for this issue, unless we
> need the instrumentation information during execution (other than for
> explain) for some purpose.
Hmm, I disagree. It should be the job of
ExecParallelRetrieveInstrumen
Apologies, I accidentally replied off-list, here's the response I sent.
Vladimir, I suggest you reply to this message with your own response...
On Sat, Aug 13, 2016 at 6:32 PM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Shay>To be honest, the mere idea of having an SQL parser insid
On Sun, Aug 14, 2016 at 6:54 PM, konstantin knizhnik
wrote:
> Barriers are really very simple and convenient mechanism for process
> synchronization.
> But it is actually a special case of semaphores: having semaphore primitive
> it is trivial to implement a barrier.
> We have semaphores in Post
Shay> What? I really didn't understand your point here. All the doc is saying is
Shay> that if the driver doesn't support prepared statements, then using them
Please read again. PreparedStatement is the only way to execute statements
in JDBC API. There's no API that allows user to specify "use
ser
On 13/08/16 17:34, Steve Singer wrote:
On 08/05/2016 11:00 AM, Petr Jelinek wrote:
Hi,
as promised here is WIP version of logical replication patch.
Thanks for keeping on this. This is important work
Feedback is welcome.
+
+ Publication
+
+A Publication object can be defined on
> On 11 Aug 2016, at 17:43, Petr Jelinek wrote:
>
>>
>> * Also I wasn’t able actually to run replication itself =) While regression
>> tests passes, TAP
>> tests and manual run stuck. pg_subscription_rel.substate never becomes ‘r’.
>> I’ll investigate
>> that more and write again.
>
> Interes
On Sat, Aug 13, 2016 at 7:18 PM, Thomas Munro
wrote:
> I would like to propose "barriers" for Postgres processes. A barrier
> is a very simple mechanism for coordinating parallel computation, as
> found in many threading libraries.
>
> First, you initialise a Barrier object somewhere in shared me
On Sat, Aug 13, 2016 at 11:20 PM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Tatsuo>Interesting. What would happen if a user changes some of GUC
> parameters? Subsequent session accidentally inherits the changed GUC
> parameter?
>
> Yes, that is what happens.
> The idea is not to me
On 08/14/2016 04:38 PM, Tom Lane wrote:
I did a trial run following the current pgindent README procedure, and
noticed that the perltidy step left me with a pile of '.bak' files
littering the entire tree. This seems like a pretty bad idea because
a naive "git add ." would have committed them.
Andrew Dunstan writes:
> On 08/14/2016 04:38 PM, Tom Lane wrote:
>> I did a trial run following the current pgindent README procedure, and
>> noticed that the perltidy step left me with a pile of '.bak' files
>> littering the entire tree. This seems like a pretty bad idea because
>> a naive "git
14.08.2016 20:11, Andrey Borodin:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, failed
Spec compliant: tested, passed
Documentation:tested, passed
Hi hackers!
I've read th
On Thursday, 11 August 2016 3:18 PM, Artur Zakirov
wrote:
>Here is my patch. It is a proof of concept.>Date/Time
>Formatting>>There are changes in date/time formatting
>rules:-> now to_timestamp() and to_date() skip spaces in the input string and
>>in the formatting string
Vladimir>> Yes, that is what happens.
Vladimir>> The idea is not to mess with gucs.
Shay:> Wow... That is... insane...
Someone might say that "programming languages that enable side-effects
are insane".
Lots of connection pools work by sharing the connections and it is up
to developer
if he can b
On Fri, Aug 12, 2016 at 7:15 PM, Alvaro Herrera
wrote:
> Many have expressed their interest in this topic, but I haven't seen any
> design of how it should work. Here's my attempt; I've been playing with
> this for some time now and I think what I propose here is a good initial
> plan. This will
On Mon, Aug 15, 2016 at 10:56 AM, amul sul wrote:
> On Thursday, 11 August 2016 3:18 PM, Artur Zakirov
> wrote:
>
>>Here is my patch. It is a proof of concept.
>>Date/Time Formatting
>>
>>There are changes in date/time formatting rules:
> -> now to_timestamp() and to_date() sk
On Sat, Aug 13, 2016 at 6:22 PM, Tom Lane wrote:
> Jeff Janes writes:
>> I am getting corrupted Bloom indexes in which a tuple in the table
>> heap is not in the index.
>
> Will push a fix in a bit.
After 36 hours of successful running on two different machines (one
with crash injection t
On 15.08.2016 15:42, Thomas Munro wrote:
This implementation is using a spinlock for the arrival counter, and
signals (via Robert's condition variables and latches) for waking up
peer processes when the counter reaches the target. I realise that
using signals for this sort of thing is a bit un
On 8/15/16 2:33 AM, Venkata B Nagothi wrote:
> During the recovery process, It would be nice if PostgreSQL generates an
> error by aborting the recovery process (instead of starting-up the
> cluster) if the intended recovery target point is not reached and give
> an option to DBA to resume the rec
On Mon, Aug 15, 2016 at 1:58 AM, Thomas Munro
wrote:
> On Sun, Aug 14, 2016 at 9:04 AM, Thomas Munro
> wrote:
>> On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
>>> [condition-variable-v1.patch]
>>
>> Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
>
> I poked at t
On Mon, Aug 15, 2016 at 3:16 PM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Vladimir>> Yes, that is what happens.
> Vladimir>> The idea is not to mess with gucs.
>
> Shay:> Wow... That is... insane...
>
> Someone might say that "programming languages that enable side-effects
> are i
Peter Eisentraut writes:
> On 8/1/16 11:49 AM, Tom Lane wrote:
>> Somebody needs to come up with a patch implementing this changeover.
> Here is such a patch. It does not yet implement:
I've pushed this with minor additional twiddling. We can work on the
"UI issues" you mentioned at leisure.
08.08.2016 12:43, Anastasia Lubennikova:
08.08.2016 03:51, Michael Paquier:
On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera
wrote:
Anastasia Lubennikova wrote:
So there is a couple of patches. They do not cover all mentioned
problems,
but I'd like to get a feedback before continuing.
I agree
13.08.2016 02:15, Alvaro Herrera:
Many have expressed their interest in this topic, but I haven't seen any
design of how it should work. Here's my attempt; I've been playing with
this for some time now and I think what I propose here is a good initial
plan. This will allow us to write permanent
On 2016-05-25 21:13, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 22, 2016 at 4:16 PM, Piotr Stefaniak
>> wrote:
>>> I think I've managed to improve pg_bsd_indent's handling of two types of
>>> cases.
>
>> Wow, that seems pretty great. I haven't scrutinized your changes to
>> pg_bsd_inde
On 08/15/2016 10:19 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/14/2016 04:38 PM, Tom Lane wrote:
I did a trial run following the current pgindent README procedure, and
noticed that the perltidy step left me with a pile of '.bak' files
littering the entire tree. This seems like a prett
>
>
> I'm not going to respond to the part about dealing with prepared
> statements errors, since I think we've already covered that and there's
> nothing new being said. I don't find automatic savepointing acceptable, and
> a significant change of the PostgreSQL protocol to support this doesn't
>
>
> I'm not going to respond to the part about dealing with prepared
>> statements errors, since I think we've already covered that and there's
>> nothing new being said. I don't find automatic savepointing acceptable, and
>> a significant change of the PostgreSQL protocol to support this doesn't
>
Andrew Dunstan writes:
> On 08/15/2016 10:19 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> We should probably specify -bext='/', which would cause the backup files
>>> to be deleted unless an error occurred.
>> Really? That seems a bit magic, and it's certainly undocumented.
> We must be u
After doing the tedious and easily forgotten (I almost did forget)
minor version bumps for our shared libraries,
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0b9358d4406b9b45a06855d53f491cc7ce9550a9
it suddenly struck me that in the brave new two-part-version-number
world we
On Mon, Aug 15, 2016 at 3:06 PM, Tom Lane wrote:
> After doing the tedious and easily forgotten (I almost did forget)
> minor version bumps for our shared libraries,
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0b9358d4406b9b45a06855d53f491cc7ce9550a9
>
> it suddenly struck
src/timezone/README saith
When there has been a new release of Windows (probably including Service
Packs), the list of matching timezones need to be updated. Run the
script in src/tools/win32tzlist.pl on a Windows machine running this new
release and apply any new timezones that it detects
Robert Haas writes:
> On Mon, Aug 15, 2016 at 3:06 PM, Tom Lane wrote:
>> That would give us an automatic annual change in the minor version.
>> If we ever made an incompatible change in a shlib, we could advance
>> its SO_MAJOR_VERSION but keep this rule for the minor version (there's
>> no law
Recently a hacker proposed a patch to add pg_dynshmem to the list of
directories whose contents are excluded in pg_basebackup. I wasn't able
to find the original email despite several attempts.
That patch got me thinking about what else could be excluded and after
some investigation I found the f
David,
* David Steele (da...@pgmasters.net) wrote:
> Recently a hacker proposed a patch to add pg_dynshmem to the list of
> directories whose contents are excluded in pg_basebackup. I wasn't able
> to find the original email despite several attempts.
That would be here:
b4e94836-786b-6020-e1b3-
On Tue, Aug 16, 2016 at 7:19 AM, Tom Lane wrote:
> src/timezone/README saith
>
> When there has been a new release of Windows (probably including Service
> Packs), the list of matching timezones need to be updated. Run the
> script in src/tools/win32tzlist.pl on a Windows machine running thi
On 8/15/16 3:06 PM, Tom Lane wrote:
> That would give us an automatic annual change in the minor version.
> If we ever made an incompatible change in a shlib, we could advance
> its SO_MAJOR_VERSION but keep this rule for the minor version (there's
> no law that says we have to reset the minor vers
On 08/10/2016 06:41 AM, Michael Paquier wrote:
On Wed, Aug 3, 2016 at 10:58 AM, Tomas Vondra
wrote:
1) enriching the query tree with multivariate statistics info
Right now all the stuff related to multivariate statistics estimation
happens in clausesel.c - matching condition to statistics, sel
On 8/15/16 2:39 PM, David Steele wrote:
That patch got me thinking about what else could be excluded and after
some investigation I found the following: pg_notify, pg_serial,
pg_snapshots, pg_subtrans. These directories are all cleaned, zeroed,
or rebuilt on server start.
If someone wanted to
On 8/15/16 4:58 PM, Jim Nasby wrote:
On 8/15/16 2:39 PM, David Steele wrote:
That patch got me thinking about what else could be excluded and after
some investigation I found the following: pg_notify, pg_serial,
pg_snapshots, pg_subtrans. These directories are all cleaned, zeroed,
or rebuilt on
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 8/15/16 3:06 PM, Tom Lane wrote:
> > That would give us an automatic annual change in the minor version.
> > If we ever made an incompatible change in a shlib, we could advance
> > its SO_MAJOR_VERSION but keep this rule for
I wrote:
> I've pushed this with minor additional twiddling. We can work on the
> "UI issues" you mentioned at leisure. One that I noted is that psql's
> version-mismatch-warning messages aren't two-part-version aware, and
> will print "10.0" where they should say "10". Probably that fix should
On 07/10/2016 10:56 AM, Joshua D. Drake wrote:
> Hackers,
>
> This just came across my twitter feed:
>
> https://lists.freedesktop.org/archives/systemd-devel/2014-April/018373.html
>
> tl;dr; Systemd 212 defaults to remove all IPC (including SYSV memory)
> when a user "fully" logs out.
That loo
Thomas Munro writes:
> On Tue, Aug 16, 2016 at 7:19 AM, Tom Lane wrote:
>> We have certainly not been doing that on a regular basis (as best I can
>> tell, no such changes have been made since 2010). Does anybody who uses
>> Windows want to deal with it? Or at least do it once so that our Windo
Josh Berkus writes:
> On 07/10/2016 10:56 AM, Joshua D. Drake wrote:
>> tl;dr; Systemd 212 defaults to remove all IPC (including SYSV memory)
>> when a user "fully" logs out.
> That looks like it was under discussion in April, though. Do we have
> confirmation it was never fixed? I'm not seeing
Hi, hackers!
There is a known issue that index only scan (IOS) can only work with
simple index keys based on single attributes and doesn't work with index
expressions. In this patch I propose a solution that adds support of IOS
for index expressions. Here's an example:
create table abc(a int
On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote:
> Therefore, I plan to commit this patch, removing the #include
> unless someone convinces me we need it, shortly after
> development for v10 opens, unless there are objections before then.
Hearing no objections, done.
--
Robert Haas
Enterpri
On Sat, Aug 13, 2016 at 11:56 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> Being cautious pays more in the long term, so seeing the number of
>> bugs that showed up I'd rather vote for having it disabled by default
>> in 9.6 stable, and enabled on master to aim at enabling it in 10.0.
>
On 08/16/2016 12:03 AM, Ildar Musin wrote:
Hi, hackers!
There is a known issue that index only scan (IOS) can only work with
simple index keys based on single attributes and doesn't work with index
expressions. In this patch I propose a solution that adds support of IOS
for index expressions. He
On 8/15/16 5:11 PM, Stephen Frost wrote:
> Eh? Last I checked, we needed minor version bumps to ensure that
> binaries compiled against later versions, which might use newer symbols,
> don't try to link against older libraries (which wouldn't have those
> symbols).
Let's review:
What we install
On 08/15/2016 02:43 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 07/10/2016 10:56 AM, Joshua D. Drake wrote:
>>> tl;dr; Systemd 212 defaults to remove all IPC (including SYSV memory)
>>> when a user "fully" logs out.
>
>> That looks like it was under discussion in April, though. Do we have
>>
On Mon, Aug 15, 2016 at 11:19 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/14/2016 04:38 PM, Tom Lane wrote:
>>> I did a trial run following the current pgindent README procedure, and
>>> noticed that the perltidy step left me with a pile of '.bak' files
>>> littering the entire tree. T
On Tue, Aug 16, 2016 at 4:19 AM, Tom Lane wrote:
> We have certainly not been doing that on a regular basis (as best I can
> tell, no such changes have been made since 2010). Does anybody who uses
> Windows want to deal with it? Or at least do it once so that our Windows
> TZ info is less than 5
Josh Berkus writes:
> On 08/15/2016 02:43 PM, Tom Lane wrote:
>> Last I heard, there's an exclusion for "system" accounts, so an
>> installation that's using the Fedora-provided pgsql account isn't
>> going to have a problem. It's homebrew installs running under
>> ordinary-user accounts that are
Michael Paquier writes:
> The tree does not have any .bak file, and those refer to backup copies
> normally. Perhaps it would make sense to include those in root's
> .gitignore? That would save from an unfortunate manipulation of git
> add in the future.
We've generally refrained from adding thin
On 08/15/2016 05:18 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 08/15/2016 02:43 PM, Tom Lane wrote:
>>> Last I heard, there's an exclusion for "system" accounts, so an
>>> installation that's using the Fedora-provided pgsql account isn't
>>> going to have a problem. It's homebrew installs ru
On 15/08/16 15:51, Stas Kelvich wrote:
On 11 Aug 2016, at 17:43, Petr Jelinek wrote:
* Also I wasn’t able actually to run replication itself =) While regression
tests passes, TAP
tests and manual run stuck. pg_subscription_rel.substate never becomes ‘r’.
I’ll investigate
that more and write
Peter Eisentraut writes:
> On 8/15/16 5:11 PM, Stephen Frost wrote:
>> Eh? Last I checked, we needed minor version bumps to ensure that
>> binaries compiled against later versions, which might use newer symbols,
>> don't try to link against older libraries (which wouldn't have those
>> symbols).
Josh Berkus writes:
> On 08/15/2016 05:18 PM, Tom Lane wrote:
>> Well, yeah, it's easy to fix once you know you need to do so. The
>> complaint is basically that out-of-the-box, it's broken, and it's
>> not very clear what was gained by breaking it.
> You're welcome to argue with Lennart about t
On Wed, Aug 3, 2016 at 2:13 PM, Peter Geoghegan wrote:
> Since merging is a big bottleneck with this, we should probably also
> work to address that indirectly.
I attach a patch that changes how we maintain the heap invariant
during tuplesort merging. I already mentioned this over on the
"Paralle
On Mon, Aug 15, 2016 at 12:12 AM, Ryan Murphy wrote:
> This is to fix an issue that came up for me when running initdb.
>
> At the end of a successful initdb it says:
>
> Success. You can now start the database server using:
> pg_ctl -D /some/path/to/data -l logfile start
>
> but this
Robert Haas writes:
> On Sat, Aug 13, 2016 at 11:56 AM, Alvaro Herrera
> wrote:
>> I too prefer to keep it turned off in 9.6 and consider enabling it by
>> default on a future release (10 is probably good). Interested users can
>> carefully test the feature without endangering other unsuspecting
On Mon, Aug 15, 2016 at 9:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Aug 13, 2016 at 11:56 AM, Alvaro Herrera
>> wrote:
>>> I too prefer to keep it turned off in 9.6 and consider enabling it by
>>> default on a future release (10 is probably good). Interested users can
>>> carefull
Any reason why we can create a function that accepts anyelement and
returns anyarray, but can't do the same with anyrange? Could we attempt
to match each range subtype looking for a match?
create function range__create(anyelement,anyelement,text = '[]') RETURNS
anyrange LANGUAGE plpgsql AS $bo
Jim Nasby writes:
> Any reason why we can create a function that accepts anyelement and
> returns anyarray, but can't do the same with anyrange?
Because there can be more than one range type over the same element
type, so we couldn't deduce which one should be used for anyrange.
The other direc
On 08/15/2016 02:23 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/15/2016 10:19 AM, Tom Lane wrote:
Andrew Dunstan writes:
We should probably specify -bext='/', which would cause the backup files
to be deleted unless an error occurred.
Really? That seems a bit magic, and it's certainl
On 2016/07/29 23:50, Robert Haas wrote:
> On Mon, Jul 25, 2016 at 4:18 AM, 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 t
Monday, 15 August 2016 9:58 PM, Robert Haas wrote:
>On Mon, Aug 15, 2016 at 10:56 AM, amul sul wrote:
>> On Thursday, 11 August 2016 3:18 PM, Artur Zakirov
>> wrote:
[Skipped..]
>Well, what's the Oracle behavior in any of these cases? I don't think
>we can decide to change any of this behavi
On Mon, Aug 15, 2016 at 6:02 PM, Robert Haas wrote:
> On Sat, Aug 13, 2016 at 4:36 AM, Amit Kapila
> wrote:
> > AFAICS, your patch seems to be the right fix for this issue, unless we
> > need the instrumentation information during execution (other than for
> > explain) for some purpose.
>
> Hmm,
On Tue, Aug 16, 2016 at 2:50 AM, David Steele wrote:
> On 8/15/16 2:33 AM, Venkata B Nagothi wrote:
>
> > During the recovery process, It would be nice if PostgreSQL generates an
> > error by aborting the recovery process (instead of starting-up the
> > cluster) if the intended recovery target po
On 16/08/16 16:19, Andrew Dunstan wrote:
On 08/15/2016 02:23 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/15/2016 10:19 AM, Tom Lane wrote:
Andrew Dunstan writes:
We should probably specify -bext='/', which would cause the backup
files
to be deleted unless an error occurred.
Really?
Ok, I'll do that!
Thanks Michael!
Ryan
On Monday, August 15, 2016, Michael Paquier
wrote:
> On Mon, Aug 15, 2016 at 12:12 AM, Ryan Murphy > wrote:
> > This is to fix an issue that came up for me when running initdb.
> >
> > At the end of a successful initdb it says:
> >
> > Success. You can
On Tue, Aug 16, 2016 at 1:03 AM, Ildar Musin wrote:
> Hi, hackers!
>
> There is a known issue that index only scan (IOS) can only work with simple
> index keys based on single attributes and doesn't work with index
> expressions. In this patch I propose a solution that adds support of IOS for
> in
> I think it makes sense to keep calling it a table because it has all the
> logical properties of a table even though it will differ from a regular
> table on the basis of physical implementation details such as that it does
> not own physical storage. Am I missing something?
>
> >
> > + par
On Tue, Aug 16, 2016 at 9:09 AM, Oleg Bartunov wrote:
> On Tue, Aug 16, 2016 at 1:03 AM, Ildar Musin
> wrote:
> > Hi, hackers!
> >
> > There is a known issue that index only scan (IOS) can only work with
> simple
> > index keys based on single attributes and doesn't work with index
> > expressio
93 matches
Mail list logo
