Hi, Amit
Thanks for your reply.
Your explanation is very easy to understand :)
On Wednesday, November 28, 2018 2:52 PM, Amit Langote wrote:
>Keeping aside the fact that making a generic plan gets increasing more
>expensive as the number of partitions increases, I'm a bit surprised that you
>ge
Hi Michael,
On 2018/11/29 16:27, Michael Paquier wrote:
> Hi all,
>
> d5eec4ee has added pg_partition_tree, unfortunately it is not showing in
> the documentation index. Please see attached to fix the mistake.
Oh, I wasn't aware of this index and that the tag is meant for
that.
> Any thoughts
>
> I'm a little bit reluctant for us to write and maintain more and more
> format styles, especially one as subjective and varied as markdown. I
> imagine we will constantly be bombarded with "this isn't quite right" or
> "this isn't compatible with github".
>
>
I understand your concern. It's a
Hi all,
d5eec4ee has added pg_partition_tree, unfortunately it is not showing in
the documentation index. Please see attached to fix the mistake.
Any thoughts or objections?
--
Michael
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 09c77db045..112d962824 100644
--- a/doc/src/
On Fri, Mar 16, 2018 at 10:18:59AM +0900, Michael Paquier wrote:
> So based on the feedback here is what we could at least do now as a
> minimal fix set, in the shape of:
> - Patch functions in information_schema.sql, using either operator() or
> SET search_path.
> - Patch function qualifications I
Hi, David
On Wednesday, November 28, 2018 1:23 PM David Rowley wrote:
> > I found that making a generic plan of SELECT/UPDATE/DELETE for a table
> partitioned into thousands is slow.
> > Especially, UPDATE/DELETE statement is too slow.
>
> It's quite well known and also documented [1] that this i
Hi Stephen,
On Thu, Sep 27, 2018 at 06:49:26PM -0400, Stephen Frost wrote:
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> On Thu, Sep 06, 2018 at 09:20:15AM -0700, Michael Paquier wrote:
>>> Attached is a patch with more comments about the intents of the test
>>> suite, and the separate issue
On Mon, Nov 26, 2018 at 02:48:39PM +0900, myungkyu.lim wrote:
> So I selected 'reply_time' because 'timestamp' was not used in stat
> field.
Fine by me. Could you send a new patch please? I am switching the
patch as waiting on author for now.
--
Michael
signature.asc
Description: PGP signature
On Thu, Nov 22, 2018 at 03:47:11PM +0100, Pavel Stehule wrote:
> I have not feel well when I see in one report numbers 40 and 16, I see much
> more comfortable when I see 24 and 16, but for this I need a different
> perspective
>
> What do you think about it?
Maybe, my thought is that this would
On Fri, Nov 23, 2018 at 05:13:24PM +0300, Sergey Cherkashin wrote:
> The attached patches are applied sequentially: first 0003-
> psql_add_am_info.patch, then 0003-psql_add_index_info.patch.
Thanks for doing a split. I have been looking at add_am to being with,
which is the first one in the set.
Stephen Frost writes:
> We, today, have a baked in assumption that any function marked as
> immutable will remain immutable across all major versions that we allow
> indexes to be retained through, which is all of them since about 8.3 at
> this point.
That's the ideal situation, yes.
> I don't a
On Thu, Nov 29, 2018 at 09:09:48AM +0530, Amit Kapila wrote:
> On Thu, Nov 29, 2018 at 8:46 AM Michael Paquier wrote:
>> With option 4 (as defined in [1]), the database ID or the user ID set to
>> 0 means that we don't apply any filter on them, which is sensible. Now,
>> we have query IDs which c
On Wed, 2018-11-28 at 21:17 -0500, Stephen Frost wrote:
> I don't agree that we can simply declare that all functional and partial
> indexes have to be rebuilt between every major version upgrade, which is
> the alternative. There really isn't another option- either we're
> extremely careful and t
At Wed, 28 Nov 2018 21:17:17 -0500, Stephen Frost wrote in
<20181129021717.gt3...@tamriel.snowman.net>
> Greetings,
>
> * Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote:
> > At Tue, 27 Nov 2018 06:33:42 +0100, Laurenz Albe
> > wrote in <8dcb0bb248e9aaef0f1ef0faa27ab583bfa5bb84.ca...
(2018/11/28 23:31), Bruce Momjian wrote:
On Wed, Nov 28, 2018 at 08:51:54AM -0500, Bruce Momjian wrote:
On Wed, Nov 28, 2018 at 10:46:51AM -0300, Alvaro Herrera wrote:
On 2018-Nov-28, Bruce Momjian wrote:
On Wed, Nov 28, 2018 at 03:25:34PM +0900, Etsuro Fujita wrote:
Here is a small patch fo
Hello.
Sorry for not getting into this but I'm looking forward to this.
(I'm tired to insert '--help' to the top of argument list..)
This patch still applies to the current master but ecpg.c.
At Sun, 22 Jul 2018 16:13:20 -0400 (EDT), Fabien COELHO
wrote in
>
> Hello
>
> My 0.02€:
>
> > Tha
On Thu, Nov 29, 2018 at 8:46 AM Michael Paquier wrote:
>
> On Wed, Nov 28, 2018 at 10:43:35AM -0300, Alvaro Herrera wrote:
> > On 2018-Nov-28, Amit Kapila wrote:
> >> The problem with this idea is that if someone specifies a particular
> >> parameter using query and the query doesn't return any pa
On Wed, Nov 28, 2018 at 10:43:35AM -0300, Alvaro Herrera wrote:
> On 2018-Nov-28, Amit Kapila wrote:
>> The problem with this idea is that if someone specifies a particular
>> parameter using query and the query doesn't return any parameters,
>> then it can lead to inadvertent behavior. For exampl
On Wed, Nov 28, 2018 at 7:13 PM Alvaro Herrera wrote:
>
> On 2018-Nov-28, Amit Kapila wrote:
>
> > The problem with this idea is that if someone specifies a particular
> > parameter using query and the query doesn't return any parameters,
> > then it can lead to inadvertent behavior. For example,
On Wed, Nov 28, 2018 at 02:38:04PM +0100, Daniel Verite wrote:
> -A and --csv each select an output format, and since
> there can be only one output format active, they are
> mutually exclusive.
>
> When options conflict, the rightmost on the command line wins,
> so -A --cvs is the same as --csv,
Greetings,
* Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote:
> At Tue, 27 Nov 2018 06:33:42 +0100, Laurenz Albe
> wrote in <8dcb0bb248e9aaef0f1ef0faa27ab583bfa5bb84.ca...@cybertec.at>
> > On Mon, 2018-11-26 at 19:51 -0500, Stephen Frost wrote:
> > > If a function's results can change
On Wed, Nov 28, 2018 at 12:32:29PM -0500, David Steele wrote:
> Looks good to me.
Thanks David for the input. I think that I will be able to finish
wrapping and commit this stuff tomorrow.
--
Michael
signature.asc
Description: PGP signature
On Fri, Nov 23, 2018 at 09:43:45AM +0900, Michael Paquier wrote:
> That's for the main regression test suite within src/test/regress, TAP
> is also a regression test suite, the page of the link reflects the
> general set of test suites available.
The main patch had to be reverted a couple of days
At Tue, 27 Nov 2018 06:33:42 +0100, Laurenz Albe
wrote in <8dcb0bb248e9aaef0f1ef0faa27ab583bfa5bb84.ca...@cybertec.at>
> On Mon, 2018-11-26 at 19:51 -0500, Stephen Frost wrote:
> > If a function's results can change across minor or major versions, we
> > shouldn't be marking it as immutable becau
On Thu, Nov 29, 2018 at 2:11 PM Michael Paquier wrote:
> On Wed, Nov 28, 2018 at 09:55:37AM -0600, Jeremy Finzel wrote:
> > I noticed that the way the test module worker_spi is written, it will
> > execute the main loop SQL one more time after it gets a sigterm, THEN exit
> > 1. This was surprisi
On Wed, Nov 28, 2018 at 10:00:00AM +0900, Michael Paquier wrote:
> Okay, no problem with that.
Both things have been committed, but not back-patched.
--
Michael
signature.asc
Description: PGP signature
On Thu, Nov 29, 2018 at 1:40 PM Ideriha, Takeshi
wrote:
> I found a minor typo in dsa.c.
>
> s/set_dsa_size_limit/dsa_set_size_limit/
Thanks! Pushed.
--
Thomas Munro
http://www.enterprisedb.com
On Wed, Nov 28, 2018 at 09:55:37AM -0600, Jeremy Finzel wrote:
> I noticed that the way the test module worker_spi is written, it will
> execute the main loop SQL one more time after it gets a sigterm, THEN exit
> 1. This was surprising to me where I used this module as a pattern for my
> own back
Hi.
I found a minor typo in dsa.c.
s/set_dsa_size_limit/dsa_set_size_limit/
regards,
==
Takeshi Ideriha
Fujitsu Limited
0001-Minor-typo-in-dsa.c.patch
Description: 0001-Minor-typo-in-dsa.c.patch
As we do make significant(?) use of the ssl-ish stuff - though not of the views
- should I weigh in?
We do make some not-insignificant use of the sslinfo data, but I see little
issue with adding underscores. In fact, ssl-ville is replete with underscores
anyway.
Further, I’m not sure exposing
On Tue, Nov 27, 2018 at 11:40:25AM +0900, Michael Paquier wrote:
> Thanks Paul for double-checking. I'll come back to this patch in two
> days, look at it again and commit it if there are no objections from
> others.
Committed and back-patched down to 9.4. Thanks Paul for the report!
--
Michael
>>> Hi, it makes sense to me. One can submit transaction again same as
>>> other cases you mentioned.
>>>
>>> I didn't attach the patch but according to my simple experiment in
>>> psql the output would become the following:
>>>
>>> FATAL: terminating connection due to idle-in-transaction timeout
On 11/26/18 2:25 PM, Surafel Temesgen wrote:
>
>
> On Sat, Nov 24, 2018 at 5:09 AM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
>
> 1) While comparing this to the FILTER clause we already have for
> aggregates, I've noticed the aggregate version is
>
> FILTER '
On Thu, 29 Nov 2018 at 08:17, Steve Crawford
wrote:
> Both for my edification and as a potentially important documentation detail,
> do operations that rebuild the table such as CLUSTER or pg_repack reclaim the
> column space?
I've never used pg_repack, but CLUSTER will reform the tuples so tha
On Thu, 29 Nov 2018 at 07:06, Peter Eisentraut
wrote:
>
> That last sentence about the dropped columns is confusing to me:
>
> +
> + Columns which have been dropped from the table also contribute to the
> + maximum column limit, although the dropped column values for newly
> + crea
It's a real problem. I saw this pattern more than once already.
The people have several schemas with identical data structures as a
preparation to eventual migration of the schema to its own server in the
cloud.
So you have ten schemas, one generic user from connection pool and
pg_stat_statemen
On 27/11/2018 08:42, Iwata, Aya wrote:
> I created a new version patch. Please find attached my patch.
This does not excite me. It seems mostly redundant with using tcpdump.
If I were to debug networking problems, I wouldn't even trust this very
much because it relies on the willpower of all fut
On 11/27/18 9:59 AM, Kyotaro HORIGUCHI wrote:
> ...
>
> v10-0001-sequential-scan-for-dshash.patch
> v10-0002-Add-conditional-lock-feature-to-dshash.patch
> fixed.
> v10-0003-Make-archiver-process-an-auxiliary-process.patch
> fixed.
> v10-0004-Shared-memory-based-stats-collector.patch
> updat
Thomas Munro writes:
>> On 25/11/2018 23:14, Tom Lane wrote:
>>> Also, I noticed on a fresh FreeBSD 12.0 installation that what
>>> I've got is [ python2.7 and python3.6 ]
> Confirmed that if you pkg install python2 and python3 meta-packages on
> a FreeBSD box you get python2 and python3 commands
Alvaro Herrera writes:
> On 2018-Nov-28, Tom Lane wrote:
>> This would also entail rather significant overhead to find out schema
>> names and interpolate them into the text.
> True. I was thinking that the qualified-names version of the query
> would be obtained via ruleutils or some similar me
On Wed, Nov 28, 2018 at 2:14 AM Peter Eisentraut
wrote:
> On 25/11/2018 23:14, Tom Lane wrote:
> > Also, I noticed on a fresh FreeBSD 12.0 installation that what
> > I've got is
> >
> > $ ls /usr/bin/pyth*
> > ls: /usr/bin/pyth*: No such file or directory
> > $ ls /usr/local/bin/pyth*
> > /usr/loc
On 11/28/18 10:46 PM, Alvaro Herrera wrote:
> On 2018-Nov-28, Tom Lane wrote:
>
>> Sergei Agalakov writes:
>>> It would help to analyze performance issues if pg_stat_statements would
>>> extend the object names to the qualified names.
>>
>> What pg_stat_statements puts out is the original que
On 28/11/2018 09:59, Lætitia Avrot wrote:
> First, thanks to have read that whole mail and sorry I didn't mean to
> make it so long...
> Then I'd like to know ***what you think about what I'm about to do***
> before heading in a wrong direction.
I'm a little bit reluctant for us to write and maint
On 2018-Nov-28, Tom Lane wrote:
> Sergei Agalakov writes:
> > It would help to analyze performance issues if pg_stat_statements would
> > extend the object names to the qualified names.
>
> What pg_stat_statements puts out is the original query text. As was
> already pointed out to you, changi
Peter Eisentraut writes:
> My suggestion is to either
> - Change the probe order to python, python3 in master, or
> - Don't change anything until PEP 394 is updated.
It's hard to evaluate the latter unless we have some idea how soon
that update is likely to happen ... have you heard any little bi
Sergei Agalakov writes:
> It would help to analyze performance issues if pg_stat_statements would
> extend the object names to the qualified names.
What pg_stat_statements puts out is the original query text. As was
already pointed out to you, changing that text is likely to break
use-cases in
On 27/11/2018 18:30, Andres Freund wrote:
> ISTM we should first go for python, python2, python3 in all branches,
> and then have a separate master only commit that changes over the order
> to prefer python3 over 2. I don't think preferring 3 over 2 would be
> appropriate for past branches, but it'
On Thu, Nov 29, 2018 at 3:30 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Wed, Nov 28, 2018 at 6:47 PM Tom Lane wrote:
> >> Is it possible that unlink() on APFS is not atomic?
>
> > I think you might be right.
> > https://github.com/macdice/unlinktest
>
> Bleah. But you can do better than a
Hi,
It would help to analyze performance issues if pg_stat_statements would
extend the object names to the qualified names.
Currently if we have two schemas ( say s1 and s2) with the objects with
the same name ( say tables t1) then after the next executions:
set schema 's1';
select count(*) f
Bruce Momjian writes:
> On Wed, Nov 28, 2018 at 06:31:59PM +0100, Peter Eisentraut wrote:
>> Any thoughts from others about whether to rename clientdn to client_dn
>> to allow better naming of the new fields?
> Makes sense. The SSL acronyms can get very complex.
+1. It seems unlikely to me tha
On 04/11/2018 12:20, Fabien COELHO wrote:
> Shouldn't psql tab completion be updated as well?
Done. (I only did the AND CHAIN, not the AND NO CHAIN.)
> I must admit that do not like much the three global variables &
> Save/Restore functions. I'd suggest saving directly into 3 local variables
>
Hi!
On Sat, Nov 24, 2018 at 11:03 PM Tomas Vondra
wrote:
> I've done another round of reviews on v20, assuming the patch is almost
> ready to commit, but unfortunately I ran into a bunch of issues that
> need to be resolved. None of this is a huge issue, but it's also above
> the threshold of wha
Le mer. 28 nov. 2018 à 16:25, Daniel Verite a
écrit :
> Lætitia Avrot wrote:
>
> > # The result I want
> > From points 3 and 4, here is what I'd like to see :
> >
> > | Header 1 | Header 2 | Header 3 |
> > |--|--|--|
> > | content | content | content |
> > | conten
On Wed, Nov 28, 2018 at 10:06 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> That last sentence about the dropped columns is confusing to me:
>
> +
> + Columns which have been dropped from the table also contribute to the
> + maximum column limit, although the dropped
That last sentence about the dropped columns is confusing to me:
+
+ Columns which have been dropped from the table also contribute to the
+ maximum column limit, although the dropped column values for newly
+ created tuples are internally marked as NULL in the tuple's null
bitmap,
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Nov 28, 2018 at 06:31:59PM +0100, Peter Eisentraut wrote:
> > On 20/11/2018 22:41, Peter Eisentraut wrote:
> > >>> - Adds new fields to pg_stat_ssl: issuerdn and clientserial. These
> > >>> allow uniquely identifying the client certif
On Wed, Nov 28, 2018 at 06:31:59PM +0100, Peter Eisentraut wrote:
> On 20/11/2018 22:41, Peter Eisentraut wrote:
> >>> - Adds new fields to pg_stat_ssl: issuerdn and clientserial. These
> >>> allow uniquely identifying the client certificate. AFAICT, these are
> >>> the most interesting pieces of
On 11/27/18 8:32 PM, Michael Paquier wrote:
>
>>> Attached are two patches to fix all the mess:
>>> - 0001 is a revert of the whitelist, minus the set of regression tests
>>> checking after corrupted files and empty files.
>>> - 0002 is a fix for all the issues reported on this thread, with tests
On 20/11/2018 22:41, Peter Eisentraut wrote:
>>> - Adds new fields to pg_stat_ssl: issuerdn and clientserial. These
>>> allow uniquely identifying the client certificate. AFAICT, these are
>>> the most interesting pieces of information provided by sslinfo but not
>>> in pg_stat_ssl. (I don't lik
On 27/11/2018 00:29, Thomas Munro wrote:
> On Thu, Oct 18, 2018 at 11:05 AM Peter Eisentraut
> wrote:
>> - Adds tests under src/test/ssl/ for the pg_stat_ssl view.
>
> Hi Peter,
>
> Your new tests fail when run by cfbot (Ubuntu), and also on my Debian
> buster machine, but pass on my FreeBSD 13-
On 27/11/2018 15:16, Sergei Kornilov wrote:
> Hi
>
>> The attached seems to be the simplest way to fix this. (Needs
>> documentation updates, test updates, error message refinement.)
>
> Thank you!
> I add documentation change, tests and rephrased error message.
I have committed it along these l
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Sorry about the prior review; I neglected to select all the appropriate
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Patch applies cleanly on master (b238527664ec6f6c9d00dba4cc2f3dab1c8b8b04
Hello!
I wrote some tests(it's just 01_rep_changes.pl but for non superuser) and fix
`DROP TABLE` from subscription. Now old and new tests pass.
22.11.2018, 16:23, "Evgeniy Efimkin" :
> Hello!
> New draft attached with filtering table in subscription (ADD/DROP) and allow
> non-superusers use` CR
I noticed that the way the test module worker_spi is written, it will
execute the main loop SQL one more time after it gets a sigterm, THEN exit
1. This was surprising to me where I used this module as a pattern for my
own background worker as I would have thought it should bail immediately
withou
Lætitia Avrot wrote:
> # The result I want
> From points 3 and 4, here is what I'd like to see :
>
> | Header 1 | Header 2 | Header 3 |
> |--|--|--|
> | content | content | content |
> | content | content | content |
> (2 rows)
What would it look like when a field
On Wed, Nov 28, 2018 at 08:51:54AM -0500, Bruce Momjian wrote:
> On Wed, Nov 28, 2018 at 10:46:51AM -0300, Alvaro Herrera wrote:
> > On 2018-Nov-28, Bruce Momjian wrote:
> >
> > > On Wed, Nov 28, 2018 at 03:25:34PM +0900, Etsuro Fujita wrote:
> > > > Here is a small patch for removing $SUBJECT.
>
Thomas Munro writes:
> On Wed, Nov 28, 2018 at 6:47 PM Tom Lane wrote:
>> Is it possible that unlink() on APFS is not atomic?
> I think you might be right.
> https://github.com/macdice/unlinktest
Bleah. But you can do better than ask whether it's a bug: you can
quote POSIX:
The unlink() f
On 28.11.2018 16:45, Alvaro Herrera wrote:
On 2018-Nov-28, Bruce Momjian wrote:
On Wed, Nov 28, 2018 at 01:01:03PM +0300, Konstantin Knizhnik wrote:
Hi,
I want to introduce new version of VOPS extension for Postgres (vectorized
operations) providing new, more convenient way of usage:
auto-
On 28.11.2018 16:18, Bruce Momjian wrote:
On Wed, Nov 28, 2018 at 01:01:03PM +0300, Konstantin Knizhnik wrote:
Hi,
I want to introduce new version of VOPS extension for Postgres (vectorized
operations) providing new, more convenient way of usage:
auto-substitution of projections.
[Announce
On Wed, Nov 28, 2018 at 10:46:51AM -0300, Alvaro Herrera wrote:
> On 2018-Nov-28, Bruce Momjian wrote:
>
> > On Wed, Nov 28, 2018 at 03:25:34PM +0900, Etsuro Fujita wrote:
> > > Here is a small patch for removing $SUBJECT.
> >
> > Agreed. Patch applied through PG 10, where this first appeared.
>
On 2018-Nov-28, Bruce Momjian wrote:
> On Wed, Nov 28, 2018 at 03:25:34PM +0900, Etsuro Fujita wrote:
> > Here is a small patch for removing $SUBJECT.
>
> Agreed. Patch applied through PG 10, where this first appeared.
Why wouldn't Fujita-san push this patch himself?
--
Álvaro Herrera
On 2018-Nov-28, Bruce Momjian wrote:
> On Wed, Nov 28, 2018 at 01:01:03PM +0300, Konstantin Knizhnik wrote:
> > Hi,
> >
> > I want to introduce new version of VOPS extension for Postgres (vectorized
> > operations) providing new, more convenient way of usage:
> > auto-substitution of projections.
On 2018-Nov-28, Amit Kapila wrote:
> The problem with this idea is that if someone specifies a particular
> parameter using query and the query doesn't return any parameters,
> then it can lead to inadvertent behavior. For example, if user uses
> something like pg_stat_statements_reset(,
> , SELE
Erik Rijkers wrote:
> I don't know if this really is a bug but it seems wrong to me:
>
> psql -A --csv -Xc "select * from pg_namespace order by 1"
>
> gives a difference result than
>
> psql --csv -A -Xc "select * from pg_namespace order by 1"
-A and --csv each select an output format,
On Wed, Nov 28, 2018 at 01:01:03PM +0300, Konstantin Knizhnik wrote:
> Hi,
>
> I want to introduce new version of VOPS extension for Postgres (vectorized
> operations) providing new, more convenient way of usage:
> auto-substitution of projections.
[Announce post moved to hackers.]
I remember th
On Wed, Nov 28, 2018 at 4:45 PM Sergei Kornilov wrote:
>
> Hello
>
> > My preference is for NULL to mean *all* so this is my favorite option,
> > except that the first query should reset everything.
>
> I am +1 for this option. NULL treat as "any" and
> pg_stat_statements_reset(NULL,NULL,NULL) to
On Wed, Nov 28, 2018 at 03:25:34PM +0900, Etsuro Fujita wrote:
> Here is a small patch for removing $SUBJECT.
Agreed. Patch applied through PG 10, where this first appeared.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As yo
Hello
> My preference is for NULL to mean *all* so this is my favorite option,
> except that the first query should reset everything.
I am +1 for this option. NULL treat as "any" and
pg_stat_statements_reset(NULL,NULL,NULL) to reset everything
We can use named notation?
https://www.postgresql.
st 28. 11. 2018 v 9:59 odesílatel Lætitia Avrot
napsal:
> Hi all,
>
> # What I'd like to do
> I've been working on the idea of a markdown format for psql as I had said
> in that thread :
> https://www.postgresql.org/message-id/flat/CAB_COdiiwTmBcrmjXWCKiqkcPgf_bLodrUyb4GYE6pfKeoK2eg%40mail.gmail.
>> Hi, it makes sense to me. One can submit transaction again same as
>> other cases you mentioned.
>>
>> I didn't attach the patch but according to my simple experiment in
>> psql the output would become the following:
>>
>> FATAL: terminating connection due to idle-in-transaction timeout
>> HINT
On Wed, Nov 28, 2018 at 6:47 PM Tom Lane wrote:
> Is it possible that unlink() on APFS is not atomic? That is, the
> sequence of events is something like
>
> pg_ctl: open("postmaster.pid")
> postmaster: unlink("postmaster.pid")
> pg_ctl: reads file, gets zero
> Hi, it makes sense to me. One can submit transaction again same as other cases
> you mentioned.
>
> I didn't attach the patch but according to my simple experiment
> in psql the output would become the following:
>
> FATAL: terminating connection due to idle-in-transaction timeout
> HINT: In
Hi all,
# What I'd like to do
I've been working on the idea of a markdown format for psql as I had said
in that thread :
https://www.postgresql.org/message-id/flat/CAB_COdiiwTmBcrmjXWCKiqkcPgf_bLodrUyb4GYE6pfKeoK2eg%40mail.gmail.com
An attempt was made a year ago (see here :
https://www.postgresq
Hello.
At Tue, 27 Nov 2018 22:30:57 +0100, David Fetter wrote in
<20181127213057.gt...@fetter.org>
> On Tue, Nov 27, 2018 at 03:54:55PM -0500, Tom Lane wrote:
> > David Fetter writes:
> > > Do we still want this as a compile-time option, or does it make more
> > > sense as a run-time option? I'
On 11/28/18 3:31 AM, Andres Freund wrote:
> Hi,
>
> On 2018-11-28 03:06:58 +0100, Petr Jelinek wrote:
>> On 28/11/2018 02:14, Andres Freund wrote:
>>> On 2018-11-28 02:04:18 +0100, Tomas Vondra wrote:
Pushed and backpatched to 9.4- (same as e9edc1ba).
>>>
>>> Backpatching seems on the more
Hello.
At Wed, 28 Nov 2018 05:13:26 +, "Ideriha, Takeshi"
wrote in
<4E72940DA2BF16479384A86D54D0988A6F3BD73A@G01JPEXMBKW04>
> Hi
>
> >From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]
> >Here we need something better, because once this new kind of memory fills up
> >with
> >leaked
87 matches
Mail list logo
