At Thu, 14 Nov 2019 12:01:29 +0900, Michael Paquier wrote
in
> On Wed, Nov 13, 2019 at 09:17:03PM +0900, Michael Paquier wrote:
> > Actually, no, this is not good. I have been studying more the patch,
> > and after stressing more this code path with a cluster having
> > checksums enabled and sh
At Wed, 13 Nov 2019 14:21:13 +0530, Amit Kapila wrote
in
> On Wed, Nov 13, 2019 at 12:57 AM Andres Freund wrote:
> >
> > On 2019-11-11 13:53:40 -0300, Alvaro Herrera wrote:
> >
> > > /* Get a more recent flush pointer. */
> > > if (!RecoveryInProgress())
> > > RecentFl
В письме от четверг, 14 ноября 2019 г. 16:50:18 MSK пользователь Michael
Paquier написал:
> > I've changed the patch to use build_reloptions function and again propose
> > it to the commitfest.
>
> Thanks for the new patch. I have not reviewed the patch in details,
> but I have a small comment.
Today I noticed strange behaviour, consider the following test:
postgres@126111=#create table foo ( a text );
CREATE TABLE
postgres@126111=#insert into foo values ( repeat('PostgreSQL is the
world''s best database and leading by an Open Source Community.', 8000));
INSERT 0 1
postgres@126111=#sele
On Thu, Nov 14, 2019 at 12:10 PM Amit Kapila wrote:
>
> On Thu, Nov 14, 2019 at 9:37 AM Dilip Kumar wrote:
> >
> > On Wed, Nov 13, 2019 at 5:55 PM Amit Kapila wrote:
> > >
> > > On Thu, Oct 3, 2019 at 1:18 PM Dilip Kumar wrote:
> > > >
> > >
> > > As mentioned by me a few days back that the fir
On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
wrote:
> On Wed, Nov 13, 2019 at 01:20:43PM +, Simon Riggs wrote:
> >On Wed, 13 Nov 2019 at 13:08, Bruce Momjian wrote:
> >
> >> On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> >> > On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus
On Wed, Nov 13, 2019 at 8:05 PM Pavel Stehule wrote:
>
>
>
> st 13. 11. 2019 v 7:13 odesílatel Pavel Stehule
> napsal:
>>
>>
>>
>> st 13. 11. 2019 v 7:12 odesílatel Amit Kapila
>> napsal:
>>>
>>> On Tue, Nov 12, 2019 at 11:17 AM Amit Kapila
>>> wrote:
>>> >
>>> > I am planning to commit this
On Mon, 11 Nov 2019 at 17:56, Amit Kapila wrote:
>
> On Mon, Nov 11, 2019 at 5:14 PM Dilip Kumar wrote:
> >
> > On Mon, Nov 11, 2019 at 4:23 PM Amit Kapila
wrote:
> > >
> > > ..
> > > > I have tested the same with some other workload(test file attached).
> > > > I can see the same behaviour with
Hi,
On Wed, Nov 13, 2019 at 10:01 PM Tom Lane wrote:
>
> didier writes:
> > clang -E output before 7a0574b5
> > HeapTuple newtuple = 0;
> > with 7a0574b5
> > HeapTuple newtuple = ((bool) 0);
>
> Hm, did you re-run configure after 7a0574b5? If you didn't, it would
> have gone through the not-std
> * Several fixes for logical replication, including a failure when the
> publisher
> & subscriber had different REPLICA IDENTITY columns set.
"&" should probably be "and" as I don't see it used like that in any
other release notes.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | http
On Tue, 12 Nov 2019 at 22:17, Jonathan S. Katz wrote:
> Attached is a draft of the press release for the update release going
> out on 2010-11-14. Please provide feedback, particularly on the
> technical accuracy of the statements.
Text
by the `position()`
should probably either be
by `
On Thu, Nov 14, 2019 at 03:27:42PM +0530, Rushabh Lathia wrote:
Today I noticed strange behaviour, consider the following test:
postgres@126111=#create table foo ( a text );
CREATE TABLE
postgres@126111=#insert into foo values ( repeat('PostgreSQL is the
world''s best database and leading by an
On Wed, Nov 13, 2019 at 3:23 PM Tomas Vondra
wrote:
> I think it would be beneficial to explain why shared object is more
> secure than an OS command. Perhaps it's common knowledge, but it's not
> quite obvious to me.
External command args can be viewed by other OS users (not just the
postgres us
I have seen the error
could not stat promote trigger file "...": Permission denied
because of a misconfiguration (for example, setting promote_trigger_file
to point into a directory to which you don't have appropriate read or
execute access).
The problem is that because this happens in t
On Wed, Nov 6, 2019 at 4:14 PM btfujiitkp wrote:
>
> 2019-10-31 21:01 に Fujii Masao さんは書きました:
> > On Thu, Oct 31, 2019 at 7:59 PM Ibrar Ahmed
> > wrote:
> >>
> >>
> >>
> >> On Thu, Oct 31, 2019 at 12:32 PM Fujii Masao
> >> wrote:
> >>>
> >>> On Thu, Oct 31, 2019 at 1:42 PM Tom Lane wrote:
> >>>
On Thu, Nov 14, 2019 at 10:58 PM Peter Eisentraut
wrote:
>
> I have seen the error
>
> could not stat promote trigger file "...": Permission denied
>
> because of a misconfiguration (for example, setting promote_trigger_file
> to point into a directory to which you don't have appropriate read
Michael Paquier wrote:
> On Mon, Nov 11, 2019 at 10:03:14AM +0100, Antonin Houska wrote:
> > This looks good to me.
>
> Actually, no, this is not good. I have been studying more the patch,
> and after stressing more this code path with a cluster having
> checksums enabled and shared_buffers at
Hello,
I did a (slow) dichotomy on gcc sources which determined that gcc r277979
was the culprit, then I started a bug report which showed that the issue
was already reported this morning by Martin Liška, including a nice
example isolated from sources. See:
https://gcc.gnu.org/bugzi
On 2019-11-12 20:00, Andres Freund wrote:
Looking at the cplusplus variant, I'm somewhat surprised to see that you
made both fallback and plain version unconditionally use GCC style
compound expressions:
Was that intentional? The C version intentionally uses compound
expressions only for the _
Kyotaro Horiguchi writes:
> This seems assuming %x are a kind of stable (until semicolon)
> function. But at least %`..` can be volatile. So, I think the %w
> thing in PROMPT2 should be able to refer the actual prompt string
> resulted from PROMPT1.
Oh, that's a good point. But it actually lead
On 11/14/19 7:46 AM, Geoff Winkless wrote:
> On Tue, 12 Nov 2019 at 22:17, Jonathan S. Katz wrote:
>> Attached is a draft of the press release for the update release going
>> out on 2010-11-14. Please provide feedback, particularly on the
>> technical accuracy of the statements.
>
> Text
>
>
Peter Eisentraut writes:
> I have seen the error
> could not stat promote trigger file "...": Permission denied
> because of a misconfiguration (for example, setting promote_trigger_file
> to point into a directory to which you don't have appropriate read or
> execute access).
> The proble
Hi.
Yep, I build periodically PostgreSQL package in openSUSE with the
latest GCC and so
that I identified that and isolated to a simple test-case. I would expect a fix
today or tomorrow.
See you,
Martin
On Thu, 14 Nov 2019 at 16:46, Fabien COELHO wrote:
>
>
> Hello,
>
> I did a (slow) dichotomy
On Wed, Nov 13, 2019 at 10:04:36AM -0800, Mark Dilger wrote:
On 11/13/19 7:28 AM, Tomas Vondra wrote:
Hi,
here's an updated patch, with some minor tweaks based on the review and
added tests (I ended up reworking those a bit, to make them more like
the existing ones).
Thanks, Tomas, for the
On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
> I think it would be beneficial to explain why shared object is more
> secure than an OS command. Perhaps it's common knowledge, but it's not
> quite obvious to me.
>
>
>
On 11/14/19 11:07 AM, Bruce Momjian wrote:
> On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
>> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
>> I think it would be beneficial to explain why shared object is more
>> secure than an OS command. Perhaps it's common knowledge
On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:
On 11/14/19 11:07 AM, Bruce Momjian wrote:
On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
I think it would be beneficial to explain why shared object is more
On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:
>
> On 11/14/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> >> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
> >> I think it would be beneficial to explain why shared objec
On 2019-Nov-14, Bruce Momjian wrote:
> I was assuming if the variable starts with a #, it is a shared object,
> if not, it is a shell command:
>
> ssl_passphrase_command='#/lib/x.so'
> ssl_passphrase_command='my_command a b c'
Note that the proposed patch doesn't use a separate GUC -
On Thu, Nov 14, 2019 at 02:07:58PM -0300, Alvaro Herrera wrote:
> On 2019-Nov-14, Bruce Momjian wrote:
>
> > I was assuming if the variable starts with a #, it is a shared object,
> > if not, it is a shell command:
> >
> > ssl_passphrase_command='#/lib/x.so'
> > ssl_passphrase_command='my
Hi,
On 2019-11-13 03:23:06 +, Smith, Peter wrote:
> From: Andres Freund Sent: Wednesday, 13 November 2019
> 6:01 AM
>
> >Peter Smith:
> >
> > Is there a reason to not just make StaticAssertExpr and StaticAssertStmt be
> > the same? I don't want to proliferate variants that users have to
>
On 11/14/19 7:55 AM, Tomas Vondra wrote:
On Wed, Nov 13, 2019 at 10:04:36AM -0800, Mark Dilger wrote:
On 11/13/19 7:28 AM, Tomas Vondra wrote:
Hi,
here's an updated patch, with some minor tweaks based on the review and
added tests (I ended up reworking those a bit, to make them more like
I wrote:
> Michael Paquier writes:
>> Good question. That's a historical choice, still I have seen cases
>> where those warnings are helpful while not making the logs too
>> verbose to see some congestion in the jobs.
> I kind of feel that NOTICE is more semantically appropriate, but
> perhaps t
On 2019-Oct-07, Bruce Momjian wrote:
> Uh, I looked at the pg_ugprade code and the error message is:
>
> pg_fatal("Your installation contains \"contrib/isn\" functions which
> rely on the\n"
> "bigint data type. Your old and new clusters pass bigint
> values\n"
>
Alvaro Herrera writes:
> On 2019-Nov-12, Luis Carril wrote:
>> But, not all foreign tables are necessarily in a remote server like
>> the ones referenced by the postgres_fdw.
>> In FDWs like swarm64da, cstore, citus or timescaledb, the foreign
>> tables are part of your database, and one could exp
On 11/14/19 12:07 PM, Alvaro Herrera wrote:
> On 2019-Nov-14, Bruce Momjian wrote:
>
>> I was assuming if the variable starts with a #, it is a shared object,
>> if not, it is a shell command:
>>
>> ssl_passphrase_command='#/lib/x.so'
>> ssl_passphrase_command='my_command a b c'
> Note
Alvaro Herrera writes:
> On 2019-Oct-07, Bruce Momjian wrote:
>> and the "in database" (which I have changed to capitalized "In database"
>> in the attached patch), looks like:
>> fprintf(script, "In database: %s\n", active_db->db_name);
>> meaning it _isn't_ an output error message, but rather so
On Thu, Nov 14, 2019 at 10:23:44AM -0800, Mark Dilger wrote:
On 11/14/19 7:55 AM, Tomas Vondra wrote:
On Wed, Nov 13, 2019 at 10:04:36AM -0800, Mark Dilger wrote:
On 11/13/19 7:28 AM, Tomas Vondra wrote:
Hi,
here's an updated patch, with some minor tweaks based on the review and
added tes
Hi,
On 2019-11-14 13:37:44 -0500, Tom Lane wrote:
> I wrote:
> > Michael Paquier writes:
> >> Good question. That's a historical choice, still I have seen cases
> >> where those warnings are helpful while not making the logs too
> >> verbose to see some congestion in the jobs.
>
> > I kind of f
Tomas Vondra writes:
> For the case with equal Const values that should be mostly obvious, i.e.
> "a=1 AND a=1 AND a=1" has the same selectivity as "a=1".
> The case with different Const values is harder, unfortunately. It might
> seem obvious that "a=1 AND a=2" means there are no matching rows,
Andres Freund writes:
> On 2019-11-14 13:37:44 -0500, Tom Lane wrote:
>> As for the SKIP_LOCKED tests in vacuum.sql, what I now propose is that
>> we just remove them. I do not see that they're offering any coverage
>> that's not completely redundant with this isolation test. We don't
>> need to
On 2019-Nov-14, Andrew Dunstan wrote:
> I guess this would work. There would have to be a deal of code to load
> the library and lookup the symbol. Do we really think it's worth it?
> Leveraging shared_preload_libraries makes this comparatively simple.
Using the generic interface has the drawback
On Wed, Nov 13, 2019 at 2:45 PM Andres Freund wrote:
> I might be missing something. Aren't all of the places where those
> checks are places where we currently can't do a CHECK_FOR_INTERRUPTS()?
> I've swapped this thoroughly out of my mind, but going through them:
>
> 1) AutoVacLauncherMain() -
On 11/14/19 12:04 PM, Tomas Vondra wrote:
Aha, I think I understand now - thanks for the explanation. You're right
the comment is trying to explain why just taking the last clause for a
given attnum is fine. I'll try to make the comment clearer.
For the case with equal Const values that shoul
Gareth Palmer writes:
>> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
>> Perhaps the way to resolve Peter's objection is to make the syntax
>> more fully like UPDATE:
>> INSERT INTO target SET c1 = x, c2 = y+z, ... FROM tables-providing-x-y-z
>> (with the patch as-submitted corresponding to the
On Wed, Nov 13, 2019 at 08:37:59PM -0500, Tom Lane wrote:
Mark Dilger writes:
On 11/11/19 1:41 PM, Tom Lane wrote:
I happened to notice that find_expr_references_walker has not
been taught anything about TableFunc nodes, which means it will
miss the type and collation OIDs embedded in such a n
Tomas Vondra writes:
> On Wed, Nov 13, 2019 at 08:37:59PM -0500, Tom Lane wrote:
>> I concur with Tomas' suspicion that this must be a race condition
>> during DROP STATISTICS. If we're going to allow people to do that
>> separately from dropping the table(s), there has to be some kind of
>> lock
On Thu, Nov 14, 2019 at 03:16:04PM -0500, Tom Lane wrote:
Tomas Vondra writes:
For the case with equal Const values that should be mostly obvious, i.e.
"a=1 AND a=1 AND a=1" has the same selectivity as "a=1".
The case with different Const values is harder, unfortunately. It might
seem obviou
On Thu, Nov 14, 2019 at 01:17:02PM -0800, Mark Dilger wrote:
On 11/14/19 12:04 PM, Tomas Vondra wrote:
Aha, I think I understand now - thanks for the explanation. You're right
the comment is trying to explain why just taking the last clause for a
given attnum is fine. I'll try to make the comm
On Thu, Nov 14, 2019 at 04:06:52PM -0300, Alvaro Herrera wrote:
> BTW, how is one supposed to "manually upgrade databases that use
> contrib/isb"? This part is not very clear.
I thought you would dump out databases that use isn, drop those
databases, use pg_upgrade for the remaining databases, th
On Thu, Nov 14, 2019 at 02:46:29PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Oct-07, Bruce Momjian wrote:
> >> and the "in database" (which I have changed to capitalized "In database"
> >> in the attached patch), looks like:
> >> fprintf(script, "In database: %s\n", active_db->db
On Thu, Nov 14, 2019 at 04:36:54PM -0500, Tom Lane wrote:
Tomas Vondra writes:
On Wed, Nov 13, 2019 at 08:37:59PM -0500, Tom Lane wrote:
I concur with Tomas' suspicion that this must be a race condition
during DROP STATISTICS. If we're going to allow people to do that
separately from dropping
On 2019-Nov-14, Tomas Vondra wrote:
> Isn't that solved by RemoveObjects() doing this?
>
>/* Get an ObjectAddress for the object. */
>address = get_object_address(stmt->removeType,
> object,
> &relation,
>
Tomas Vondra writes:
> On Thu, Nov 14, 2019 at 04:36:54PM -0500, Tom Lane wrote:
>> Hm. No, it's not enough, unless you add more logic to deal with the
>> possibility that the stats object is gone by the time you have the
>> table lock. Consider e.g. two concurrent DROP STATISTICS commands,
>> o
Bruce Momjian writes:
> On Thu, Nov 14, 2019 at 04:06:52PM -0300, Alvaro Herrera wrote:
>> BTW, how is one supposed to "manually upgrade databases that use
>> contrib/isb"? This part is not very clear.
> I thought you would dump out databases that use isn, drop those
> databases, use pg_upgrade
On Thu, Nov 14, 2019 at 05:49:12PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Nov 14, 2019 at 04:06:52PM -0300, Alvaro Herrera wrote:
> >> BTW, how is one supposed to "manually upgrade databases that use
> >> contrib/isb"? This part is not very clear.
>
> > I thought you would du
On Thu, Nov 14, 2019 at 07:27:29PM -0300, Alvaro Herrera wrote:
On 2019-Nov-14, Tomas Vondra wrote:
Isn't that solved by RemoveObjects() doing this?
/* Get an ObjectAddress for the object. */
address = get_object_address(stmt->removeType,
object,
On Thu, Nov 14, 2019 at 05:35:06PM -0500, Tom Lane wrote:
Tomas Vondra writes:
On Thu, Nov 14, 2019 at 04:36:54PM -0500, Tom Lane wrote:
Hm. No, it's not enough, unless you add more logic to deal with the
possibility that the stats object is gone by the time you have the
table lock. Consider
> On 14 Nov 2019, at 23:16, Bruce Momjian wrote:
>
> On Thu, Nov 14, 2019 at 04:06:52PM -0300, Alvaro Herrera wrote:
>> BTW, how is one supposed to "manually upgrade databases that use
>> contrib/isb"? This part is not very clear.
>
> I thought you would dump out databases that use isn, drop th
On Wed, Nov 13, 2019 at 10:50 AM, Julien Rouhaud wrote:
> On Tue, Nov 12, 2019 at 5:41 AM imai.yoshik...@fujitsu.com
> wrote:
> >
> > On Sat, Nov 9, 2019 at 1:36 PM, Julien Rouhaud wrote:
> > >
> > > I attach v3 patches implementing those counters.
> >
> > Thanks for updating the patch! Now I can
On Thu, Nov 14, 2019 at 03:20:09PM -0500, Tom Lane wrote:
> If we're going to keep them in vacuum.sql, we should use the
> client_min_messages fix there, as that's a full solution not just
> reducing the window. But I don't agree that these tests are worth
> the cycles, given the coverage elsewher
On Thu, Nov 14, 2019 at 11:20:25AM +0300, Nikolay Shaplov wrote:
> For me there is no mush sense in it, as it does not prevent us from wrong
> type
> casting. Indexes can use all kinds of structures for reloptions, and checking
> that this is index, will not do much.
It seems to me that if the
On Thu, Nov 14, 2019 at 10:38:30AM -0500, Tom Lane wrote:
> It is harsh, but I suspect if we just logged the complaint, we'd get
> bug reports about "Postgres isn't reacting to my trigger file",
> because people don't read the postmaster log unless forced to.
> Is there some more-visible way to rep
On Wed, Nov 13, 2019 at 05:55:12PM -0800, Andres Freund wrote:
> My point was that I think there must be negation missing in Daniel's
> statement - XLH_INSERT_CONTAINS_NEW_TUPLE will only be set if *not* a
> catalog relation. But Daniel's statement says exactly the opposite, at
> least by my read.
On Fri, Nov 15, 2019 at 10:49 AM Michael Paquier wrote:
>
> On Thu, Nov 14, 2019 at 10:38:30AM -0500, Tom Lane wrote:
> > It is harsh, but I suspect if we just logged the complaint, we'd get
> > bug reports about "Postgres isn't reacting to my trigger file",
> > because people don't read the postm
On Tue, Sep 10, 2019 at 03:23:25PM +0900, Michael Paquier wrote:
> Yes, I suspect that it could be very costly in some configurations if
> there is a large gap between the last replayed LSN and the last LSN
> the WAL receiver has flushed.
>
> There is an extra thing, which has not been mentioned y
On Wed, Nov 13, 2019 at 10:02 AM Masahiko Sawada
wrote:
>
> I've done some tests while changing shared buffer size, delays and
> number of workers. The overall results has the similar tendency as the
> result shared by Dilip and looks reasonable to me.
>
Thanks, Sawada-san for repeating the tests
On Wed, Sep 25, 2019 at 07:03:52AM +0200, Julien Rouhaud wrote:
> IIUC, if something like Heikki's patch is applied on older branch the
> problem will be magically fixed from the extension point of view so
> that should be safe (an extension would only need to detect the minor
> version to get a mo
Sorry I missed one thing. Turn off full page writes. I'm running in an env.
with atomic 8K writes.
> On November 12, 2019 at 6:23 PM Daniel Wood wrote:
>
> It's been tedious to get it exactly right but I think I got it. FYI, I
> was delayed because today we had yet another customer hit
On Thu, Nov 14, 2019 at 6:30 PM Tomas Vondra
wrote:
> On Thu, Nov 14, 2019 at 03:27:42PM +0530, Rushabh Lathia wrote:
> >Today I noticed strange behaviour, consider the following test:
> >
> >postgres@126111=#create table foo ( a text );
> >CREATE TABLE
> >postgres@126111=#insert into foo values
Yep, I build periodically PostgreSQL package in openSUSE with the latest
GCC and so that I identified that and isolated to a simple test-case. I
would expect a fix today or tomorrow.
Indeed, the gcc issue reported seems fixed by gcc r278259. I'm updating
moonjelly gcc to check if this solve
čt 14. 11. 2019 v 12:12 odesílatel vignesh C napsal:
> On Wed, Nov 13, 2019 at 8:05 PM Pavel Stehule
> wrote:
> >
> >
> >
> > st 13. 11. 2019 v 7:13 odesílatel Pavel Stehule
> napsal:
> >>
> >>
> >>
> >> st 13. 11. 2019 v 7:12 odesílatel Amit Kapila
> napsal:
> >>>
> >>> On Tue, Nov 12, 2019 a
72 matches
Mail list logo
