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
>
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
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
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
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
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
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
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
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...
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
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
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:
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.
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_
> 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
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
>
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
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,
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
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,
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
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
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.
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
>
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
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
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
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.
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
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,
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
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"
>>
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
The 'succeeded' argument seems backwards here:
static void
heapam_tuple_complete_speculative(Relation relation, TupleTableSlot *slot,
uint32
spekToken, bool succeeded)
{
boolshouldFree = true;
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]"
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
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.
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
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
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);' .
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]"
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
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]" behaves the same way among
> existing completions.
Hmm. True. Here's
On Tue, Apr 30, 2019 at 02:20:27PM +1200, David Rowley wrote:
> The options seem to be:
> 1. Make the lower limit of toast_tuple_target the same as
> TOAST_TUPLE_THRESHOLD; or
> 2. Require an AccessExclusiveLock when setting toast_tuple_target and
> call create_toast_table() to ensure we get a
On Mon, 1 Apr 2019 12:11:22 +0900
Yugo Nagata wrote:
> On Thu, 27 Dec 2018 21:57:26 +0900
> Yugo Nagata wrote:
>
> > Hi,
> >
> > I would like to implement Incremental View Maintenance (IVM) on PostgreSQL.
> >
>
> I am now working on an initial patch for implementing IVM on PostgreSQL.
>
Hi,
On 2019-05-14 14:22:15 +0900, Michael Paquier wrote:
> On Mon, May 13, 2019 at 09:33:52PM -0700, Andres Freund wrote:
> > On 2019-05-14 13:23:28 +0900, Michael Paquier wrote:
> >> What's actually the reason preventing us from delaying the
> >> checkpointer like the index AMs for the logging
Hello.
At Tue, 14 May 2019 17:50:58 +1200, Thomas Munro wrote
in
> Hi,
>
> Since I keep forgetting the syntax and options, here is $SUBJECT.
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
On Tue, Apr 30, 2019 at 11:26 AM nickb wrote:
> Hello, hackers
>
> we witnessed this slightly misleading error in production and it took us a
> while to figure out what was taking place.
> Below are reproduction steps:
>
>
> -- setup
> create table trun(cate int4);
>
> -- session 1
> begin;
>
66 matches
Mail list logo
