On Thu, Dec 3, 2015 at 8:34 AM, Craig Ringer wrote:
> On 3 December 2015 at 14:54, konstantin knizhnik <
> k.knizh...@postgrespro.ru> wrote:
>
>>
>> Are there some principle problems with it? In BDR it was handled in
>> alternative way, using executor callback. It will be much easier if DDL can
>
Hi ALL,
Need your suggestions.
initially_valid flag is added to make column constraint valid. (commit :
http://www.postgresql.org/message-id/e1q2ak9-0006hk...@gemulon.postgresql.org)
IFAICU, initially_valid and skip_validation values are mutually exclusive at
constraint creation(ref: gram.y),
On Wed, Dec 02, 2015 at 04:46:26PM +0100, Andres Freund wrote:
> On 2015-12-02 09:57:19 -0500, Noah Misch wrote:
> > Hackers have been too reticent to revert and redo defect-laden
> > commits. If doing that is weird today, let it be normal.
>
> Why?
See my paragraph ending with the two sentences
Hello,
At Thu, 3 Dec 2015 16:24:32 +0900, Amit Langote
wrote in <565fee30.8010...@lab.ntt.co.jp>
> > Agreed. The patch already separates integer values and texts.
> > And re-reviewing the patch, there's no fields necessary to be
> > passed as string.
> >
> > total_heap_pages, scanned_heap_pages
Hi,
I am seeing different results with two queries which AFAIU have same
semantics and hence are expected to give same results.
postgres=# \d t1
Table "public.t1"
Column | Type | Modifiers
+-+---
val| integer |
val2 | integer |
postgres=# \d t2
Tab
Jim Nasby wrote:
> I was more thinking it would be nice to be able to temporarily
> over-ride/wrap what an output function is doing. AFAIK that would allow
> this to work everywhere (row(), copy, etc). I don't know of any remotely
> practical way to do that, though.
Yes. Something like
Hi Amul!
On 2015/12/03 17:52, amul sul wrote:
> Hi ALL,
>
> Need your suggestions.
> initially_valid flag is added to make column constraint valid. (commit :
> http://www.postgresql.org/message-id/e1q2ak9-0006hk...@gemulon.postgresql.org)
>
>
> IFAICU, initially_valid and skip_validation valu
On Dec 3, 2015, at 10:34 AM, Craig Ringer wrote:
> On 3 December 2015 at 14:54, konstantin knizhnik
> wrote:
>
>> I'd really like to collaborate using pglogical_output if at all possible.
>> Petr's working really hard to get the pglogical downstrem out too, with me
>> helping where I can.
>
On Wednesday 02 of December 2015 20:26:56 Pavel Stehule wrote:
> 2015-12-02 20:08 GMT+01:00 Alvaro Herrera :
>
> > Pavel Stehule wrote:
> > > Hi
> > >
> > > Today I have problem with regress tests on my laptop.
> >
> > Maybe this is because of the libxml version?
>
> 100%, same issue is with 9.4.
Hi Amit,
Thanks for prompt response.
>On Thursday, 3 December 2015 4:36 PM, Amit Langote
> wrote:
>Especially from a readability standpoint, I think using skip_validation may be
>more apt.
>Why - the corresponding parameter of StoreRelCheck() dictates what's stored in
>pg_constraint.convalida
On 12/3/15 12:44 PM, amul sul wrote:
On Thursday, 3 December 2015 4:36 PM, Amit Langote
wrote:
The user will have to separately validate the constraint by issuing a ALTER
TABLE VALIDATE CONSTRAINT
command at a time of their choosing.
This could be time consuming operation for big table, If I
On Tue, Dec 1, 2015 at 5:17 PM, Greg Stark wrote:
> Sorry, I didn't look at it since. At the time I was using Xi Wang's software
> to find the overflow checks that need to be redone. He published a paper on
> it and it's actually pretty impressive. It constructs a constraint problem
> and then thr
On 3 December 2015 at 12:06, konstantin knizhnik
wrote:
>
> On Dec 3, 2015, at 10:34 AM, Craig Ringer wrote:
>
> On 3 December 2015 at 14:54, konstantin knizhnik <
> k.knizh...@postgrespro.ru> wrote:
>
>>
>> I'd really like to collaborate using pglogical_output if at all possible.
>> Petr's worki
There's another seemingly wrong result, not with lateral, but with FOR
UPDATE.
postgres=# select * from t1;
val | val2
-+--
1 |1
(1 row)
postgres=# select * from t2;
val | val2
-+--
1 |1
2 |2
1 |1
(3 rows)
Session 1
postgres=# begin;
BEGIN
postgres=#
On 30 November 2015 at 17:20, Konstantin Knizhnik wrote:
> But looks like there is not so much sense in having multiple network
> connection between one pair of nodes.
> It seems to be better to have one connection between nodes, but provide
> parallel execution of received transactions at desti
On 3 December 2015 at 15:27, konstantin knizhnik
wrote:
>
> On Dec 3, 2015, at 4:18 AM, Craig Ringer wrote:
>
> > Excellent.
> >
> > It should be possible to make that a separate extension. You can use C
> functions from other extensions by exposing a single pg_proc function with
> 'internal' ret
On 3 December 2015 at 19:06, konstantin knizhnik
wrote:
>
> On Dec 3, 2015, at 10:34 AM, Craig Ringer wrote:
>
> On 3 December 2015 at 14:54, konstantin knizhnik <
> k.knizh...@postgrespro.ru> wrote:
>
>>
>> I'd really like to collaborate using pglogical_output if at all possible.
>> Petr's worki
Greg Stark writes:
> What version of GCC and other compilers did we decide we're targeting now?
I can't see us moving the compiler goalposts one inch for this.
"I'm going to break building on your compiler in order to work around
bugs in somebody else's compiler" isn't gonna fly.
The original po
On 3 December 2015 at 20:39, Simon Riggs wrote:
> On 30 November 2015 at 17:20, Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> wrote:
>
>
>> But looks like there is not so much sense in having multiple network
>> connection between one pair of nodes.
>> It seems to be better to have one conne
On Thu, Dec 3, 2015 at 9:02 AM, Craig Ringer wrote:
>
> On 3 December 2015 at 09:32, Peter Eisentraut wrote:
>>
>> On 12/2/15 7:00 PM, Craig Ringer wrote:
>> > I notice that you don't set the 'waiting' flag. 'waiting' is presently
>> > documented as:
>> >
>> >True if this backend is curr
On 2015-12-03 14:32, Craig Ringer wrote:
On 3 December 2015 at 15:27, konstantin knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
3. What is the right way of creation of background worker requiring
access to shared memory, i.e. having control structure in main memory?
This is documen
On Wed, Dec 2, 2015 at 7:59 PM, David Fetter wrote:
> On Wed, Dec 02, 2015 at 10:36:56PM -0500, Josh Berkus wrote:
>> On 12/02/2015 05:24 PM, Tom Lane wrote:
>> > Don't think I agree. Suppose that you have a wider-than-screen table
>> > and you use a pager to scroll left and right in that. If we
On 2015-12-02 14:48:24 -0600, Kevin Grittner wrote:
> On Wed, Dec 2, 2015 at 12:39 AM, Michael Paquier
> wrote:
> > On Mon, Nov 9, 2015 at 8:07 AM, Steve Singer wrote:
>
> >> In snapmgr.c
> >>
> >>
> >> + * XXX: If we can trust a read of an int64 value to be atomic, we can
> >> skip the
> >> +
On Thu, Dec 3, 2015 at 7:58 AM, Pavel Stehule wrote:
> I am sorry, I don't understand. Now due inheritance plpy.Fatal and
> plpy.SPIError has availability to use keyword parameters.
Indeed, I didn't realize this, but I don't think it changes the main argument.
What I think should happen:
1. Err
On Thu, Dec 3, 2015 at 2:51 PM, Tom Lane wrote:
> Greg Stark writes:
>> What version of GCC and other compilers did we decide we're targeting now?
>
> I can't see us moving the compiler goalposts one inch for this.
That's not the question I asked :/
--
greg
--
Sent via pgsql-hackers mailing
On 2015-11-16 22:43, Alvaro Herrera wrote:
I paraphrase Fujii Masao, who wrote:
1. Start the master and standby servers with track_commit_timestamp enabled.
2. Disable track_commit_timestamp in the master and restart the master server.
3. Run checkpoint in the master.
4. Run restartpoint in the
On 2015-12-03 12:10:27 +, Greg Stark wrote:
> I'm leaning towards using the builtin functions described here
For performance reasons? Michael's version of the patch had the
necessary 'raw' macros, and they don't look *that* bad. Using the
__builtin variants when available, would be nice - and
On Thu, Dec 3, 2015 at 2:51 PM, Tom Lane wrote:
> I can't see us moving the compiler goalposts one inch for this.
> "I'm going to break building on your compiler in order to work around
> bugs in somebody else's compiler" isn't gonna fly.
Fwiw the builtins offer a carrot as well. They promise to
Greg Stark writes:
> On Thu, Dec 3, 2015 at 2:51 PM, Tom Lane wrote:
>> I can't see us moving the compiler goalposts one inch for this.
>> "I'm going to break building on your compiler in order to work around
>> bugs in somebody else's compiler" isn't gonna fly.
> I was proposing to implement wr
2015-12-03 16:57 GMT+01:00 Catalin Iacob :
> On Thu, Dec 3, 2015 at 7:58 AM, Pavel Stehule
> wrote:
> > I am sorry, I don't understand. Now due inheritance plpy.Fatal and
> > plpy.SPIError has availability to use keyword parameters.
>
> Indeed, I didn't realize this, but I don't think it changes
On 2015-12-03 04:38:45 -0500, Noah Misch wrote:
> On Wed, Dec 02, 2015 at 04:46:26PM +0100, Andres Freund wrote:
> > Especially if reverting and redoing includes conflicts that mainly
> > increases the chance of accidental bugs.
>
> True. (That doesn't apply to these patches.)
Uh, it does. You h
On Thu, Dec 3, 2015 at 6:59 AM, Alvaro Herrera wrote:
> I didn't push the changes for config_default you requested a few
> messages upthread; it's not clear to me how setting it to undef affects
> the whole thing. If setting it to undef makes the MSVC toolchain run
> the tap tests in the default
2015-12-03 12:39 GMT+01:00 Pavel Raiskup :
> On Wednesday 02 of December 2015 20:26:56 Pavel Stehule wrote:
> > 2015-12-02 20:08 GMT+01:00 Alvaro Herrera :
> >
> > > Pavel Stehule wrote:
> > > > Hi
> > > >
> > > > Today I have problem with regress tests on my laptop.
> > >
> > > Maybe this is beca
Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote:
> >> BTW, not the fault of this patch in particular, but this example points
> >> up the complaint I've had right along about how opaque TAP test failures
> >> are. How did you dig down to see that err
2015-12-03 5:53 GMT+01:00 Pavel Stehule :
>
>
> 2015-12-03 5:00 GMT+01:00 Haribabu Kommi :
>
>> On Wed, Nov 25, 2015 at 7:18 PM, Pavel Stehule
>> wrote:
>> >
>> >
>> > 2015-11-25 8:05 GMT+01:00 Haribabu Kommi :
>> >>
>> >>
>> >> Thanks. Here I attached the poc patch that returns authentication
>>
> >> Here I attached the patch with the suggested changes.
> >> Along with line number, I kept the options column also with authentication
> >> options as a jsonb datatype.
> >>
> >> Example output:
> >>
> >> postgres=# select pg_hba_lookup('test','all','::1');
> >> NOTICE: Skipped 84 Hba line, be
Hi,
On 2015-11-20 16:11:15 +0900, Michael Paquier wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index cc845d2..4883697 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -9503,6 +9503,14 @@ xlog_redo(XL
On 2015-11-27 16:59:20 +0900, Michael Paquier wrote:
> Attached is a patch that fixes the issue for me in master and 9.5.
> Actually in the last patch I forgot a call to smgrwrite to ensure that
> the INIT_FORKNUM is correctly synced to disk when those pages are
> replayed at recovery, letting the
On Thursday 03 of December 2015 20:49:09 Pavel Stehule wrote:
> 2015-12-03 12:39 GMT+01:00 Pavel Raiskup :
>
> > On Wednesday 02 of December 2015 20:26:56 Pavel Stehule wrote:
> > > 2015-12-02 20:08 GMT+01:00 Alvaro Herrera :
> > >
> > > > Pavel Stehule wrote:
> > > > > Hi
> > > > >
> > > > > Today
Alvaro Herrera writes:
> Tom Lane wrote:
>> Michael Paquier writes:
>>> Well, it showed up on my terminal...
>> Not on mine, as per the extract I showed. Probably a Perl version
>> difference, but I don't think we can exactly write off RHEL6 as an
>> uninteresting obsolete distribution. (The P
The "snapshot too old" patch has an XXX comment about being able to
drop a spinlock usage from a frequently called "get" method if the
64-bit read could be trusted to be atomic. There is no need for a
barrier in this case, because a stale value just means we won't be
quite as aggressive about prun
Petr Jelinek wrote:
> While this seems good, I'd code it slightly differently. I didn't like the
> addition of new bool when it's not really needed. This brings the question
> if we actually need the BootStrapCommitTs and StartupCommitTs functions
> which really don't do much though.
Thanks, it's
On Tue, Dec 1, 2015 at 9:19 AM, Bruce Momjian wrote:
> On Tue, Nov 17, 2015 at 12:48:38PM -0500, Robert Haas wrote:
>> > At this time, the number of round trips needed particularly for READ
>> > COMMITTED transactions that need a new snapshot for each query was
>> > really a performance killer. We
On 2015/12/03 20:44, amul sul wrote:
>> On Thursday, 3 December 2015 4:36 PM, Amit Langote
>> wrote:
>> Especially from a readability standpoint, I think using skip_validation may
>> be more apt.
>> Why - the corresponding parameter of StoreRelCheck() dictates what's stored
>> in pg_constraint
On 4 December 2015 at 06:41, Robert Haas wrote:
>
> I think there are ways to reduce the cost of this. Some distributed
> systems have solved it by retreating from snapshot isolation and going
> back to using locks. This can improve scalability if you've got lots
> of transactions but they're v
On Tue, Dec 01, 2015 at 11:05:47AM -0500, Robert Haas wrote:
> On Mon, Nov 30, 2015 at 2:43 PM, Tom Lane wrote:
> > * Foreign join pushdown vs EvalPlanQual
> >
> > Is this fixed by 5fc4c26db? If not, what remains to do?
>
> Unfortunately, no. That commit allows FDWs to do proper EPQ handling
>
On Wed, Dec 2, 2015 at 5:27 AM, Robert Haas wrote:
>> These are mainly just documentation improvements which I'm working on,
>> though the docs were recently updated and I need to incorporate Peter's
>> changes which I wasn't exactly anticipating.
>
> So, when do you foresee this documentation stu
psql --help=variables shows variables treated specially by psql. And it
tells you
Usage:
psql --set=NAME=VALUE
or \set NAME VALUE
But some of the variables listed cannot usefully be set, only read, such as
DBNAME the currently connected database name
HOST the c
Hi all,
While running the test suite this morning I have noticed the following error:
server stopped
readline() on closed filehandle $pidfile at
/Users/ioltas/git/postgres/src/bin/pg_rewind/../../../src/test/perl/PostgresNode.pm
line 308.
Use of uninitialized value in concatenation (.) or string a
On Fri, Dec 4, 2015 at 8:05 AM, Alvaro Herrera wrote:
>> >> Here I attached the patch with the suggested changes.
>> >> Along with line number, I kept the options column also with authentication
>> >> options as a jsonb datatype.
>> >>
>> >> Example output:
>> >>
>> >> postgres=# select pg_hba_loo
On Fri, Dec 4, 2015 at 7:45 AM, Pavel Stehule wrote:
>
>
> this tracing can be implemented to main pg_hba processing. When you are
> connect from some specific client - and you can see, why you cannot to
> connect to Postgres
The trace messages that are going to print doesn't come to client until
let me put it in other words, is there any harm use of initially_valid instead
of !skip_validation?
Earlier to commit I mentioned in my first post, there is only one flag, IMO
i.e. skip_validation, which are serving both purpose, setting
pg_constraint.convalidated & decide to skip or validate e
On 2015/12/03 21:26, Ashutosh Bapat wrote:
> Session 1
> postgres=# begin;
> BEGIN
> postgres=# update t1 set val = 2 where val2 = 1;
> UPDATE 1
>
> Session 2
> postgres=# select * from t1 left join t2 on (t1.val = t2.val) for update of
> t1;
>
> query waits
>
> Session 1
> postgres=# commit;
>
On Thu, Dec 3, 2015 at 3:44 PM, Michael Paquier
wrote:
> On Thu, Dec 3, 2015 at 6:59 AM, Alvaro Herrera wrote:
>> I didn't push the changed for config_default you requested a few
>> messages upthread; it's not clear to me how setting it to undef affects
>> the whole thing. If setting it to undef
On Fri, Dec 4, 2015 at 1:27 AM, Andres Freund wrote:
> On 2015-12-03 12:10:27 +, Greg Stark wrote:
>> I'm leaning towards using the builtin functions described here
>
> For performance reasons? Michael's version of the patch had the
> necessary 'raw' macros, and they don't look *that* bad. Usi
On Wed, Dec 02, 2015 at 04:33:50PM -0300, Alvaro Herrera wrote:
> Noah Misch wrote:
> > On Tue, Dec 01, 2015 at 08:11:21PM -0300, Alvaro Herrera wrote:
> > > Finally, I ran perltidy on all the files, which strangely changed stuff
> > > that I didn't expect it to change. I wonder if this is related
On Fri, Dec 4, 2015 at 2:43 PM, Noah Misch wrote:
> On Wed, Dec 02, 2015 at 04:33:50PM -0300, Alvaro Herrera wrote:
>> How did you figure
>> that that was the version used, anyway?
>
> I asked Bruce at one point.
So we are trying to use the same version over the years to keep code
consistent acro
2015-12-03 22:50 GMT+01:00 Pavel Raiskup :
> On Thursday 03 of December 2015 20:49:09 Pavel Stehule wrote:
> > 2015-12-03 12:39 GMT+01:00 Pavel Raiskup :
> >
> > > On Wednesday 02 of December 2015 20:26:56 Pavel Stehule wrote:
> > > > 2015-12-02 20:08 GMT+01:00 Alvaro Herrera >:
> > > >
> > > > >
2015-12-04 4:08 GMT+01:00 Peter Eisentraut :
> psql --help=variables shows variables treated specially by psql. And it
> tells you
>
> Usage:
> psql --set=NAME=VALUE
> or \set NAME VALUE
>
> But some of the variables listed cannot usefully be set, only read, such as
>
> DBNAME t
2015-12-04 5:33 GMT+01:00 Haribabu Kommi :
> On Fri, Dec 4, 2015 at 8:05 AM, Alvaro Herrera
> wrote:
> >> >> Here I attached the patch with the suggested changes.
> >> >> Along with line number, I kept the options column also with
> authentication
> >> >> options as a jsonb datatype.
> >> >>
> >>
2015-12-04 5:48 GMT+01:00 Haribabu Kommi :
> On Fri, Dec 4, 2015 at 7:45 AM, Pavel Stehule
> wrote:
> >
> >
> > this tracing can be implemented to main pg_hba processing. When you are
> > connect from some specific client - and you can see, why you cannot to
> > connect to Postgres
>
> The trace
On 2015-12-03 22:08:31 -0500, Peter Eisentraut wrote:
> psql --help=variables shows variables treated specially by psql. And it
> tells you
>
> Usage:
> psql --set=NAME=VALUE
> or \set NAME VALUE
>
> But some of the variables listed cannot usefully be set, only read, such as
>
> DBNAME
On Fri, Dec 04, 2015 at 02:47:36PM +0900, Michael Paquier wrote:
> On Fri, Dec 4, 2015 at 2:43 PM, Noah Misch wrote:
> > On Wed, Dec 02, 2015 at 04:33:50PM -0300, Alvaro Herrera wrote:
> >> How did you figure
> >> that that was the version used, anyway?
> >
> > I asked Bruce at one point.
>
> So
On Fri, Dec 4, 2015 at 10:58 AM, Amit Langote wrote:
> On 2015/12/03 21:26, Ashutosh Bapat wrote:
> > Session 1
> > postgres=# begin;
> > BEGIN
> > postgres=# update t1 set val = 2 where val2 = 1;
> > UPDATE 1
> >
> > Session 2
> > postgres=# select * from t1 left join t2 on (t1.val = t2.val) for
On Fri, Dec 4, 2015 at 2:59 PM, Pavel Stehule wrote:
> 2015-12-03 22:50 GMT+01:00 Pavel Raiskup :
>> Sorry if that looked like this :(. I just wanted to point out that this
>> is not "just" about Fedora --> but either libxml2 (upstream) needs to be
>> fixed or PostgreSQL's testsuite.
>
>
> juju
On 2015/12/04 11:51, Noah Misch wrote:
On Tue, Dec 01, 2015 at 11:05:47AM -0500, Robert Haas wrote:
On Mon, Nov 30, 2015 at 2:43 PM, Tom Lane wrote:
* Foreign join pushdown vs EvalPlanQual
Is this fixed by 5fc4c26db? If not, what remains to do?
Unfortunately, no. That commit allows FDWs
66 matches
Mail list logo
