On Wed, Oct 26, 2016 at 11:04 PM, Joshua D. Drake
wrote:
> On 10/26/2016 12:54 PM, Josh Berkus wrote:
>> I mean, I'm not particularly in favor of using JSON for this (arrays
>> seem OK), but that seems like an invalid reason not to.
>
> -1 to JSON for this.
Sigh. Well I tried to review this patc
Hi
,
selectDumpableExtension() function skip
s dump of
built-in extensions in case of binary-upgrade only,
why not in normal
dump
?
Can't we assume those will already be installed in the target database
at restore
?
Thanks
&
Regards,
Amul
On Thu, Oct 27, 2016 at 2:01 AM, Tom Lane wrote:
> Slightly related: there are some callers such as PGLC_localeconv that
> aren't checking for a failure return. Seems bad.
And also related to the patch trying to improve OOM handling in
pg_locale.c, the point being that elog() cannot be called as
On Wed, Oct 26, 2016 at 6:13 PM, Amit Kapila wrote:
> If my understanding is right, then the changes proposed by you as
> below is not what is intended here. I think you need to do something
> as I have mentioned above.
Ah OK I have spotted the subtility;
- 0 means update minRecoveryPoint to the
On Thu, Oct 27, 2016 at 2:59 AM, Robert Haas wrote:
> On Wed, Oct 26, 2016 at 2:06 AM, Michael Paquier
> wrote:
>> But yes, thinking *harder*, I agree that updating minRecoveryPoint
>> just after the checkpoint record would be fine and removes the need to
>> have more WAL than necessary in for a
On Thu, 27 Oct 2016 00:31:56 +0200
Gilles Darold wrote:
> Thanks a lot for the documentation fixes, I've also patched some of
> your changes, see v7 of the patch and explanations bellow.
Thanks. Sorry if I've not kept up on your latest decisions.
> > Put pg_log_file in alphabetical order in th
On 2016/10/27 3:13, Robert Haas wrote:
> On Tue, Oct 25, 2016 at 9:06 PM, Amit Langote
> wrote:
>> I will include these changes in the next version of patches I will post
>> soon in reply to [1].
>> [1]
>> https://www.postgresql.org/message-id/CA%2BTgmoYJcUTcN7vVgg54GHtffH11JJWYZnfF4KiRxjV-iaACQg%
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Bapat
> In pgstat_quickdie(), I think a call to sigaddset(&BlockSig, SIGQUIT) is
> missing before PG_SETMASK(). Although there are some SIGQUIT handlers which
> do not have that call. But I
Thanks for your quick response, Fabien
I think that PGPASSFILE is somehow checked twice
yup, that was unintended redundancy...
I would suggest that the struct gets the value (from option,
environment or default) and is always used elsewhere. The
getPgPassFilename function should disappear and
On 27 October 2016 at 09:22, Chapman Flack wrote:
> Hmm, IsUnderPostmaster is PGDLLIMPORTed but IsPostmasterEnvironment isn't,
> so I'm out of luck on Windows. Is there another way I can check?
>
>>> Do I detect I'm in a BGW by a non-null MyBgworkerEntry?
>>
>> Use IsBackgroundWorker, same place
On Thu, Oct 27, 2016 at 10:27 AM, Peter Eisentraut
wrote:
> On 10/26/16 9:18 PM, Michael Paquier wrote:
>> Side question just for curiosity: when is AVAIL_LANGUAGES filled? Once
>> the translations are added to the tree?
>
> Yes, that happens when the translations are copied in before a release.
>
On 10/26/16 9:18 PM, Michael Paquier wrote:
> Side question just for curiosity: when is AVAIL_LANGUAGES filled? Once
> the translations are added to the tree?
Yes, that happens when the translations are copied in before a release.
See here for the script that is normally used:
https://git.postgre
On 10/26/16 07:04, Amit Kapila wrote:
> No, parallel workers in parallel query doesn't have MyProcPort.
Ok ... it turns out I was using MyProcPort as a quick way to grab
database_name and user_name (very early in startup, for a purpose
analogous to setting a 'ps' process title), and that seemed mo
On Thu, Oct 27, 2016 at 10:02 AM, Peter Eisentraut
wrote:
> Here is a series of patches to add NLS to the remaining bin programs,
> which were moved from contrib a while ago. (If you're missing pgbench,
> I'm skipping that for now because it's more complicated.) I'll add this
> to the commit fes
Here is a series of patches to add NLS to the remaining bin programs,
which were moved from contrib a while ago. (If you're missing pgbench,
I'm skipping that for now because it's more complicated.) I'll add this
to the commit fest.
--
Peter Eisentraut http://www.2ndQuadrant.com/
P
On Thu, Oct 27, 2016 at 5:11 AM, Tom Lane wrote:
> Josh Berkus writes:
>> On 10/26/2016 12:24 PM, Tom Lane wrote:
>>> I concur. JSON isn't a core datatype and I don't want to see it treated
>>> as one. We should redesign this view so that it doesn't rely on anything
>>> more advanced than array
On Wed, Aug 17, 2016 at 4:12 PM, Peter Geoghegan wrote:
> During preliminary analysis of what it would take to produce a
> parallel CLUSTER patch that is analogous of what I came up with for
> CREATE INDEX, which in general seems quite possible, I identified
> reform_and_rewrite_tuple() as a major
Thank you.
At Wed, 26 Oct 2016 10:20:28 -0400, Tom Lane wrote in
<17387.1477491...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > Hello, compiler complains about unused variable during build
> > postgres_fdw without assertions (!--enable-cassert).
> > The attched patch removes it and moves into
Hi,
At Wed, 26 Oct 2016 11:00:17 +0530, Ashutosh Bapat
wrote in
> On Wed, Oct 26, 2016 at 6:19 AM, Kyotaro HORIGUCHI
> wrote:
> Thanks for the patch and sorry for missing this in the review. I
>
> The patch applies but seems to have a trailing white space.
Oops. My 'git commit' has a hook t
On 10/25/2016 06:10 AM, Amit Kapila wrote:
On Mon, Oct 24, 2016 at 2:48 PM, Dilip Kumar wrote:
On Fri, Oct 21, 2016 at 7:57 AM, Dilip Kumar wrote:
On Thu, Oct 20, 2016 at 9:03 PM, Tomas Vondra
wrote:
In the results you've posted on 10/12, you've mentioned a regression with 32
clients, wher
Le 26/10/2016 à 05:30, Karl O. Pinc a écrit :
> On Tue, 18 Oct 2016 14:18:36 +0200
> Gilles Darold wrote:
>
>> Here is the v6 of the patch, here is the description of the
>> pg_current_logfile() function, I have tried to keep thing as simple as
>> possible:
>>
>> pg_current_logfile( [ destination
Hi,
On 26/10/16 18:22, Serge Rielau wrote:
> Euler,
>
> Thanks, I was previously told I should post a WIP patch here.
> There are too many open issues to be near committing.
> Anyway, I have created a patch.
> https://commitfest.postgresql.org/11/843/#
Adding to commitfest is act of asking for
On 2016-10-26 15:06:34 -0500, Jim Nasby wrote:
> Removing the exec might "solve" the problem here, assuming that the
> forked process doesn't still inherit all open FH's.
Unless you explicitly close fds or use FD_CLOEXEC when opening fds
they'll be inherited forever.
--
Sent via pgsql-hackers m
On Wed, Oct 26, 2016 at 3:06 PM, Jim Nasby wrote:
> On 10/26/16 2:25 PM, Merlin Moncure wrote:
>>
>> I don't think that's the case. sqsh is a psql-like utility. it
>> writes to stdout and stderr only which is captured by plsh and sent.
>> In this context shexec only wraps rm -f 'file' where 'fi
Josh Berkus writes:
> On 10/26/2016 12:24 PM, Tom Lane wrote:
>> I concur. JSON isn't a core datatype and I don't want to see it treated
>> as one. We should redesign this view so that it doesn't rely on anything
>> more advanced than arrays.
> Huh? Sure it is. Ships in PostgreSQL-core.
To
On 10/26/16 2:25 PM, Merlin Moncure wrote:
I don't think that's the case. sqsh is a psql-like utility. it
writes to stdout and stderr only which is captured by plsh and sent.
In this context shexec only wraps rm -f 'file' where 'file' is a file
previously created with COPY in the same transact
On 10/26/2016 12:54 PM, Josh Berkus wrote:
On 10/26/2016 12:24 PM, Tom Lane wrote:
Robert Haas writes:
FWIW, I'm -1 on using JSON here. I don't believe that we should start
using JSON all over the place just because we can. If we do that,
we'll end up with a mishmash of styles, and maybe loo
On 10/26/2016 12:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> FWIW, I'm -1 on using JSON here. I don't believe that we should start
>> using JSON all over the place just because we can. If we do that,
>> we'll end up with a mishmash of styles, and maybe look silly when JSON
>> is replaced by
On Thu, Oct 27, 2016 at 6:55 AM, Josh Berkus wrote:
> On 10/21/2016 10:29 AM, Robert Haas wrote:
>> On Fri, Oct 21, 2016 at 1:17 PM, Josh Berkus wrote:
>>> Particularly, with 9.6's freeze map, point (2) is even stronger reason
>>> to *lower* autovacuum_max_freeze_age. Since there's little duplic
Robert Haas writes:
> FWIW, I'm -1 on using JSON here. I don't believe that we should start
> using JSON all over the place just because we can. If we do that,
> we'll end up with a mishmash of styles, and maybe look silly when JSON
> is replaced by the new and much better SDGJHSDR format.
I co
On Wed, Oct 26, 2016 at 2:12 PM, Andres Freund wrote:
> On 2016-10-26 13:49:12 -0500, Merlin Moncure wrote:
>> On Wed, Oct 26, 2016 at 1:45 PM, Andres Freund wrote:
>> >
>> >
>> > On October 26, 2016 9:38:49 PM GMT+03:00, Merlin Moncure
>> > wrote:
>> >>On Wed, Oct 26, 2016 at 1:34 PM, Andres F
Robert Haas writes:
> I'm not interested in committing this patch. I don't believe it is an
> improvement on what we've got today.
> Tom, any chance you could offer an opinion?
I have no objection to this patch as such, but I think that the docs
around FDW direct modify need significantly more w
On 2016-10-26 13:49:12 -0500, Merlin Moncure wrote:
> On Wed, Oct 26, 2016 at 1:45 PM, Andres Freund wrote:
> >
> >
> > On October 26, 2016 9:38:49 PM GMT+03:00, Merlin Moncure
> > wrote:
> >>On Wed, Oct 26, 2016 at 1:34 PM, Andres Freund
> >>wrote:
> >>> Any chance that plsh or the script it e
On 10/26/2016 11:33 AM, Robert Haas wrote:
On Wed, Oct 26, 2016 at 2:22 PM, Joshua D. Drake wrote:
After some further investigation and collaboration with #postgresql it looks
like what we have here is an actual bug or at least improper implementation.
Apparently, we use getpwuid on the euid to
On Tue, Oct 25, 2016 at 3:23 AM, Alvaro Herrera
wrote:
> Haribabu Kommi wrote:
>> On Mon, Oct 3, 2016 at 3:51 PM, Michael Paquier
>> wrote:
>
>> Yes, I agree that adding these JSONB utility functions for this view
>> is an overkill, but I thought that these are may be useful for some
>> users if
On Sun, Oct 2, 2016 at 10:03 AM, Michael Paquier
wrote:
> On Thu, Sep 22, 2016 at 7:48 PM, Rushabh Lathia
> wrote:
>> I performed basic test with patch,
>>
>> a) patch get applied cleanly on latest source,
>> b) able to build documentation cleanly.
>>
>> Marking this as ready for committer.
>
> O
On Wed, Oct 26, 2016 at 1:45 PM, Andres Freund wrote:
>
>
> On October 26, 2016 9:38:49 PM GMT+03:00, Merlin Moncure
> wrote:
>>On Wed, Oct 26, 2016 at 1:34 PM, Andres Freund
>>wrote:
>>> Any chance that plsh or the script it executes does anything with the
>>file descriptors it inherits? That'
On October 26, 2016 9:38:49 PM GMT+03:00, Merlin Moncure
wrote:
>On Wed, Oct 26, 2016 at 1:34 PM, Andres Freund
>wrote:
>> Any chance that plsh or the script it executes does anything with the
>file descriptors it inherits? That'd certainly one way to get into odd
>corruption issues.
>
>not su
On Tue, Oct 18, 2016 at 7:25 PM, Bruce Momjian wrote:
> On Wed, Oct 12, 2016 at 08:33:00AM -0400, Tom Lane wrote:
>> As others have noted, there is no likelihood that we'd take a disk-format-
>> compatibility-breaking patch for v10. Even if we wanted to do that, the
>> above proposal would also b
On Wed, Oct 26, 2016 at 1:34 PM, Andres Freund wrote:
> Any chance that plsh or the script it executes does anything with the file
> descriptors it inherits? That'd certainly one way to get into odd corruption
> issues.
not sure. it's pretty small -- see
https://github.com/petere/plsh/blob/mas
On October 26, 2016 8:57:22 PM GMT+03:00, Merlin Moncure
wrote:
>On Wed, Oct 26, 2016 at 12:43 PM, Merlin Moncure
>wrote:
>> On Wed, Oct 26, 2016 at 11:35 AM, Merlin Moncure
>wrote:
>>> On Tue, Oct 25, 2016 at 3:08 PM, Merlin Moncure
>wrote:
Confirmation of problem re-occurrence will co
On Wed, Oct 26, 2016 at 2:22 PM, Joshua D. Drake wrote:
> After some further investigation and collaboration with #postgresql it looks
> like what we have here is an actual bug or at least improper implementation.
> Apparently, we use getpwuid on the euid to locate the 'home directory'. This
> is
On Tue, Oct 25, 2016 at 10:00 PM, Amit Langote
wrote:
> I am not (or no longer) sure how that argument affects INSERT on
> partitioned tables with tuple-routing though. Are partitions at all
> levels *implicitly specified to be affected* when we say INSERT INTO
> root_partitioned_table?
I'd say
On Wed, Oct 26, 2016 at 1:09 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> *) I've now strongly correlated this routine with the damage.
>
> Hmm. Do you have any way to replace the non-core calls with something
> else? The "shexec('rm -f ' || _OutputFile)" bits could presumably be
> converted
Hello,
After some further investigation and collaboration with #postgresql it
looks like what we have here is an actual bug or at least improper
implementation. Apparently, we use getpwuid on the euid to locate the
'home directory'. This is incorrect (as well as inconsistent to our own
docume
On Tue, Oct 25, 2016 at 9:06 PM, Amit Langote
wrote:
> I will include these changes in the next version of patches I will post
> soon in reply to [1].
> [1]
> https://www.postgresql.org/message-id/CA%2BTgmoYJcUTcN7vVgg54GHtffH11JJWYZnfF4KiRxjV-iaACQg%40mail.gmail.com
How soon? Tempus fugit, and
Merlin Moncure writes:
> *) I've now strongly correlated this routine with the damage.
Hmm. Do you have any way to replace the non-core calls with something
else? The "shexec('rm -f ' || _OutputFile)" bits could presumably be
converted to use contrib/adminpack's pg_file_unlink(), or an equivale
On Tue, Oct 25, 2016 at 2:58 AM, Amit Kapila wrote:
> a. Policy on table_name
No, because queries against the parent will apply the policy to
children. See today's commit
162477a63d3c0fd1c31197717140a88077a8d0aa.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQ
On Wed, Oct 26, 2016 at 6:12 AM, Amit Kapila wrote:
> On Wed, Oct 26, 2016 at 3:04 PM, Amit Langote
> wrote:
>> On 2016/10/26 17:57, Amit Kapila wrote:
>>> @@ -123,6 +123,9 @@ typedef struct RelationData
>>> {
>>> ..
>>> MemoryContext rd_partkeycxt; /* private memory cxt for the below */
>>>
On Wed, Oct 26, 2016 at 2:06 AM, Michael Paquier
wrote:
> But yes, thinking *harder*, I agree that updating minRecoveryPoint
> just after the checkpoint record would be fine and removes the need to
> have more WAL than necessary in for a backup taken from a standby.
> That will also prevent cases
On Wed, Oct 26, 2016 at 12:43 PM, Merlin Moncure wrote:
> On Wed, Oct 26, 2016 at 11:35 AM, Merlin Moncure wrote:
>> On Tue, Oct 25, 2016 at 3:08 PM, Merlin Moncure wrote:
>>> Confirmation of problem re-occurrence will come in a few days.I'm
>>> much more likely to believe 6+sigma occurrence
Robert Haas writes:
> On Wed, Oct 26, 2016 at 1:20 PM, Tom Lane wrote:
>> Right, so quals from above the SB view would have to not be allowed to
>> drop below the join level (but they could fall *to* the join level,
>> where they'd be applied after the join's own quals). I mentioned that
>> in t
On 10/21/2016 10:29 AM, Robert Haas wrote:
> On Fri, Oct 21, 2016 at 1:17 PM, Josh Berkus wrote:
>> Particularly, with 9.6's freeze map, point (2) is even stronger reason
>> to *lower* autovacuum_max_freeze_age. Since there's little duplicate
>> work in a freeze scan, a lot of users will find tha
On Wed, Oct 26, 2016 at 11:35 AM, Merlin Moncure wrote:
> On Tue, Oct 25, 2016 at 3:08 PM, Merlin Moncure wrote:
>> Confirmation of problem re-occurrence will come in a few days.I'm
>> much more likely to believe 6+sigma occurrence (storage, freak bug,
>> etc) should it prove the problem goes
On Wed, Oct 26, 2016 at 1:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> This might work for RLS policies, if they can only reference a single
>> table, but I can't see how it's going to work for security barrier
>> views. For example, consider CREATE VIEW v WITH (security_barrier) AS
>> SELECT
On 10/26/2016 10:26 AM, Andres Freund wrote:
On October 26, 2016 8:09:11 PM GMT+03:00, "Joshua D. Drake"
wrote:
postgres=# \! export
export HOME='/home/jd/snap/postgresql96/1'
That doesn't do much. Isn't that just spawning a shell in which you set the
variable, which then immediately exi
On October 26, 2016 8:09:11 PM GMT+03:00, "Joshua D. Drake"
wrote:
>postgres=# \! export
>export HOME='/home/jd/snap/postgresql96/1'
That doesn't do much. Isn't that just spawning a shell in which you set the
variable, which then immediately exits? And this the value isn't set anywhere
rele
On 10/26/2016 10:16 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
Is psql getting the home directory from /etc/passwd?
Yes, of course.
If so what can we do about that?
Fix your /etc/passwd entry? Seems unlikely that psql is the only
program that believes that entry.
It isn't that simpl
Robert Haas writes:
> This might work for RLS policies, if they can only reference a single
> table, but I can't see how it's going to work for security barrier
> views. For example, consider CREATE VIEW v WITH (security_barrier) AS
> SELECT * FROM x, y WHERE x.a = y.a followed by SELECT * FROM v
"Joshua D. Drake" writes:
> Is psql getting the home directory from /etc/passwd?
Yes, of course.
> If so what can we do about that?
Fix your /etc/passwd entry? Seems unlikely that psql is the only
program that believes that entry.
regards, tom lane
--
Sent via pgsql
Hello,
CMD has been working on building snap packages. It has been an adventure
and we are very close to having them complete. In fact they are complete
enough that we have published them in the snap repo.
jd@jd-wks:~$ snap find postgres
NameVersion Developer Notes Summary
post
On Tue, Oct 25, 2016 at 5:58 PM, Tom Lane wrote:
> The alternative I'm now thinking about pursuing is to get rid of the
> conversion of RLS quals to subqueries. Instead, we can label individual
> qual clauses with security precedence markings. Concretely, suppose we
> add an "int security_level"
Peter Eisentraut writes:
> pg_get_encoding_from_locale() in chklocale.c reports this when it finds
> a locale with an encoding it does not recognize:
> ereport(WARNING,
> (errmsg("could not determine encoding for locale \"%s\": codeset
> is \"%s\"",
> ctype, sys),
>err
On Wed, Oct 26, 2016 at 7:17 AM, Andres Freund wrote:
> On 2016-09-23 16:04:32 -0400, Tom Lane wrote:
>> Looking back over the thread, I see that you also proposed installing
>> isolationtester and pg_isolation_regress for the benefit of extensions.
>> I'm very much less excited about that idea.
On Mon, Oct 24, 2016 at 4:04 PM, Peter Eisentraut
wrote:
> On 10/12/16 7:58 PM, Robert Haas wrote:
>> I don't think it's wrong that the handling is done there, though. The
>> process that is registering the background worker is well-placed to
>> check whether there are already too many, and if it
On Tue, Oct 25, 2016 at 3:08 PM, Merlin Moncure wrote:
> Confirmation of problem re-occurrence will come in a few days.I'm
> much more likely to believe 6+sigma occurrence (storage, freak bug,
> etc) should it prove the problem goes away post rebuild.
ok, no major reported outage yet, but jus
Euler,
Thanks, I was previously told I should post a WIP patch here.
There are too many open issues to be near committing.
Anyway, I have created a patch.
https://commitfest.postgresql.org/11/843/#
Since this is my first time I do have a couple of questions:
There are entries for a git and a wiki
pg_get_encoding_from_locale() in chklocale.c reports this when it finds
a locale with an encoding it does not recognize:
ereport(WARNING,
(errmsg("could not determine encoding for locale \"%s\": codeset
is \"%s\"",
ctype, sys),
errdetail("Please report this to .")));
I
On Mon, Aug 1, 2016 at 3:18 PM, Peter Geoghegan wrote:
> Setup:
>
> CREATE TABLE parallel_sort_test AS
> SELECT hashint8(i) randint,
> md5(i::text) collate "C" padding1,
> md5(i::text || '2') collate "C" padding2
> FROM generate_series(0, 1e9::bigint) i;
>
> CHECKPOINT;
>
> This le
On 26-10-2016 12:43, Serge Rielau wrote:
> Posting to this group on a Friday evening was obviously a Bad Idea(tm). :-)
>
Serge, add your patch to the next commitfest [1] so we don't forget to
review it.
[1] https://commitfest.postgresql.org/11/
--
Euler Taveira Timbira -
Hackers,
Posting to this group on a Friday evening was obviously a Bad Idea(tm). :-)
Let me clarify that I’m at this point not looking for any detailed review.
Rather I’m hoping to drive towards design decisions on the below.
So any opining would be much appreciated.
> On Oct 21, 2016, at 4:15 PM
On Mon, Oct 24, 2016 at 11:57 AM, Robert Haas wrote:
> So now I think that to make this work correctly, we're going to need
> to change both the URL parser and also add parsing for the host and
> port. Let's say the user says this:
>
> postgresql://[1::2]:3,[4::5],[6::7]::8/
>
> What I think we n
Kyotaro HORIGUCHI writes:
> Hello, compiler complains about unused variable during build
> postgres_fdw without assertions (!--enable-cassert).
> The attched patch removes it and moves into the assertion below it.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hac
Robert Haas writes:
> On Wed, Oct 26, 2016 at 7:12 AM, Ashutosh Bapat
> wrote:
>> Also, many other SIGQUIT handlers like bgworker_quickdie() call
>> on_exit_reset()
>> followed by exit(2) instead of just exit(1) in pgstat_quickdie(). Why is this
>> difference?
> Well, for that, you'd need to lo
On Wed, Oct 26, 2016 at 5:54 PM, Robert Haas wrote:
> On Mon, Oct 24, 2016 at 3:48 AM, Amit Kapila wrote:
>> On Thu, Oct 13, 2016 at 5:28 AM, Robert Haas wrote:
>>> On Wed, Oct 12, 2016 at 8:13 AM, Peter Eisentraut
>>> wrote:
On 10/4/16 10:16 AM, Julien Rouhaud wrote:
> Please find att
On Wed, Oct 26, 2016 at 4:47 PM, Michael Paquier
wrote:
>
> If you test on a master node that would be the same: there is a delay
> until the stats process restart. I have not looked at the code closely
> enough in this area (reaper()?) to determine if there are ways to
> improve the responsivenes
On Wed, Oct 26, 2016 at 7:12 AM, Ashutosh Bapat
wrote:
> Also, many other SIGQUIT handlers like bgworker_quickdie() call
> on_exit_reset()
> followed by exit(2) instead of just exit(1) in pgstat_quickdie(). Why is this
> difference?
Well, for that, you'd need to look at how postmaster.c treats t
On Mon, Oct 24, 2016 at 3:48 AM, Amit Kapila wrote:
> On Thu, Oct 13, 2016 at 5:28 AM, Robert Haas wrote:
>> On Wed, Oct 12, 2016 at 8:13 AM, Peter Eisentraut
>> wrote:
>>> On 10/4/16 10:16 AM, Julien Rouhaud wrote:
Please find attached v9 of the patch, adding the parallel worker class
On 26 October 2016 at 06:56, Chapman Flack wrote:
> My main question is, what state do I need to examine at startup
> in order to distinguish these cases?
For loaded in shared_preload_libraries, test
IsPostmasterEnvironment && !IsUnderPostmaster
See src/backend/utils/init/globals.c
> Do I det
On Wed, Oct 26, 2016 at 7:12 PM, Kuntal Ghosh
wrote:
> On Wed, Oct 26, 2016 at 12:10 PM, Michael Paquier
> wrote:
>> On Wed, Oct 26, 2016 at 2:46 PM, Tsunakawa, Takayuki
>> wrote:
>>> If the stats collector is forcibly terminated on the standby in streaming
>>> replication configuration, it won
On 2016-09-23 16:04:32 -0400, Tom Lane wrote:
> Looking back over the thread, I see that you also proposed installing
> isolationtester and pg_isolation_regress for the benefit of extensions.
> I'm very much less excited about that idea. It'd be substantially more
> dead weight in typical installa
On Wed, Oct 26, 2016 at 7:39 AM, Chapman Flack wrote:
> On 10/25/16 18:56, Chapman Flack wrote:
>
>> If pooled, and tied to the backend that started them, do they need
>> to do anything special to detect when the leader has executed
>> SET ROLE or SET SESSION AUTHORIZATION?
>
> Let me guess ... su
Hello Julian,
The documentation needs to be updated.
I've written a couple lines now.
I aligned the definition of the connection option and the environment
variable with that of other (conn.opt&env.var.) pairs and added mention of
the different options to the doc of the "Password File".
Ok
On Wed, Sep 28, 2016 at 8:37 AM, Tsunakawa, Takayuki
wrote:
>> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
>> Allowing SIGQUIT to prompt fast shutdown of the stats collector seems sane,
>> though. Try to make sure it doesn't leave
On Wed, Oct 26, 2016 at 4:26 AM, Chapman Flack wrote:
> Hi,
>
> I have a report of a PL/Java crash in 9.6 where the stack trace
> suggests it was trying to initialize in a background worker
> process (not sure why that even happened, yet), and by my first
> glance, it seems to have crashed derefer
On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita
wrote:
> On 2016/10/26 18:25, Ashutosh Bapat wrote:
>
>> Your patch calls isSubqueryExpr() recursively for every Var in the
>> targetlist, which can be many for foreign tables with many columns.
>> For every such Var it may need to reach upto the rela
Hi hackers,
Here is a new version of my patch to add a replay_lag column to the
pg_stat_replication view (originally proposed as part of a larger
patch set for 9.6[1]), like this:
postgres=# select application_name, replay_lag from pg_stat_replication;
┌──┬─┐
│ app
On Wed, Oct 26, 2016 at 3:04 PM, Amit Langote
wrote:
> On 2016/10/26 17:57, Amit Kapila wrote:
>> @@ -123,6 +123,9 @@ typedef struct RelationData
>> {
>> ..
>> MemoryContext rd_partkeycxt; /* private memory cxt for the below */
>> struct PartitionKeyData *rd_partkey; /* partition key, or NULL
On Wed, Oct 26, 2016 at 12:10 PM, Michael Paquier
wrote:
> On Wed, Oct 26, 2016 at 2:46 PM, Tsunakawa, Takayuki
> wrote:
>> If the stats collector is forcibly terminated on the standby in streaming
>> replication configuration, it won't be restarted until the standby is
>> promoted to the prima
On 2016/10/26 18:25, Ashutosh Bapat wrote:
Your patch calls isSubqueryExpr() recursively for every Var in the
targetlist, which can be many for foreign tables with many columns.
For every such Var it may need to reach upto the relation which is
converted into subquery, which can as bad as reachi
On 2016/10/26 17:57, Amit Kapila wrote:
> @@ -123,6 +123,9 @@ typedef struct RelationData
> {
> ..
> MemoryContext rd_partkeycxt; /* private memory cxt for the below */
> struct PartitionKeyData *rd_partkey; /* partition key, or NULL */
> + MemoryContext rd_pdcxt; /* private context for partdes
>
I guess, the arrays need to be
computed only once for any relation when the query for that relation
is deparsed the first time.
>
>
>>> Does this algorithm extend to the case where we consider paths for every
>>> join order?
>
>
>> Yes, if we store the information about which of re
On Wed, Oct 26, 2016 at 12:39 PM, Michael Paquier
wrote:
> On Wed, Oct 26, 2016 at 1:40 PM, Amit Kapila wrote:
>> If you are inclined towards this solution, then I think what we need
>> to do is to change the API UpdateMinRecoveryPoint() such that it's
>> second parameter can take three values.
2016-10-26 10:03 GMT+02:00 Heikki Linnakangas :
> On 10/24/2016 10:33 PM, Pavel Stehule wrote:
>
>> Hi
>>
>> 2016-10-14 10:53 GMT+02:00 Heikki Linnakangas :
>>
>> Please review. Are the docs and the error messages now clear enough on
>>> this? We'll need a mention in the release notes too, when it
On 2016/10/26 16:11, Ashutosh Bapat wrote:
You wrote:
For
example, let's assume that a relation (1, 2, 3) is required to be
deparsed as subquery for an immediate upper relation (1, 2, 3, 4, 5)
(thus the other joining relation being (4,5)). While deparsing for
relation (1,2,3,4,5), the context wi
On Wed, Oct 5, 2016 at 7:20 AM, Robert Haas wrote:
> On Tue, Oct 4, 2016 at 4:02 AM, Amit Langote
> wrote:
>> [ latest patch set ]
>
> Reviewing 0003:
>
>
> 5. I wonder how well this handles multi-column partition keys. You've
> just got one Datum flag and one is-finite flag per partition, but I
On 10/26/2016 08:37 AM, vinayak wrote:
Attached patch fixes a typo in reorderbuffer.c
s/messsage/message/g
Fixed, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/26/2016 09:52 AM, Daniel Gustafsson wrote:
Spotted a tiny typo in contrib/pageinspect/heapfuncs.c:
s/accordindly/accordingly/
Fixed, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
On 10/21/2016 04:06 AM, vinayak wrote:
Attached patch fixes a typo in pgstat.c
s/addtions/additions/g
Fixed, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/21/2016 03:55 AM, vinayak wrote:
- * st_progress_command_target, and st_progress_command[].
+ * st_progress_command_target, and st_progress_param[].
Attached patch fixed typo.
Fixed, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
1 - 100 of 106 matches
Mail list logo
