On Wed, Dec 7, 2016 at 4:24 PM, Michael Paquier
wrote:
> On Tue, Dec 6, 2016 at 10:42 PM, Rahila Syed wrote:
>> Thank you for suggestion. Attached is a patch which resolves the columns
>> with literal constants as TEXT for view creation.
You may also want to add your patch to a CF so as it does
On Tue, Dec 6, 2016 at 10:42 PM, Rahila Syed wrote:
> Hello,
>
>>And ideally fix things so
>>that the type of the view column will be resolved as text, so that you
>>don't hit this condition in the first place; but there is no good that
>>comes out of allowing a view to be created like this
>
> Th
On Wed, Dec 7, 2016 at 2:49 PM, Kyotaro HORIGUCHI
wrote:
> Aside from measurement of the two sorting methods, I'd like to
> point out that quorum commit basically doesn't need
> sorting. Counting conforming santdbys while scanning the
> walsender(receiver) LSN list comparing with the target LSN is
> 6 дек. 2016 г., в 19:19, David Fetter написал(а):
>
> On Tue, Dec 06, 2016 at 10:52:47AM -0500, Tom Lane wrote:
>> Vladimir Borodin writes:
>>> Any chance to get tzdata 2016j in supported branches?
>>
>> When the next scheduled releases come around (February), we'll update
>> to whatever tzd
On 2016/12/07 15:26, Craig Ringer wrote:
> On 7 December 2016 at 07:29, legrand legrand
> wrote:
>
>> Working in a DSS environment, we often need to truncate table partitions
>> regarding a WHERE condition and have to
>> [...]
>> Would be pleased to ear your feedback regarding this.
>
> It sound
On 7 December 2016 at 14:39, Craig Ringer wrote:
> On 7 December 2016 at 04:13, Robert Haas wrote:
>
>> I wonder how feasible it would be to make this a run-time dependency
>> rather than a compile option.
>
> Or something that's compiled with the server, but produces a separate
> .so that's the
On 12/6/16 10:34 PM, Craig Ringer wrote:
In other words, we could start to separate session state from executor
state in a limited manner. That'd definitely be valuable, IMO; it's a
real shame that Pg's architecture so closely couples the two.
So - is just doing "PgInCoreBouncer" a good idea? No
On 7 December 2016 at 04:13, Robert Haas wrote:
> I wonder how feasible it would be to make this a run-time dependency
> rather than a compile option.
Or something that's compiled with the server, but produces a separate
.so that's the only thing that links to LLVM. So packagers can avoid a
depe
>
>
> Ashutosh proposed this to do the comparison:
>
> On 2016/11/22 18:28, Ashutosh Bapat wrote:
>>
>> I guess, the reason why you are doing it this way, is SELECT clause for
>> the
>> outermost query gets deparsed before FROM clause. For later we call
>> deparseRangeTblRef(), which builds the tli
On 12/6/16 6:19 PM, Tom Lane wrote:
I'm kind of mystified how a simple code restructuring could solve the
fundamental problems with a large number of backends. It sounds like
what you're describing would just push the problem around, you would
end up with some other maximum instead, max_backends,
On 7 December 2016 at 10:19, Tom Lane wrote:
> What it sounds like to me is building a connection pooler into the
> backend. I'm not really convinced we ought to go there.
If we do, it probably needs to be able to offer things that
out-of-tree ones can't.
The main things I see that you can't d
On Wed, Dec 7, 2016 at 1:57 AM, Robert Haas wrote:
> On Mon, Dec 5, 2016 at 6:20 AM, Ashutosh Bapat
> wrote:
>> 4. I am still not happy with this change
>> +/*
>> + * Since (1) the expressions in foreignrel's reltarget doesn't
>> contain
>> + * any PHVs and (2) foreignrel
On 12/6/16 1:46 PM, Adam Brusselback wrote:
BTW, it just occurred to me that having this separation would make
it relatively easy to support re-directing DML queries from a
replica to the master; if the backend throws the error indicating
you tried to write data, the connection la
On 7 December 2016 at 07:29, legrand legrand
wrote:
> Working in a DSS environment, we often need to truncate table partitions
> regarding a WHERE condition and have to
> [...]
> Would be pleased to ear your feedback regarding this.
It sounds like something that'd be useful to do on top of decla
On 7 December 2016 at 10:53, Tom Lane wrote:
> Just saw another report of what's probably systemd killing off Postgres'
> SysV semaphores, as we've discussed previously at, eg,
> https://www.postgresql.org/message-id/flat/57828C31.5060409%40gmail.com
> Since the systemd people are generally imperv
Hi,
the following query crashes master as of 4212cb7.
select ts_rewrite(
tsquery_phrase(
tsquery $$'sanct' & 'peter'$$,
tsquery $$'5' <-> '6'$$,
42),
tsquery $$'5' <-> '6'$$,
plainto_tsquery('I') );
Backtrace below.
regards,
A
At Wed, 7 Dec 2016 13:26:38 +0900, Michael Paquier
wrote in
> On Wed, Dec 7, 2016 at 12:32 PM, Fujii Masao wrote:
> > So, isn't it better to compare the performance of some algorithms and
> > confirm which is the best for quorum commit? Since this code is hot, i.e.,
> > can be very frequently e
Amit Kapila writes:
> On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich
> wrote:
>> Amit Kapila writes:
>>
>>> [2. text/x-diff; fix_hash_bucketsplit_sqlsmith_v1.patch]
>> Ok, I'll do testing with the patch applied.
Good news: the assertion hasn't fired since the patch is in.
However, these a
> Potential risks involving minor upgrades are far higher than the risks
> involved by systemd, so -1 for a backpatch seen from here.
As long as we would have a compile time switch to enable/disable the
back-patched feature, it seems it would be acceptable. In the worst
case, the back-patching cou
On Wed, Dec 7, 2016 at 1:43 PM, Robert Haas wrote:
> Urk. That sounds like a scary thing to back-patch. The fact that the
> buildfarm has reported no problems is good as far as it goes, but user
> environments can be expected to be considerably more diverse than the
> buildfarm. I wouldn't mind
Robert Haas writes:
> On Tue, Dec 6, 2016 at 9:53 PM, Tom Lane wrote:
>> I think we should give serious consideration to back-patching commit
>> ecb0d20a9, which changed the default semaphore type to unnamed-POSIX
>> on Linux.
> Urk. That sounds like a scary thing to back-patch.
I don't deny t
On Tue, Dec 6, 2016 at 9:53 PM, Tom Lane wrote:
> Just saw another report of what's probably systemd killing off Postgres'
> SysV semaphores, as we've discussed previously at, eg,
> https://www.postgresql.org/message-id/flat/57828C31.5060409%40gmail.com
> Since the systemd people are generally imp
On Wed, Nov 30, 2016 at 10:56 AM, Amit Langote wrote:
> The latest patch I posted earlier today has this implementation.
I decided to try out these patches today with #define
CLOBBER_CACHE_ALWAYS 1 in pg_config_manual.h, which found a couple of
problems:
1. RelationClearRelation() wasn't preserv
On Wed, Dec 7, 2016 at 12:32 PM, Fujii Masao wrote:
> So, isn't it better to compare the performance of some algorithms and
> confirm which is the best for quorum commit? Since this code is hot, i.e.,
> can be very frequently executed, I'd like to avoid waste of cycle as much
> as possible.
It se
On Tue, Dec 6, 2016 at 6:57 PM, Masahiko Sawada wrote:
> On Tue, Dec 6, 2016 at 1:11 PM, Fujii Masao wrote:
>> On Mon, Nov 28, 2016 at 8:03 PM, Masahiko Sawada
>> wrote:
>>> On Sat, Nov 26, 2016 at 10:27 PM, Michael Paquier
>>> wrote:
On Tue, Nov 15, 2016 at 7:08 PM, Masahiko Sawada
>>>
On 2016/12/07 5:27, Robert Haas wrote:
On Mon, Dec 5, 2016 at 6:20 AM, Ashutosh Bapat
wrote:
4. I am still not happy with this change
+/*
+ * Since (1) the expressions in foreignrel's reltarget doesn't contain
+ * any PHVs and (2) foreignrel's local_conds is empty, the t
Just saw another report of what's probably systemd killing off Postgres'
SysV semaphores, as we've discussed previously at, eg,
https://www.postgresql.org/message-id/flat/57828C31.5060409%40gmail.com
Since the systemd people are generally impervious to suggestions that
they might be mistaken, I do
Hello,
Working in a DSS environment, we often need to truncate table partitions
regarding a WHERE condition and have to:
- query the dictionnary to identify thoses partitions,
- build SQL statements,
- truncate all partitions covered by the WHERE condition
- eventually delete the rest ...
-
Greg Stark writes:
> On 5 December 2016 at 19:48, Jim Nasby wrote:
>> One solution to this would be to segregate connection handling from actual
>> backends, somewhere along the lines of separating the main loop from the
>> switch() that handles libpq commands. Benefits:
> I'm kind of mystified
Joseph Brenner writes:
> Well, my take would be that if you've taken the trouble to set an
> empty string as the PAGER that means something, and it probably means
> you don't want any pager to be used.
Yeah, on reflection that argument seems pretty persuasive. So I propose
the attached patch.
B
On 5 December 2016 at 19:48, Jim Nasby wrote:
> One solution to this would be to segregate connection handling from actual
> backends, somewhere along the lines of separating the main loop from the
> switch() that handles libpq commands. Benefits:
I'm kind of mystified how a simple code restructu
On 2016-12-06 13:27:14 -0800, Peter Geoghegan wrote:
> On Mon, Dec 5, 2016 at 7:49 PM, Andres Freund wrote:
> > I tried to address 2) by changing the C implementation. That brings some
> > measurable speedups, but it's not huge. A bigger speedup is making
> > slot_getattr, slot_getsomeattrs, slot_
Le 02/12/2016 à 02:08, Karl O. Pinc a écrit :
> On Sun, 27 Nov 2016 21:54:46 +0100
> Gilles Darold wrote:
>
>> I've attached the v15 of the patch
>> I've not applied patch patch_pg_current_logfile-v14.diff.backoff to
>> prevent constant call of logfile_writename() on a busy system (errno =
>> ENF
On Tue, Dec 6, 2016 at 3:46 PM, Stephen Frost wrote:
> Good thought, thanks!
>
> Updated patch attached with that change and I also added an Assert() to
> GetCachedPlan(), in case that code gets whacked around later and somehow
> we end up falling through without actually setting *plan.
>
> Though
>
> BTW, it just occurred to me that having this separation would make it
> relatively easy to support re-directing DML queries from a replica to the
> master; if the backend throws the error indicating you tried to write data,
> the connection layer could re-route that.
This also sounds like it
On Mon, Dec 5, 2016 at 7:49 PM, Andres Freund wrote:
> I tried to address 2) by changing the C implementation. That brings some
> measurable speedups, but it's not huge. A bigger speedup is making
> slot_getattr, slot_getsomeattrs, slot_getallattrs very trivial wrappers;
> but it's still not huge.
On Tue, Dec 6, 2016 at 11:42 PM, Asif Naeem wrote:
> Thanks for updated patch. Although EVP_CIPHER_CTX_cleanup() seems deprecated
> in OpenSSL >= 1.1.0 i.e.
>
>> # if OPENSSL_API_COMPAT < 0x1010L
>> # define EVP_CIPHER_CTX_init(c) EVP_CIPHER_CTX_reset(c)
>> # define EVP_CIPHER_CTX_clean
On Tue, Dec 06, 2016 at 12:36:41PM -0800, Andres Freund wrote:
> On 2016-12-06 15:25:44 -0500, Tom Lane wrote:
> > I'm not entirely thrilled with the idea of this being a configure-time
> > decision, because that forces packagers to decide for their entire
> > audience whether it's okay to depend o
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Dec 6, 2016 at 3:23 PM, Stephen Frost wrote:
> > Given the lack of screaming, I'll push the attached in a bit, which just
> > initializes the two variables being complained about. As mentioned,
> > there doesn't appear to be any live
On 2016-12-06 14:35:43 -0600, Nico Williams wrote:
> On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote:
> > On 2016-12-06 14:19:21 -0600, Nico Williams wrote:
> > > > I concur with your feeling that hand-rolled JIT is right out. But
> > >
> > > Yeah, that way lies maintenance madness.
On 2016-12-06 15:25:44 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-12-06 13:56:28 -0500, Tom Lane wrote:
> >> I guess the $64 question that has to be addressed here is whether we're
> >> prepared to accept LLVM as a run-time dependency. There are some reasons
> >> why we might not
On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote:
> On 2016-12-06 14:19:21 -0600, Nico Williams wrote:
> > A bigger concern might be interface stability. IIRC the LLVM C/C++
> > interfaces are not very stable, but bitcode is.
>
> The C API is a lot more stable than the C++ bit, that'
On Tue, Dec 6, 2016 at 4:00 AM, Amit Kapila wrote:
> On Tue, Dec 6, 2016 at 1:29 PM, Jeff Janes wrote:
> >
> >
> > I just occasionally insert a bunch of equal tuples, which have to be in
> > overflow pages no matter how much splitting happens.
> >
> > I am getting vacuum errors against HEAD, aft
On Tue, Dec 6, 2016 at 3:23 PM, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Not sure if anyone else has been seeing these, but I'm getting a bit
>> tired of them. Neither is a live bug, but they also seem pretty simple
>> to fix. The attached patch makes both of these w
Hi,
On 2016-12-06 14:19:21 -0600, Nico Williams wrote:
> A bigger concern might be interface stability. IIRC the LLVM C/C++
> interfaces are not very stable, but bitcode is.
The C API is a lot more stable than the C++ bit, that's the primary
reason I ended up using it, despite the C++ docs being
On Mon, Dec 5, 2016 at 6:20 AM, Ashutosh Bapat
wrote:
> 4. I am still not happy with this change
> +/*
> + * Since (1) the expressions in foreignrel's reltarget doesn't
> contain
> + * any PHVs and (2) foreignrel's local_conds is empty, the tlist
> + * created by b
Andres Freund writes:
> On 2016-12-06 13:56:28 -0500, Tom Lane wrote:
>> I guess the $64 question that has to be addressed here is whether we're
>> prepared to accept LLVM as a run-time dependency. There are some reasons
>> why we might not be:
> Indeed. It'd only be a soft dependency obviously
All,
* Stephen Frost (sfr...@snowman.net) wrote:
> Not sure if anyone else has been seeing these, but I'm getting a bit
> tired of them. Neither is a live bug, but they also seem pretty simple
> to fix. The attached patch makes both of these warnings go away. At
> least for my common build, the
On Tue, Dec 06, 2016 at 01:56:28PM -0500, Tom Lane wrote:
> Andres Freund writes:
> > I'm posting a quite massive series of WIP patches here, to get some
> > feedback.
>
> I guess the $64 question that has to be addressed here is whether we're
> prepared to accept LLVM as a run-time dependency.
On 2016-12-06 15:13:21 -0500, Robert Haas wrote:
> Presumably this is going to need to be something that a user can get
> via yum install or apt-get install on common systems.
Right. apt-get install llvm-dev (or llvm-3.9-dev or such if you want to
install a specific version), does the trick here
On Tue, Dec 6, 2016 at 2:10 PM, Andres Freund wrote:
>> * The sheer mass of the dependency. What's the installed footprint of
>> LLVM, versus a Postgres server? How hard is it to install from source?
>
> Worked for me first try, but I'm perhaps not the best person to judge.
> It does take a whil
On 2016-12-06 11:10:59 -0800, Andres Freund wrote:
> > * Are there any currently-interesting platforms that LLVM doesn't work
> > for? (I'm worried about RISC-V as much as legacy systems.)
>
> LLVM itself I don't think is a problem, it seems to target a wide range
> of platforms. The platforms th
On 2016-12-06 14:04:09 -0500, Robert Haas wrote:
> I've heard at least one and maybe several PGCon presentations about
> people JITing tuple deformation and getting big speedups, and I'd like
> to finally hear one from somebody who intends to integrate that into
> PostgreSQL.
I certainly want to.
Hi,
On 2016-12-06 13:56:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I'm posting a quite massive series of WIP patches here, to get some
> > feedback.
>
> I guess the $64 question that has to be addressed here is whether we're
> prepared to accept LLVM as a run-time dependency. There
On Tue, Dec 6, 2016 at 1:56 PM, Tom Lane wrote:
> Andres Freund writes:
>> I'm posting a quite massive series of WIP patches here, to get some
>> feedback.
>
> I guess the $64 question that has to be addressed here is whether we're
> prepared to accept LLVM as a run-time dependency. There are so
On Tue, Dec 6, 2016 at 1:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> Done.
>
> The comment seems quite confused now:
>
> * If a tuple count was supplied or data is being written to relation, we
> * must force the plan to run without parallelism, because we might exit
> * early.
>
On Tue, Dec 6, 2016 at 1:36 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 15, 2016 at 3:55 PM, Tom Lane wrote:
>>> Account for catalog snapshot in PGXACT->xmin updates.
>
>> It seems to me that this makes it possible for
>> ThereAreNoPriorRegisteredSnapshots() to fail spuriously. The
Andres Freund writes:
> I'm posting a quite massive series of WIP patches here, to get some
> feedback.
I guess the $64 question that has to be addressed here is whether we're
prepared to accept LLVM as a run-time dependency. There are some reasons
why we might not be:
* The sheer mass of the d
Robert Haas writes:
> On Tue, Nov 15, 2016 at 3:55 PM, Tom Lane wrote:
>> Account for catalog snapshot in PGXACT->xmin updates.
> It seems to me that this makes it possible for
> ThereAreNoPriorRegisteredSnapshots() to fail spuriously. The only
> core code that calls that function is in copy.c,
Robert Haas writes:
> Done.
The comment seems quite confused now:
* If a tuple count was supplied or data is being written to relation, we
* must force the plan to run without parallelism, because we might exit
* early.
Exit early is exactly what we *won't* do if writing to an INTO
On Mon, Dec 5, 2016 at 6:54 PM, Jim Nasby wrote:
> On 12/5/16 2:14 PM, David Fetter wrote:
>> What do you see as the relationship between this proposal and the
>> earlier one for admission control?
>>
>> https://www.postgresql.org/message-id/4b38c1c502250002d...@gw.wicourts.gov
>
> Without ha
On 12/5/16 6:24 PM, Petr Jelinek wrote:
> I think that the removal of changes to ReplicationSlotAcquire() that you
> did will result in making it impossible to reacquire temporary slot once
> you switched to different one in the session as the if (active_pid != 0)
> will always be true for temp slo
On Mon, Dec 5, 2016 at 5:18 AM, Albe Laurenz wrote:
> Tobias Bussmann wrote:
>>> I think if we don't see any impact then we should backpatch this
>>> patch. However, if we decide to go some other way, then I can provide
>>> a separate patch for back branches. BTW, what is your opinion?
>>
>> I co
On Tue, Dec 06, 2016 at 10:52:47AM -0500, Tom Lane wrote:
> Vladimir Borodin writes:
> > Any chance to get tzdata 2016j in supported branches?
>
> When the next scheduled releases come around (February), we'll update
> to whatever tzdata is current at that time.
I'm guessing that request came th
On Mon, Dec 5, 2016 at 4:49 AM, Amit Kapila wrote:
> I can very well understand the reason for not doing so (IIUC, it is
> about complexity and time to get it right when we are already trying
> to solve one big and complex problem of the system), but saying most
> of the benefit can be realized by
Vladimir Borodin writes:
> Any chance to get tzdata 2016j in supported branches?
When the next scheduled releases come around (February), we'll update
to whatever tzdata is current at that time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
But if it does make sense to share, then that's another reason for not
designing something ad-hoc for psql: integrating it later will be more
work in total.
Yes, but not much: evaluating "[!] :var" special syntax would be dropped,
but I do not think that it is the main issue with these featu
Hi all.
Any chance to get tzdata 2016j in supported branches?
--
May the force be with you…
https://simply.name
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-12-05 20:51:02 +, Stephen Frost wrote:
> > Add support for restrictive RLS policies
> This is missing a catversion bump.
Ewps, apologies and thanks for pointing it out.
Fixed.
Stephen
signature.asc
Description: Digital signatu
On Tue, Dec 6, 2016 at 8:45 AM, Fabien COELHO wrote:
> There are some differences: pgbench already had one operator at a time
> expressions, while psql has survived till today with none, which suggest a
> less pressing need.
I don't really think so. People have been wanting expressions in psql
s
On Tue, Nov 15, 2016 at 3:55 PM, Tom Lane wrote:
> Account for catalog snapshot in PGXACT->xmin updates.
>
> The CatalogSnapshot was not plugged into SnapshotResetXmin()'s accounting
> for whether MyPgXact->xmin could be cleared or advanced. In normal
> transactions this was masked by the fact th
Thanks for updated patch. Although EVP_CIPHER_CTX_cleanup() seems deprecated in
OpenSSL >= 1.1.0 i.e.
# if OPENSSL_API_COMPAT < 0x1010L
> # define EVP_CIPHER_CTX_init(c) EVP_CIPHER_CTX_reset(c)
> # define EVP_CIPHER_CTX_cleanup(c) EVP_CIPHER_CTX_reset(c)
> # endif
I guess use of dep
2016-12-06 16:59 GMT+09:00 Pavel Stehule :
>
>
> 2016-12-06 1:50 GMT+01:00 Kohei KaiGai :
>>
>> 2016-12-05 22:45 GMT+09:00 Pavel Stehule :
>> >
>> > There are more goals:
>> >
>> > 1. user friendly import of text or binary data - import text data (with
>> > psql) from file is possible - but you hav
Hello Robert,
Your experience as an seasoned core developer and a committer is
probably different:-)
Well, everybody can have their own opinion on what is reasonable.
Sure.
There are times I argue for making a patch smaller (frequent) and
times when I argue for making it bigger (rare).
Hello,
>And ideally fix things so
>that the type of the view column will be resolved as text, so that you
>don't hit this condition in the first place; but there is no good that
>comes out of allowing a view to be created like this
Thank you for suggestion. Attached is a patch which resolves the
On Tue, Dec 6, 2016 at 9:31 PM, Asif Naeem wrote:
> Thank you for v2 patch, I would like to comment on it. It seems that you
> have used function EVP_CIPHER_CTX_reset in the patch that was introduced in
> OpenSSL 1.1.0, older library version might not work now, is it intentional
> change ?.
I tho
On Tue, Dec 6, 2016 at 1:28 AM, Fabien COELHO wrote:
> First, my experience as a basic patch submitter is that any patch which does
> more than one thing at a time, even somehow closely related changes, is
> asked to be split into distinct sub-patches, and is harder to get through.
>
> Second, req
Hi Michael,
Thank you for v2 patch, I would like to comment on it. It seems that you
have used function EVP_CIPHER_CTX_reset in the patch that was introduced in
OpenSSL 1.1.0, older library version might not work now, is it intentional
change ?.
Regards,
Muhammad Asif Naeem
On Tue, Dec 6, 2016 a
On Tue, Dec 6, 2016 at 1:29 PM, Jeff Janes wrote:
>
>
> I just occasionally insert a bunch of equal tuples, which have to be in
> overflow pages no matter how much splitting happens.
>
> I am getting vacuum errors against HEAD, after about 20 minutes or so (8
> cores).
>
> 49233 XX002 2016-12-05
On Tue, Dec 6, 2016 at 6:57 PM, Masahiko Sawada wrote:
> On Tue, Dec 6, 2016 at 1:11 PM, Fujii Masao wrote:
>> If M (i.e., number of quorum sync standbys) is enough large,
>> your choice would be good. But usually M seems not so large.
>>
>
> Thank you for the comment.
>
> One another possible id
On Tue, Dec 6, 2016 at 1:11 PM, Fujii Masao wrote:
> On Mon, Nov 28, 2016 at 8:03 PM, Masahiko Sawada
> wrote:
>> On Sat, Nov 26, 2016 at 10:27 PM, Michael Paquier
>> wrote:
>>> On Tue, Nov 15, 2016 at 7:08 PM, Masahiko Sawada
>>> wrote:
Attached latest version patch incorporated review
On Tue, Dec 6, 2016 at 6:00 PM, Fujii Masao wrote:
> One idea is to provide the utility or extension which fsync's the specified
> files and directories (including all the files under them). It may be
> overkill,
> though. But it would be useful for other purposes, for example, we can
> improve t
On Wed, Nov 16, 2016 at 1:27 AM, Robert Haas wrote:
> On Sun, Nov 13, 2016 at 4:18 AM, Andres Freund wrote:
>> On 2016-11-08 18:18:01 -0500, Tom Lane wrote:
>>> I think this might be better addressed by adding something to backup.sgml
>>> pointing out that you'd better fsync or sync your backups
On Tue, Dec 6, 2016 at 4:54 PM, Michael Paquier
wrote:
> On Tue, Dec 6, 2016 at 4:38 PM, Fujii Masao wrote:
>> I changed the order of descriptions of the walsender state in
>> intuitive one rather than alphabetical one. Also I enhanced
>> the description of "potential" state.
>>
>> Could you revi
2016-12-06 1:50 GMT+01:00 Kohei KaiGai :
> 2016-12-05 22:45 GMT+09:00 Pavel Stehule :
> >
> > There are more goals:
> >
> > 1. user friendly import of text or binary data - import text data (with
> > psql) from file is possible - but you have to load a content to psql
> > variable. For binary data
On Thu, Dec 1, 2016 at 10:54 PM, Amit Kapila
wrote:
> On Thu, Dec 1, 2016 at 8:56 PM, Robert Haas wrote:
> > On Thu, Dec 1, 2016 at 12:43 AM, Amit Kapila
> wrote:
> >> On Thu, Dec 1, 2016 at 2:18 AM, Robert Haas
> wrote:
> >>> On Wed, Nov 23, 2016 at 8:50 AM, Amit Kapila
> wrote:
> [ new
86 matches
Mail list logo
