On Wed, May 15, 2019 at 1:01 PM Masahiko Sawada wrote:
>
> On Wed, May 15, 2019 at 11:45 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2019-05-15 11:36:52 +0900, Masahiko Sawada wrote:
> > > I might be missing something but if the frontend code doesn't check
> > > arguments and we let the backen
Thomas Munro writes:
> I tried teaching pgindent's post_indent subroutine to unmangle the
> multi-line declarations it mangles. That produces correct
> indentation! But can also produce lines that exceed the column limit
> we would normally wrap at (of course, because pg_bsd_indent had less
> wh
Hi all,
I have just finished my annual set of checks with
wal_consistency_checking enabled based on f4125278, and I am seeing no
failures when replaying comparison pages on a standby.
Thanks,
--
Michael
signature.asc
Description: PGP signature
On Wed, May 15, 2019 at 11:45 AM Andres Freund wrote:
>
> Hi,
>
> On 2019-05-15 11:36:52 +0900, Masahiko Sawada wrote:
> > I might be missing something but if the frontend code doesn't check
> > arguments and we let the backend parsing logic do all the work then it
> > allows user to execute an ar
Hi,
On 2019-05-15 11:36:52 +0900, Masahiko Sawada wrote:
> I might be missing something but if the frontend code doesn't check
> arguments and we let the backend parsing logic do all the work then it
> allows user to execute an arbitrary SQL command via vacuumdb.
But, so what? The user could just
On Wed, May 15, 2019 at 7:51 AM Michael Paquier wrote:
>
> On Wed, May 15, 2019 at 03:19:29AM +0900, Fujii Masao wrote:
> > + if (strncasecmp(opt_str, "true", 4) != 0 &&
> > + strncasecmp(opt_str, "false", 5) != 0)
> >
> > Shouldn't we allow also "on" and "off", "1", "0" as a valid boolean value,
On Tue, May 14, 2019 at 11:32:52AM -0400, Alvaro Herrera wrote:
> I do :-)
And actually I am happy to see somebody raising that point. The
current log messages are quite inconsistent for a couple of years now
but I did not bother changing anything other than the new strings per
the feedback I got
On Wed, May 15, 2019 at 2:52 AM Andres Freund wrote:
>
> Hi,
>
> On 2019-05-15 02:45:21 +0900, Fujii Masao wrote:
> > VACUUM fails to parse 0 and 1 as boolean value
> >
> > The document for VACUUM explains
> >
> > boolean
> > Specifies whether the selected option should be turned on or off
Hi,
On 2019-05-14 15:30:52 -0700, Andres Freund wrote:
> There's a new set of CPU vulnerabilities, so far only affecting intel
> CPUs. Cribbing from the linux-kernel announcement I'm referring to
> https://xenbits.xen.org/xsa/advisory-297.html
> for details.
>
> The "fix" is for the OS to perform
Hi,
On 2019-05-15 12:52:47 +1200, Thomas Munro wrote:
> On Wed, May 15, 2019 at 10:31 AM Andres Freund wrote:
> > *Without* disabling SMT, for readonly pgbench, I'm seeing regressions
> > between 7-11%, depending on the size of shared_buffers (and some runtime
> > variations). That's just on my
On Wed, May 15, 2019 at 10:31 AM Andres Freund wrote:
> *Without* disabling SMT, for readonly pgbench, I'm seeing regressions
> between 7-11%, depending on the size of shared_buffers (and some runtime
> variations). That's just on my laptop, with an i7-6820HQ / Haswell CPU.
> I'd be surprised if
Hi,
On 2019-05-15 12:01:07 +1200, Thomas Munro wrote:
> On Thu, May 2, 2019 at 5:10 AM Robert Haas wrote:
> > On Wed, May 1, 2019 at 12:50 PM Tom Lane wrote:
> > > > Not strongly enough to argue about it very hard. The current behavior
> > > > is a little weird, but it's a long way from being t
On Thu, May 2, 2019 at 5:10 AM Robert Haas wrote:
> On Wed, May 1, 2019 at 12:50 PM Tom Lane wrote:
> > > Not strongly enough to argue about it very hard. The current behavior
> > > is a little weird, but it's a long way from being the weirdest thing
> > > we ship, and it appears that we have no
On 5/15/19 3:38 AM, Tom Lane wrote:
I wrote:
I think moving fe_utils/logging.[hc] to
common/ is definitely the way to get out of this problem.
I've pushed that, so Ian's problem should be gone as of HEAD.
Thanks, that resolves the issue!
Regards
Ian Barwick
--
Ian Barwick
On Wed, May 15, 2019 at 08:20:33AM +0900, Michael Paquier wrote:
> Hmn. I think that Robert's commit is right to rely on defGetBoolean()
> for option parsing. That's what we use for anything from CREATE
> EXTENSION to CREATE SUBSCRIPTION, etc.
And I need more coffee at this time of the day... B
Hi,
On 2019-05-15 08:20:33 +0900, Michael Paquier wrote:
> On Tue, May 14, 2019 at 10:52:23AM -0700, Andres Freund wrote:
> > Might be worth having a common rule for such options, so we don't
> > duplicate the knowledge between different places.
> >
> > CCing Robert and Sawada-san, who committed
On Tue, May 14, 2019 at 10:52:23AM -0700, Andres Freund wrote:
> Might be worth having a common rule for such options, so we don't
> duplicate the knowledge between different places.
>
> CCing Robert and Sawada-san, who committed / authored that code.
Hmn. I think that Robert's commit is right t
On Wed, May 15, 2019 at 03:19:29AM +0900, Fujii Masao wrote:
> + if (strncasecmp(opt_str, "true", 4) != 0 &&
> + strncasecmp(opt_str, "false", 5) != 0)
>
> Shouldn't we allow also "on" and "off", "1", "0" as a valid boolean value,
> like VACUUM does?
I am wondering, in order to keep this patch si
Hi,
There's a new set of CPU vulnerabilities, so far only affecting intel
CPUs. Cribbing from the linux-kernel announcement I'm referring to
https://xenbits.xen.org/xsa/advisory-297.html
for details.
The "fix" is for the OS to perform some extra mitigations:
https://www.kernel.org/doc/html/latest
Hi,
On 2019-05-14 16:27:47 -0400, Alvaro Herrera wrote:
> On 2019-May-14, Ashwin Agrawal wrote:
>
> > Thank you. Please find the patch to rename the agreed functions. It would
> > be good to make all consistent instead of applying exception to three
> > functions but seems no consensus on it. Giv
On 2019-May-14, Ashwin Agrawal wrote:
> Thank you. Please find the patch to rename the agreed functions. It would
> be good to make all consistent instead of applying exception to three
> functions but seems no consensus on it. Given table_ api are new, we could
> modify them leaving systable_ one
> On 14 May 2019, at 03:49, Thomas Munro wrote:
> I propose a new option $SUBJECT so that users can at least add a level of
> indirection and put the password in a file.
+1, seems like a reasonable option to give.
> Draft patch attached.
I might be a bit thick, but this is somewhat hard to pa
Hi,
On 2019-05-14 07:06:34 -0700, Andres Freund wrote:
> On May 14, 2019 4:29:01 AM PDT, Heikki Linnakangas wrote:
> >The 'succeeded' argument seems backwards here:
> >
> >> static void
> >> heapam_tuple_complete_speculative(Relation relation, TupleTableSlot
> >*slot,
> >>
Hi,
On 2019-04-30 11:53:38 -0700, Ashwin Agrawal wrote:
> Comment for table_complete_speculative() says
>
> /*
> * Complete "speculative insertion" started in the same transaction.
> If
> * succeeded is true, the tuple is fully inserted, if false, it's
> removed.
> */
> static inline void
> ta
Hi,
On 2019-05-10 14:40:38 -0700, Andres Freund wrote:
> On 2019-05-01 11:41:48 -0700, Andres Freund wrote:
> > I'm imagining something like
> >
> > if (pg_try_advisory_xact_lock(1))
> > pg_advisory_xact_lock(2);
> > else
> > pg_advisory_xact_lock(1);
> >
> > in t1_lock_func. If you then
On Wed, May 8, 2019 at 5:05 PM Ashwin Agrawal wrote:
> Not having consistency is the main aspect I wish to bring to
> attention. Like for some callback functions the comment is
>
> /* see table_insert() for reference about parameters */
> void(*tuple_insert) (Relation rel, TupleTa
On Mon, May 13, 2019 at 12:51 PM Robert Haas wrote:
> On Fri, May 10, 2019 at 3:43 PM Ashwin Agrawal
> wrote:
> > Meant to stick the question mark in that email, somehow missed. Yes
> > not planning to spend any time on it if objections. Here is the list
> > of renames I wish to perform.
> >
> >
I wrote:
> I think moving fe_utils/logging.[hc] to
> common/ is definitely the way to get out of this problem.
I've pushed that, so Ian's problem should be gone as of HEAD.
regards, tom lane
On Thu, May 9, 2019 at 8:20 PM Masahiko Sawada wrote:
>
> On Thu, May 9, 2019 at 10:01 AM Michael Paquier wrote:
> >
> > On Wed, May 08, 2019 at 06:21:09PM -0300, Euler Taveira wrote:
> > > Em qua, 8 de mai de 2019 às 14:19, Fujii Masao
> > > escreveu:
> > >> The question is; we should support
On Tue, May 14, 2019 at 10:01 AM Michael Paquier wrote:
>
> On Mon, May 13, 2019 at 07:28:25PM +0900, Masahiko Sawada wrote:
> > Thank you! I've incorporated your comment in my branch. I'll post the
> > updated version patch after the above discussion got a consensus.
>
> Fujii-san, any input abou
Hi,
On 2019-05-15 02:45:21 +0900, Fujii Masao wrote:
> VACUUM fails to parse 0 and 1 as boolean value
>
> The document for VACUUM explains
>
> boolean
> Specifies whether the selected option should be turned on or off.
> You can write TRUE, ON, or 1 to enable the option, and FALSE, O
Hi,
VACUUM fails to parse 0 and 1 as boolean value
The document for VACUUM explains
boolean
Specifies whether the selected option should be turned on or off.
You can write TRUE, ON, or 1 to enable the option, and FALSE, OFF,
or 0 to disable it.
But VACUUM fails to parse 0 and 1
[ backing up to a different sub-discussion ]
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> To support the first usage, similar_escape is non-strict, and it
> Tom> takes a NULL second argument to mean '\'. This is already a SQL
> Tom> spec violation, because as far as I can tell fro
On 2019-May-09, Michael Paquier wrote:
> On Wed, May 08, 2019 at 11:28:35PM -0400, Tom Lane wrote:
> > Michael Paquier writes:
> >> No problem to do that. I'll brush up all that once you commit the
> >> first piece you have come up with, and reuse the new API of catalog.c
> >> you are introducin
Hi there I am interested about the project and have gone through the
project idea.
But I would like to know more about the project and the organization
expectations
the tech writers .Apart from the skills and language mentioned..what more
skills/language you are expecting from technical writers.
pl
On Fri, May 10, 2019 at 05:26:43PM -0400, Andrew Dunstan wrote:
>
> On 5/10/19 3:35 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2019-05-10 11:38:57 -0400, Tom Lane wrote:
> >>> I am wondering if, somehow, the stack depth limit seen by the postmaster
> >>> sometimes doesn't apply to its
On Tue, May 14, 2019 at 10:52:07AM -0400, Tom Lane wrote:
> Mark Wong writes:
> > Slowly catching up on my collection of ppc64le animals...
>
> Oh, btw ... you didn't answer my question from before: are these animals
> all running on a common platform (and if so, what is that), or are they
> real
On Fri, May 10, 2019 at 11:27:07AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-10 11:38:57 -0400, Tom Lane wrote:
> > Core was generated by `postgres: debian regression [local] SELECT
> > '.
> > Program terminated with signal SIGSEGV, Segmentation fault.
>
Mark Wong writes:
> Slowly catching up on my collection of ppc64le animals...
Oh, btw ... you didn't answer my question from before: are these animals
all running on a common platform (and if so, what is that), or are they
really different hardware? If they're all VMs on one machine then it
migh
Mark Wong writes:
> The following I've enabled force_parallel_mode for HEAD, 11, 10, and
> 9.6:
Thanks Mark!
In theory, the stack trace we now have from shoveler proves that parallel
mode has nothing to do with this, because the crash happens during
planning (specifically, inlining SQL functions
On Fri, May 03, 2019 at 11:45:33AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-03 10:08:59 -0700, Mark Wong wrote:
> > Ok, I think I have gdb installed now...
>
> Thanks! Any chance you could turn on force_parallel_mode for the other
> branches it applies to too? Makes it easier to figure ou
Andres Freund writes:
> On 2019-05-14 12:37:39 +0900, Michael Paquier wrote:
>> Still, I would like to understand why the bootstrap process has been
>> signaled to begin with, particularly for an initdb, which is not
>> really something that should happen on a server where an instance
>> runs. If
On Tue, May 14, 2019 at 10:00 AM Amit Langote
wrote:
> On 2019/05/14 13:23, Amit Langote wrote:
> > Tom
> > strongly objected to that idea saying that such join paths are kind of
> > silly [1], even outside the context of partitionwise join. He suggested
> > that we abandon partitionwise join in
Hi,
On May 14, 2019 4:29:01 AM PDT, Heikki Linnakangas wrote:
>The 'succeeded' argument seems backwards here:
>
>> static void
>> heapam_tuple_complete_speculative(Relation relation, TupleTableSlot
>*slot,
>>uint32
>> spekToken, bo
On Tue, May 14, 2019 at 11:53:23AM +0200, nickb wrote:
> On Sat, May 11, 2019, at 22:33, Bruce Momjian wrote:
> > http://momjian.us/pgsql_docs/release-12.html
>
> There is a typo in E.1.3.1.1.:
> > Expressions are evaluated at table partitioned table creation time.
> First "table" seems to be exce
On 5/13/19 8:32 PM, Michael Paquier wrote:
> On Mon, May 13, 2019 at 01:06:10PM -0700, legrand legrand wrote:
>> that finished commited
>> "pgsql: Add hooks for session start and session end"
>> https://www.postgresql.org/message-id/flat/575d6fa2-78d0-4456-8600-302fc35b2591%40dunslane.net#0819e315c
Hi,
>>From: Thomas Munro [mailto:thomas.mu...@gmail.com]
>>Subject: Re: Copy data to DSA area
>>
>>On Wed, May 8, 2019 at 5:29 PM Ideriha, Takeshi
>>
>>wrote:
>>> >From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>>> >Sent: Friday, April 26, 2019 11:50 PM Well, after developing PoC,
The 'succeeded' argument seems backwards here:
static void
heapam_tuple_complete_speculative(Relation relation, TupleTableSlot *slot,
uint32
spekToken, bool succeeded)
{
boolshouldFree = true;
HeapTupl
At Tue, 14 May 2019 18:58:14 +1200, Thomas Munro wrote
in
> On Tue, May 14, 2019 at 6:18 PM Kyotaro HORIGUCHI
> wrote:
> > I played with this a bit and found that "... (attr=[tab]" (no
> > space between "r" and "=") complets with '='. Isn't it annoying?
> >
> > Only "UPDATE hoge SET a=[tab]" be
On 08/05/2019 01:31, Heikki Linnakangas wrote:
On 02/05/2019 10:37, Heikki Linnakangas wrote:
On 29/04/2019 16:16, Anastasia Lubennikova wrote:
In previous emails, I have sent two patches with test and bugfix (see
attached).
After Heikki shared his concerns, I've rechecked the algorithm and
hav
Hi,
That is an attempt number N+1 to relax checks for a temporary table access
in a transaction that is going to be prepared.
One of the problems regarding the use of temporary tables in prepared
transactions
is that such transaction will hold locks for a temporary table after being
prepared.
T
On Sat, May 11, 2019, at 22:33, Bruce Momjian wrote:
> http://momjian.us/pgsql_docs/release-12.html
There is a typo in E.1.3.1.1.:
> Expressions are evaluated at table partitioned table creation time.
First "table" seems to be excessive.
Regards,
Nick.
On Tue, May 14, 2019 at 9:11 AM Michael Paquier wrote:
> On Tue, May 14, 2019 at 08:08:05AM +0200, Chris Travers wrote:
> > Having thought about this a bit, I think the best solution would be to
> have
> > grant take out an access share lock to the tables granted. This would
> > prevent concurre
On Tue, May 14, 2019 at 09:01:27PM +1200, Thomas Munro wrote:
> On Tue, May 14, 2019 at 8:32 PM Edgy Hacker wrote:
> > Hmm... just got here.
>
> Welcome.
Thanks.
>
> > What happens around here?
>
> Please see https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F
> .
Not exactly
it reset statistics for a single table and update the column stats_reset of
pg_stat_database.
but i think that stats_reset shoud be database-level statistics, a single
table should not update the column stats_reset.
i am monitor the xact_commit every 5 minutes, when stats_reset is reset but
ohter
On Tue, May 14, 2019 at 8:32 PM Edgy Hacker wrote:
> Hmm... just got here.
Welcome.
> What happens around here?
Please see https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F .
--
Thomas Munro
https://enterprisedb.com
Ok, thanks for the clarification.
Regards
Navneet
On Tue, May 14, 2019 at 4:33 AM Michael Paquier wrote:
> On Tue, May 14, 2019 at 03:41:37AM -0400, navneet nikku wrote:
> >This is working in Oracle but not in postgresql 'CREATE INDEX
> > client.test_1_idx
> > ON dbo.test_1 (name);' . Ca
On Tue, May 14, 2019 at 03:41:37AM -0400, navneet nikku wrote:
>This is working in Oracle but not in postgresql 'CREATE INDEX
> client.test_1_idx
> ON dbo.test_1 (name);' . Can we implement this by another way?
No, it is not possible to define a schema with CREATE INDEX, and an
index gets
On Tue, May 14, 2019 at 06:58:14PM +1200, Thomas Munro wrote:
> On Tue, May 14, 2019 at 6:18 PM Kyotaro HORIGUCHI
> wrote:
> > I played with this a bit and found that "... (attr=[tab]" (no
> > space between "r" and "=") complets with '='. Isn't it annoying?
> >
> > Only "UPDATE hoge SET a=[tab]" b
Hi,
This is working in Oracle but not in postgresql 'CREATE INDEX
client.test_1_idx
ON dbo.test_1 (name);' . Can we implement this by another way?
Thanks
Navneet
On Tue, May 14, 2019 at 08:08:05AM +0200, Chris Travers wrote:
> Having thought about this a bit, I think the best solution would be to have
> grant take out an access share lock to the tables granted. This would
> prevent concurrent alter table operations from altering the schema
> underneath the
61 matches
Mail list logo
