On Sat, May 23, 2015 at 11:19 AM, Andres Freund wrote:
>
> On May 22, 2015 10:23:06 PM PDT, Amit Kapila
wrote:
> >On Fri, May 22, 2015 at 11:20 PM, Andres Freund
> >wrote:
> >>
> >> On 2015-05-21 09:40:58 +0530, Amit Kapila wrote:
> >> > On Thu, May 21, 2015 at 12:42 AM, Andres Freund
> >
> >wro
On May 22, 2015 10:23:06 PM PDT, Amit Kapila wrote:
>On Fri, May 22, 2015 at 11:20 PM, Andres Freund
>wrote:
>>
>> On 2015-05-21 09:40:58 +0530, Amit Kapila wrote:
>> > On Thu, May 21, 2015 at 12:42 AM, Andres Freund
>
>wrote:
>> > >
>> > > On 2015-05-20 19:27:05 +0530, Amit Kapila wrote:
>> > >
On Fri, May 15, 2015 at 11:51 AM, Amit Kapila
wrote:
>
> On Thu, May 14, 2015 at 10:29 PM, Andrew Dunstan
wrote:
> >
> >
> > On 05/14/2015 10:52 AM, Robert Haas wrote:
> >>
> >> On Thu, May 14, 2015 at 12:12 AM, Amit Kapila
wrote:
> >>>
> >>> On Thu, May 14, 2015 at 2:10 AM, Andrew Dunstan
wrot
On Fri, May 22, 2015 at 11:20 PM, Andres Freund wrote:
>
> On 2015-05-21 09:40:58 +0530, Amit Kapila wrote:
> > On Thu, May 21, 2015 at 12:42 AM, Andres Freund
wrote:
> > >
> > > On 2015-05-20 19:27:05 +0530, Amit Kapila wrote:
> > >
> > > > 13.
> > > > In function replorigin_session_setup() and
in src/backend/utils/misc/tzparser.c
It uses 60 * 60 to represent SECS_PER_HOUR.
and It is already define in other files.
so I think using SECS_PER_HOUR is more clear for readability.
and I attached patch.(it just change 60 * 60 to SECS_PER_HOUR)
What do you think?
magic.patch
Description: B
On Fri, May 22, 2015 at 4:51 PM Jim Nasby wrote:
> Interesting idea. I suspect that would be even more invasive than
> modifying the functions though...
>
Here's the solution. I can't see how anyone could possibly disagree with
this... ;)
Change the sort order for pg_stat_activity so the curre
The proposed flag for jsonb_set (the renamed jsonb_replace) in the patch
I recently published is set to false, meaning that the default behaviour
is to require all elements of the path including the last to be present.
What that does is effectively UPDATE for jsonb. If the flag is true,
then
On Fri, May 22, 2015 at 10:51 AM, Merlin Moncure wrote:
> On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
> wrote:
> > Andrew Dunstan wrote:
> >>
> >> On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
> >
> >> >Attached is a patch against master to generalize the JSON-producing
> >> >functions i
On 2015-05-22 12:23:32 -0700, Peter Geoghegan wrote:
> On Thu, May 21, 2015 at 5:51 PM, Peter Geoghegan wrote:
> >> So I think we're good with ripping it out. Peter?
> >
> > I'll come up with a patch.
>
> Attached patch rips the command tag out.
Pushed.
--
Sent via pgsql-hackers mailing list
On 2015-05-19 22:50:54 -0700, Peter Geoghegan wrote:
> On Tue, May 19, 2015 at 2:23 PM, Andres Freund wrote:
> > Pushed.
>
> I eyeballed the commit, and realized that I made a trivial error. New
> patch attached fixing that.
>
> Sorry for not getting this fix completely right first time around.
On Fri, May 22, 2015 at 2:54 PM, Tom Lane wrote:
>> I think there's essentially two scenarios for JSON usage; one where you
>> want to be pretty paranoid about things like keys aren't missing, you're
>> not trying to access a path that doesn't exist, etc. The other mode
>> (what we have today) is
On 5/22/15 4:54 PM, Tom Lane wrote:
Jim Nasby writes:
On 5/22/15 2:44 PM, Andrew Dunstan wrote:
Still I'd rather not add yet another parameter to the function, and I
certainly don't want to make throwing an error the only behaviour.
If instead of a create_missing boolean it accepted an enum
On 05/22/2015 03:35 PM, Andres Freund wrote:
> On 2015-05-22 17:29:03 -0500, Jim Nasby wrote:
>> On 5/22/15 4:51 PM, Tom Lane wrote:
>>> Jim Nasby writes:
On 5/22/15 3:08 PM, Eric Ridge wrote:
> Rather than change the behavior of pg_cancel/terminate_backend(), why not
> change pg_sta
Volker,
> I likely just viewed this too much through a "security" lens - you see a
> possible attack scenario, a way to turn it off, and only minor
> downsides, so just go for it - but this is not how you can work in a
> huge open source project. I guess as a developer you would have to take
> man
Andres Freund writes:
> This whole discussion seems to be about making it easier to run SELECT
> pg_cancel_backend(pid) FROM pg_stat_activity;. But that shouldn't be
> made easier! If anything harder.
Indeed. I find it hard to believe that there's a real problem here, and
I absolutely will resis
On 2015-05-22 17:29:03 -0500, Jim Nasby wrote:
> On 5/22/15 4:51 PM, Tom Lane wrote:
> >Jim Nasby writes:
> >>On 5/22/15 3:08 PM, Eric Ridge wrote:
> >>>Rather than change the behavior of pg_cancel/terminate_backend(), why not
> >>>change pg_stat_activity to exclude the current session? Seems li
On 5/22/15 4:51 PM, Tom Lane wrote:
Jim Nasby writes:
On 5/22/15 3:08 PM, Eric Ridge wrote:
Rather than change the behavior of pg_cancel/terminate_backend(), why not change
pg_stat_activity to exclude the current session? Seems like showing a row in
pg_stat_activity for "SELECT * FROM pg_st
Jim Nasby writes:
> On 5/22/15 2:44 PM, Andrew Dunstan wrote:
>> Still I'd rather not add yet another parameter to the function, and I
>> certainly don't want to make throwing an error the only behaviour.
> If instead of a create_missing boolean it accepted an enum we could
> handle both (since
Jim Nasby writes:
> On 5/22/15 3:08 PM, Eric Ridge wrote:
>> Rather than change the behavior of pg_cancel/terminate_backend(), why not
>> change pg_stat_activity to exclude the current session? Seems like showing
>> a row in pg_stat_activity for "SELECT * FROM pg_stat_activity" is kinda
>> use
Hackers,
At CoreOS Fest, Intel presented about a technology which they used to
improve write times for the nonrelational data store Etcd. It's called
Asynchronous DRAM Self-Refresh, or ADR. This is supposedly a feature of
all of their chips since E5 which allows users to designate a small area
o
On 5/22/15 2:44 PM, Andrew Dunstan wrote:
On 05/22/2015 03:27 PM, Peter Geoghegan wrote:
On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan
wrote:
As for raising an error, in principle it's doable, but the code to
detect it
might get messy. Also, I don't want a huge number of knobs. So I'm
exci
On 5/22/15 3:08 PM, Eric Ridge wrote:
I find it annoying to have to specifically exclude pg_backend_pid() from
pg_stat_activity if I'm trying to kill a bunch of backends at once, and I can't
think of any reason why you'd ever want to call a pg_cancel_* function with
your own PID.
I'm just a l
> On May 19, 2015, at 6:59 PM, Jim Nasby wrote:
>
> I find it annoying to have to specifically exclude pg_backend_pid() from
> pg_stat_activity if I'm trying to kill a bunch of backends at once, and I
> can't think of any reason why you'd ever want to call a pg_cancel_* function
> with your ow
On 05/22/2015 03:27 PM, Peter Geoghegan wrote:
On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan wrote:
As for raising an error, in principle it's doable, but the code to detect it
might get messy. Also, I don't want a huge number of knobs. So I'm excited
about the idea.
I think that that's a
On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan wrote:
> As for raising an error, in principle it's doable, but the code to detect it
> might get messy. Also, I don't want a huge number of knobs. So I'm excited
> about the idea.
I think that that's a bad default behavior, although I don't think
On Thu, May 21, 2015 at 5:51 PM, Peter Geoghegan wrote:
>> So I think we're good with ripping it out. Peter?
>
> I'll come up with a patch.
Attached patch rips the command tag out.
--
Peter Geoghegan
From 3b50dcd242223c909bdedf20d9b7cb94ba2ff78e Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
D
On 05/22/2015 02:38 PM, Jim Nasby wrote:
On 5/21/15 4:25 PM, Andrew Dunstan wrote:
Here is a patch that renames jsonb_replace to jsonb_set with a boolean
create_missing flag that defaults to false (should we default it to
true?). With the flag set it's more or less upsert for jsonb. Without,
it
2015-05-22 20:28 GMT+02:00 Jim Nasby :
> On 5/21/15 7:12 AM, Robert Haas wrote:
>
>> On Wed, May 20, 2015 at 8:46 PM, Andres Freund
>> wrote:
>>
>>> I've a hard time believing it's actually a good idea to change this. It
>>> pretty much seems to only be useful if you're doing unqualified SELECT
>
On 5/21/15 4:25 PM, Andrew Dunstan wrote:
Here is a patch that renames jsonb_replace to jsonb_set with a boolean
create_missing flag that defaults to false (should we default it to
true?). With the flag set it's more or less upsert for jsonb. Without,
it's just update.
I think upsert is probabl
On Fri, May 22, 2015 at 3:28 PM, Jim Nasby wrote:
>
> You and Andreas think it's fine as-is.
> Tom and Jon Nelson maybe don't like it as-is, but won't break backwards
compatibility.
> David Steele and I seem fine with breaking compat., not sure about
Fabrizio.
>
+1 to add a second parameter and -
On 5/21/15 7:12 AM, Robert Haas wrote:
On Wed, May 20, 2015 at 8:46 PM, Andres Freund wrote:
I've a hard time believing it's actually a good idea to change this. It
pretty much seems to only be useful if you're doing unqualified SELECT
pg_cancel_backend(pid) FROM pg_stat_activity; type queries.
On 05/22/2015 11:01 AM, Josh Berkus wrote:
On 05/22/2015 12:22 AM, Heikki Linnakangas wrote:
It seems worth adding a hint and/or changing the error message to be
more descriptive when in this state. Any options about what should
be logged before I start putting together a patch?
Yeah, might
Stephen Frost wrote:
> Row-Level Security Policies (RLS)
What do we need RowSecurityPolicy->policy_id for? It seems to me that
it is only used to determine whether the policy is the "default deny"
one, so that it can later be removed if a hook adds a different one.
This seems contrived as well as
On 5/20/15 9:38 PM, Robert Haas wrote:
On Wed, May 20, 2015 at 8:22 PM, Jim Nasby wrote:
It might be a good idea to do something like this, but it's
significantly more complicated than a protocol-level SET SESSION
AUTHORIZATION. Right now, you can never go backwards from an
authenticated state
On 05/22/2015 12:22 AM, Heikki Linnakangas wrote:
>> It seems worth adding a hint and/or changing the error message to be
>> more descriptive when in this state. Any options about what should
>> be logged before I start putting together a patch?
>
> Yeah, might be worthwhile. Perhaps:
>
> FATAL:
On 2015-05-21 09:40:58 +0530, Amit Kapila wrote:
> On Thu, May 21, 2015 at 12:42 AM, Andres Freund wrote:
> >
> > On 2015-05-20 19:27:05 +0530, Amit Kapila wrote:
> >
> > > 13.
> > > In function replorigin_session_setup() and or
> > > replorigin_session_advance(), don't we need to WAL log the
> >
On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
wrote:
> Andrew Dunstan wrote:
>>
>> On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
>
>> >Attached is a patch against master to generalize the JSON-producing
>> >functions in utils/adt/json.c and to provide a set of callbacks which can
>> >be over
On Fri, May 22, 2015 at 6:34 PM, Tom Lane wrote:
> Oleksandr Shulgin writes:
> > I think this is a bit over-engineered (apart from the fact that
> > processSQLNamePattern is also used in two dozen of places in
> > psql/describe.c and all of them must be touched for this patch to
> > compile).
>
2015-05-22 18:34 GMT+02:00 Tom Lane :
> Oleksandr Shulgin writes:
> > I think this is a bit over-engineered (apart from the fact that
> > processSQLNamePattern is also used in two dozen of places in
> > psql/describe.c and all of them must be touched for this patch to
> > compile).
>
> > Also, th
2015-05-22 18:35 GMT+02:00 Shulgin, Oleksandr
:
> On Fri, May 22, 2015 at 6:32 PM, Pavel Stehule
> wrote:
>
>>
>>
>> 2015-05-22 18:30 GMT+02:00 Shulgin, Oleksandr <
>> oleksandr.shul...@zalando.de>:
>>
>>> On Fri, May 22, 2015 at 6:09 PM, Pavel Stehule
>>> wrote:
>>>
2015-05-21 16:48
On Fri, May 22, 2015 at 6:32 PM, Pavel Stehule
wrote:
>
>
> 2015-05-22 18:30 GMT+02:00 Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de>:
>
>> On Fri, May 22, 2015 at 6:09 PM, Pavel Stehule
>> wrote:
>>
>>>
>>> 2015-05-21 16:48 GMT+02:00 Oleksandr Shulgin <
>>> oleksandr.shul...@zalando.de>:
Oleksandr Shulgin writes:
> I think this is a bit over-engineered (apart from the fact that
> processSQLNamePattern is also used in two dozen of places in
> psql/describe.c and all of them must be touched for this patch to
> compile).
> Also, the new --table-if-exists options seems to be doing wh
2015-05-22 18:30 GMT+02:00 Shulgin, Oleksandr
:
> On Fri, May 22, 2015 at 6:09 PM, Pavel Stehule
> wrote:
>
>>
>> 2015-05-21 16:48 GMT+02:00 Oleksandr Shulgin <
>> oleksandr.shul...@zalando.de>:
>>
>>>
>>> I think this is a bit over-engineered (apart from the fact that
>>> processSQLNamePattern
On Fri, May 22, 2015 at 6:09 PM, Pavel Stehule
wrote:
>
> 2015-05-21 16:48 GMT+02:00 Oleksandr Shulgin >:
>
>>
>> I think this is a bit over-engineered (apart from the fact that
>> processSQLNamePattern is also used in two dozen of places in
>> psql/describe.c and all of them must be touched for
2015-05-21 16:48 GMT+02:00 Oleksandr Shulgin :
> Pavel Stehule writes:
> >
> > 2015-03-23 17:11 GMT+01:00 Pavel Stehule :
> >
> >> Hi
> >>
> >> 2015-03-15 16:09 GMT+01:00 Tom Lane :
> >>
> >>> Pavel Stehule writes:
> >>> > other variant, I hope better than previous. We can introduce new long
> >
Alvaro Herrera writes:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>>> I believe it's possible to mechanically rebase a patch over an indent
>>> run of the underlying branch with half a dozen commands or less. +1 for
>>> reindenting all branches before each minor release, FWIW.
>> Yeah? Can yo
Tom Lane wrote:
> Alvaro Herrera writes:
> > I believe it's possible to mechanically rebase a patch over an indent
> > run of the underlying branch with half a dozen commands or less. +1 for
> > reindenting all branches before each minor release, FWIW.
>
> Yeah? Can you show an example?
So we
Heikki Linnakangas writes:
> On 05/22/2015 06:53 AM, Matthew Kelly wrote:
>> It seems worth adding a hint and/or changing the error message to be
>> more descriptive when in this state. Any options about what should
>> be logged before I start putting together a patch?
> Yeah, might be worthwhil
Alvaro Herrera writes:
> Robert Haas wrote:
>> On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote:
>>> To do it before every minor release would require re-indenting HEAD
>>> as well (since the whole point is to keep HEAD and the back branches
>>> consistent). I think we'd get too much push-back f
Robert Haas wrote:
> On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote:
> > To do it before every minor release would require re-indenting HEAD
> > as well (since the whole point is to keep HEAD and the back branches
> > consistent). I think we'd get too much push-back from developers
> > whose pe
Etsuro Fujita writes:
> I agree with you on that point. And I think one option for that is that
> IMPORT FOREIGN SCHEMA only imports CHECK constraints of remote tables
> from a remote server that have convalidated = true. (If doing so, we
> wouldn't need to allow IMPORT FOREIGN SCHEMA to retu
Andrew Dunstan wrote:
>
> On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
> >Attached is a patch against master to generalize the JSON-producing
> >functions in utils/adt/json.c and to provide a set of callbacks which can
> >be overridden the same way that is already provided for *parsing* JSON
On Wednesday 20 May 2015 20:50:41 Andres Freund wrote:
> Note that this very likely wasn't actually using a prepared plan. Due to
> the custom plan infrastructure the first few invocations are going to be
> replanned.
Hello. I tested it on 30 and 50 iterations, and it feels good.
Thanks.
--
Uriy
Fujii Masao writes:
> On Fri, May 22, 2015 at 8:59 PM, FabrÃzio de Royes Mello
> wrote:
>> There are some reason to "-i, --ignore-version" option doesn't appear in
>> pg_dump help?
> Because it's obsolete option, I think.
Yeah, see commit c22ed3d523782c43836c163c16fa5a7bb3912826.
Considering
On Fri, May 22, 2015 at 8:42 PM, Fabrízio de Royes Mello
wrote:
> Hi all,
>
> The attached add some spaces to better visualization of the "ALTER TABLE"
> doc.
I found another line to add spaces. Applied. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Fri, May 22, 2015 at 9:20 AM, Fujii Masao wrote:
>
> On Fri, May 22, 2015 at 8:59 PM, Fabrízio de Royes Mello
> wrote:
> > Hi all,
> >
> > There are some reason to "-i, --ignore-version" option doesn't appear in
> > pg_dump help?
>
> Because it's obsolete option, I think.
>
You're correct...
On Fri, May 22, 2015 at 8:59 PM, Fabrízio de Royes Mello
wrote:
> Hi all,
>
> There are some reason to "-i, --ignore-version" option doesn't appear in
> pg_dump help?
Because it's obsolete option, I think.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Fri, May 22, 2015 at 6:59 PM, Heikki Linnakangas wrote:
> On 05/22/2015 12:35 PM, Fujii Masao wrote:
>>
>> Doesn't this change break the case where we want to PITR to the recovery
>> target location in the last partial WAL file with the old timeline?
>> In this case, that partial WAL file needs
Hi all,
There are some reason to "-i, --ignore-version" option doesn't appear in
pg_dump help?
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>
Hi all,
The attached add some spaces to better visualization of the "ALTER TABLE"
doc.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitte
Hi
we support SET ROLE name and SET ROLE TO name. Second form isn't supported
by tabcomplete. Attached trivial patch fixes it.
Regards
Pavel
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 750e29d..7110102
*** a/src/bin/psql/tab-complete.c
--- b/
On 05/22/2015 12:35 PM, Fujii Masao wrote:
Doesn't this change break the case where we want to PITR to the recovery
target location in the last partial WAL file with the old timeline?
In this case, that partial WAL file needs to be read and replayed. But
since the suffix of its filename is .parti
Thank for your comments.
2015-05-21 23:11 GMT+09:00 Robert Haas :
> On Sat, May 16, 2015 at 9:04 AM, Shigeru Hanada
> wrote:
>> d) All relations must have the same effective user id
>> This check is done with userid stored in PgFdwRelationInfo, which is
>> valid only when underlying relations hav
On Fri, May 22, 2015 at 4:22 PM, Heikki Linnakangas wrote:
> On 05/22/2015 06:53 AM, Matthew Kelly wrote:
>>
>> Why anybody in practice would want hot_standby off while in standby
>> mode eludes me, but these are our default values (recovery.conf was
>> generated by pg_basebackup -R).
>
>
> That's
2015-05-22 6:55 GMT+02:00 Fujii Masao :
> Thanks for the report! This seems to be a bug.
>
> This problem happens when WAL record is stored in separate two WAL files and
> there is no valid latter WAL file in the standby. In your case, the former
> file
> is 00044C4D0090 and the latter
On 05/22/2015 06:53 AM, Matthew Kelly wrote:
Why anybody in practice would want hot_standby off while in standby
mode eludes me, but these are our default values (recovery.conf was
generated by pg_basebackup -R).
That's how you set up a cold standby system.
It seems worth adding a hint and/or
On Thu, May 21, 2015 at 6:43 PM, Merlin Moncure wrote:
> On Thu, May 21, 2015 at 2:23 AM, Shulgin, Oleksandr
> wrote:
> > On Wed, May 20, 2015 at 4:06 PM, Merlin Moncure
> wrote:
> >>
> >> On Wed, May 20, 2015 at 8:16 AM, Shulgin, Oleksandr
> >> wrote:
> >> >
> >> > a) no spaces
> >> >
> >> >
67 matches
Mail list logo
