č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
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
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
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 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
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
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
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
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 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
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 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
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
> 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
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.
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: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
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
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,
>>
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 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
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",
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,
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
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
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
>>
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
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
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
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 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
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
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
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,
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
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
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-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
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"
>
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
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
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 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'
> >
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 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
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 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
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 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
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)
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
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
>
>
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
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
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:
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
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
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:
>
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
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
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 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
> * 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. |
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
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
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
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,
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
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
В письме от четверг, 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
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())
> > >
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
72 matches
Mail list logo
