On Mon, Aug 18, 2014 at 3:48 PM, Fujii Masao wrote:
> On Mon, Aug 18, 2014 at 2:38 PM, Michael Paquier
> wrote:
>> - IDENTIFY_SYSTEM checks were incorrect (even in HEAD). The following
>> check was done but in 9.4 this command returns 4 fields:
>> (PQntuples(res) != 1 || PQnfields(res) < 3)
>> Th
On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
wrote:
> On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao wrote:
>> Attached patch changes \watch so that it displays how long the query takes
>> if \timing is enabled.
>>
>> I didn't refactor PSQLexec and SendQuery into one routine because
>> the con
hi, all
I am so sorry for asking some questions like this!
Recently, for understanding postgresql's optimizer, I read and debug
the source code. these two days, I read these macros in sysattr.h:
...
#define ObjectIdAttributeNumber (-2)
...
and the relative codes, but I still did not know
On Mon, Aug 18, 2014 at 4:12 PM, Fujii Masao wrote:
> On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
> wrote:
>> On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao wrote:
>>> Attached patch changes \watch so that it displays how long the query takes
>>> if \timing is enabled.
>>>
>>> I didn't refac
On Mon, Aug 18, 2014 at 4:42 PM, 土卜皿 wrote:
>Recently, for understanding postgresql's optimizer, I read and debug the
> source code. these two days, I read these macros in sysattr.h:
>
> ...
> #define ObjectIdAttributeNumber (-2)
> ...
>
> and the relative codes, but I still did not know why
On 08/17/2014 07:15 PM, Anastasia Lubennikova wrote:
2014-08-07 0:30 GMT+04:00 Heikki Linnakangas :
* I'm getting two regression failures with this (opr_sanity and join).
opr_sanity failure is corrected.
But there is remain question with join.
I check the latest version of my github repo and
hi, Michael
thanks a lot! your reminding lead me go a step forward!
the 7 attributes are system attributes of some table such as pg_class,
pg_type. but now I have a new question:
where and when using these system attributes?
2014-08-18 15:57 GMT+08:00 Michael Paquier :
> On Mon, Aug 18,
Thank you for sharing updated patch. With latest 9.5 source code, patch
build is failing with following error message i.e.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C catalog
> schemapg.h
> cd ../../../src/include/catalog && '/opt/local/bin/perl' ./duplicate_oids
> 3255
> make[3]:
Thanks for the review!
> One question is why reply_fsync is defined as volatile variable?
> Sorry I could not understand reason of that.
It was affected to time_to_abort -- since it is unnecessary, it deletes.
> Currently patch modifies argument of some function (e.g., Handle
> CopyStream, Proc
>According to the measurement result, the amount of WAL generated in
>"Multiple Blocks in one run" than that in "Single Block in one run".
>So ISTM that compression of multiple blocks at one run can improve
>the compression ratio. Am I missing something?
Sorry for using unclear terminology. WAL ge
On Tue, Aug 5, 2014 at 3:41 AM, Noah Misch wrote:
> This remains open for 9.4. Your proposal to revert the feature in 9.4 and fix
> it in 9.5 sounds reasonable.
Ok, I've gone ahead and done this. I'm sorry for the delays and confusion.
> On Thu, Jul 10, 2014 at 04:15:35PM +0100, Greg Stark wrot
In order to support alternatives to OpenSSL, we need to wean off
applications from using PQgetssl(). To do that, we have to provide an
alternative API to get the same information. PQgetSSL() returns a
pointer directly to the OpenSSL private struct, and you can do anything
with that. We cannot h
On Mon, Aug 18, 2014 at 8:30 PM, Greg Stark wrote:
> On Tue, Aug 5, 2014 at 3:41 AM, Noah Misch wrote:
>> This remains open for 9.4. Your proposal to revert the feature in 9.4 and
>> fix
>> it in 9.5 sounds reasonable.
>
> Ok, I've gone ahead and done this. I'm sorry for the delays and confusio
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 8/17/14 5:19 PM, Stephen Frost wrote:
> > Alvaro, all,
> >
> > * Stephen Frost (sfr...@snowman.net) wrote:
> >> As mentioned, I'll add this to the ALTER TABLE documentation and remove
> >> it from the TABLESPACE docs. That's not done yet but I shou
On 08/18/2014 03:04 AM, Marco Nenciarini wrote:
Hi Hackers,
This is the first piece of file level incremental backup support, as
described on wiki page https://wiki.postgresql.org/wiki/Incremental_backup
It is not yet complete, but I wish to share it on the list to receive
comments and suggesti
On Sat, Aug 16, 2014 at 3:28 AM, Noah Misch wrote:
> Nice algorithm.
Thanks.
>> I'd be afraid that a secondary mechanism that mostly-but-not-really
>> works could do more harm by allowing us to miss bugs in the primary,
>> pipe-based locking mechanism than the good it would accomplish.
>
> Users
On Mon, Aug 18, 2014 at 12:55 PM, Michael Paquier
wrote:
> I imagine that you also need to fix the release notes accordingly.
> Patch attached for master and REL9_4_STABLE.
Thanks.
Done for 9.4 but the patch is still in master. In fact it's the most
recent version and I'm still pretty convinced
On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
Marco Nenciarini wrote:
To calculate the md5 checksum I've used the md5 code present in pgcrypto
contrib as the code in src/include/libpq/md5.h is not suitable for large
files. Since a core feature cannot depend on a piece of contrib, I've
moved the
On Mon, Aug 18, 2014 at 10:05 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
>
>> Marco Nenciarini wrote:
>>
>> To calculate the md5 checksum I've used the md5 code present in pgcrypto
>>> contrib as the code in src/include/libpq/md5.h is
On Mon, Aug 18, 2014 at 09:01:20AM -0400, Robert Haas wrote:
> On Sat, Aug 16, 2014 at 3:28 AM, Noah Misch wrote:
> >> I'd be afraid that a secondary mechanism that mostly-but-not-really
> >> works could do more harm by allowing us to miss bugs in the primary,
> >> pipe-based locking mechanism tha
Hi all,
After switching primary serer while using repliaction slot, the
standby server will not able to connect new primary server.
Imagine this situation, if primary server has two ASYNC standby
servers, also use each replication slots.
And the one standby(A) apply WAL without problems. But anoth
I didn't follow the original discussions, but now that I look at this I
have to wonder:
Why does pg_basebackup -T create the symlink pointing to the wrong
location in the first place, only to fix it later? Wouldn't it make a
lot more sense to create it correctly in the first place?
- Heikki
=?UTF-8?B?5Zyf5Y2c55q/?= writes:
> where and when using these system attributes?
http://www.postgresql.org/docs/devel/static/ddl-system-columns.html
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On Mon, Aug 18, 2014 at 7:55 PM, wrote:
> Thanks for the review!
>
>> One question is why reply_fsync is defined as volatile variable?
>> Sorry I could not understand reason of that.
>
> It was affected to time_to_abort -- since it is unnecessary, it deletes.
>
>> Currently patch modifies argumen
Robert, Tom, and others,
Glad to see good discussion and progress on the locking topic!
My proof of concept code (steps a though e below) avoided any reading or
writing to the pipe (and associated handling of SIGPIPE), it just relied on
postmaster open of PIPE with ENXIO to indicate all is clea
On Mon, Aug 18, 2014 at 10:02 PM, Greg Stark wrote:
> On Mon, Aug 18, 2014 at 12:55 PM, Michael Paquier
> wrote:
> Done for 9.4 but the patch is still in master. In fact it's the most
> recent version and I'm still pretty convinced it's a good patch.
If this feature is not going to be part of 9.4
On Fri, Aug 15, 2014 at 4:20 AM, Andres Freund wrote:
> On 2014-08-15 11:12:11 +0300, Marti Raudsepp wrote:
>> Hi
>> On Thu, May 8, 2014 at 4:28 PM, Andres Freund wrote:
>> > Ok. A new version of the patches implementing that are
>> > attached. Including a couple of small fixups and docs. The lat
On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
> On Fri, Aug 15, 2014 at 4:20 AM, Andres Freund wrote:
> > On 2014-08-15 11:12:11 +0300, Marti Raudsepp wrote:
> >> Hi
> >> On Thu, May 8, 2014 at 4:28 PM, Andres Freund
> >> wrote:
> >> > Ok. A new version of the patches implementing that are
>
On Fri, Aug 15, 2014 at 7:17 AM, Fujii Masao wrote:
> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund wrote:
>> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
>>> On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund
>>> wrote:
>>> > On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
>>> >> That's abou
On Fri, Aug 15, 2014 at 8:28 AM, Fujii Masao wrote:
>> Now that we discuss the interactions with other parameters. Another
>> thing that I am wondering about now is: what should we do if we
>> specify s_s_num to a number higher than the elements in s_s_names?
>> Currently, the patch gives the prio
Andres Freund writes:
> On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
>> I fully agree with the idea of exposing the amount of free memory in
>> the shared memory segment (as discussed in other emails); that's
>> critical information. But I think exposing address space layout
>> information is
On 2014-08-18 12:27:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
> >> I fully agree with the idea of exposing the amount of free memory in
> >> the shared memory segment (as discussed in other emails); that's
> >> critical information. But
Heikki Linnakangas wrote:
> On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
> >We already have the FNV checksum implementation in the backend -- can't
> >we use that one for this and avoid messing with MD5?
> >
> >(I don't think we're looking for a cryptographic hash here. Am I wrong?)
>
> Hmm. An
Andres Freund writes:
> On 2014-08-18 12:27:12 -0400, Tom Lane wrote:
>> Should we consider putting it into an extension rather than having
>> it in the core system? That would offer some additional protection
>> for production systems, which really shouldn't have much need for
>> this IMO.
> I'
On 2014-08-18 12:33:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-18 12:27:12 -0400, Tom Lane wrote:
> >> Should we consider putting it into an extension rather than having
> >> it in the core system? That would offer some additional protection
> >> for production systems, whic
On Fri, Aug 15, 2014 at 9:54 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
>>> And what does that actually do? Send back a result-set, or a new
>>> protocol message?
>
>> What I was thinking of was to return "COMMIT X/X" instead of
>> "COMMIT". S
Andres Freund writes:
> On 2014-08-18 12:33:44 -0400, Tom Lane wrote:
>> Well, we could have the implementation code in those modules but not
>> provide any SQL-level access to it without installing an extension.
>> The only extra thing visible in the .h files would be a function or two.
> That'd
On Mon, Aug 18, 2014 at 12:00 PM, Andres Freund wrote:
>> Unfortunately, that information also has some security implications.
>> I'm sure someone trying to exploit any future stack-overrun
>> vulnerability will be very happy to have more rather than less
>> information about the layout of the pro
On 2014-08-18 12:41:58 -0400, Robert Haas wrote:
> On Mon, Aug 18, 2014 at 12:00 PM, Andres Freund
> wrote:
> >> Unfortunately, that information also has some security implications.
> >> I'm sure someone trying to exploit any future stack-overrun
> >> vulnerability will be very happy to have more
On Fri, Aug 15, 2014 at 5:59 PM, worthy7 wrote:
> CREATE INDEX USING GIST(timerange);
>
> On 1.3 million rows this took only 30 seconds.
> on 70 million its already taken over a day. I swear it didn't take this long
> on version 9.3
>
>
> Is there some kind of known bug with GIST? CPU is at 4% or
Robert Haas writes:
> On Fri, Aug 15, 2014 at 9:54 AM, Tom Lane wrote:
>> Au contraire: it will break any piece of code that is expecting a COMMIT
>> command tag to look like exactly "COMMIT" and not "COMMIT something".
> Well, I remember debating this with you once before, when we were
> decidi
On Mon, Aug 18, 2014 at 12:46 PM, Andres Freund wrote:
> On 2014-08-18 12:41:58 -0400, Robert Haas wrote:
>> On Mon, Aug 18, 2014 at 12:00 PM, Andres Freund
>> wrote:
>> >> Unfortunately, that information also has some security implications.
>> >> I'm sure someone trying to exploit any future st
On 2014-08-18 12:50:27 -0400, Robert Haas wrote:
> On Mon, Aug 18, 2014 at 12:46 PM, Andres Freund
> wrote:
> > You realize that you can pretty much recompute the offsets from the
> > sizes of the individual allocations anyway?
>
> Sure, if you know the segment base. Do you?
Err? The offset do
Robert Haas writes:
> I wouldn't mind having a MemoryContextStats()-type function that could
> be used to print this information out by attaching to the backend with
> gdb, but the utility of exposing it at the SQL level seems very
> marginal to me.
+1 for doing it like that.
On Mon, Aug 18, 2014 at 12:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 15, 2014 at 9:54 AM, Tom Lane wrote:
>>> Au contraire: it will break any piece of code that is expecting a COMMIT
>>> command tag to look like exactly "COMMIT" and not "COMMIT something".
>
>> Well, I remember
On Mon, Aug 18, 2014 at 7:19 AM, Rahila Syed wrote:
>>According to the measurement result, the amount of WAL generated in
>>"Multiple Blocks in one run" than that in "Single Block in one run".
>>So ISTM that compression of multiple blocks at one run can improve
>>the compression ratio. Am I missin
On 2014-08-18 13:06:15 -0400, Robert Haas wrote:
> On Mon, Aug 18, 2014 at 7:19 AM, Rahila Syed wrote:
> >>According to the measurement result, the amount of WAL generated in
> >>"Multiple Blocks in one run" than that in "Single Block in one run".
> >>So ISTM that compression of multiple blocks at
On Thu, Jul 3, 2014 at 3:58 PM, Rahila Syed wrote:
> Updated version of patches are attached.
> Changes are as follows
> 1. Improved readability of the code as per the review comments.
> 2. Addition of block_compression field in BkpBlock structure to store
> information about compression of block.
On Mon, Aug 18, 2014 at 12:51 PM, Andres Freund wrote:
> On 2014-08-18 12:50:27 -0400, Robert Haas wrote:
>> On Mon, Aug 18, 2014 at 12:46 PM, Andres Freund
>> wrote:
>> > You realize that you can pretty much recompute the offsets from the
>> > sizes of the individual allocations anyway?
>>
>> S
Robert Haas wrote:
> Moreover, even if somebody is (rather oddly, IMV) checking for
> command_tag == "COMMIT", it's not going to be a difficult change to
> check for command_tag == "COMMIT" or substr(command_tag,0,7) ==
> "COMMIT ". That's a level of incompatibility that would certainly
> deserve
Robert Haas writes:
> I thought you were printing actual pointer addresses. If you're just
> printing offsets relative to wherever the segment happens to be
> mapped, I don't care about that.
Well, that just means that it's not an *obvious* security risk.
I still like the idea of providing some
On 2014-08-18 13:27:07 -0400, Tom Lane wrote:
> I still like the idea of providing something comparable to
> MemoryContextStats, rather than creating a SQL interface. The problem
> with a SQL interface is you can't interrogate it unless (1) you are not
> already inside a query and (2) the client i
On Fri, Aug 15, 2014 at 7:30 PM, Joachim Wieland wrote:
> Attached is a patch that doesn't add any new functionality or
> features, all it does is get rid of the global variables that
> pg_dump.c is full of.
I think this is an excellent idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
On Mon, Aug 18, 2014 at 1:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> I thought you were printing actual pointer addresses. If you're just
>> printing offsets relative to wherever the segment happens to be
>> mapped, I don't care about that.
>
> Well, that just means that it's not an *obviou
On 15 Aug 2014 14:54, "Tom Lane" wrote:
>
> Andres Freund writes:
> > On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
> >> And what does that actually do? Send back a result-set, or a new
> >> protocol message?
>
> > What I was thinking of was to return "COMMIT X/X" instead of
> > "COMMIT". Sin
On 18 Aug 2014 20:05, "Greg Stark" wrote:
>Having it in the commit message guarantees the client never has to deal
with strange states like " I know this transaction committed but I know
when"
Sigh. Typing on the phone. "But I *don't* know when"
On 08/18/2014 07:47 PM, Robert Haas wrote:
I think something's missing from your report, though, because if there
is 3.5 Mb/s of write I/O and only 8 b/s of file growth, nearly all of
the writes are doing something other than extending that file.
Hmm. Sounds like it's churning through temporary
On 08/18/2014 07:33 PM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
We already have the FNV checksum implementation in the backend --
can't we use that one for this and avoid messing with MD5?
(I don't think we're looking for a cryptographic
On 08/12/2014 10:26 AM, Steve Crawford wrote:
On 08/07/2014 04:30 PM, Joshua D. Drake wrote:
Hello,
I know this has been brought up before:
http://www.postgresql.org/message-id/20140724080902.ga28...@msg.df7cb.de
For reference, libpq and packaging issues discussed here as well:
http://www
On Mon, Aug 18, 2014 at 5:47 PM, Robert Haas wrote:
> Sounds pretty weird
I recall GIST being really slow in the distant past in cases where the
page split choices were really bad. Is timerange an interval? Or a
Range?I wonder if the pagesplit function for some of the newish data
types like range
On Mon, Aug 18, 2014 at 12:54 PM, Heikki Linnakangas
wrote:
> server_cert_valid: Did the server present a valid certificate? "yes" or
> "no"
Is this just whether the signature verifies? Or whether the chain is
all verified? Or whether the chain leads to a root in the directory?
Does it include
On 08/19/2014 01:03 AM, Robert Haas wrote:
> 2. I agree that it's not good to have this get controlled by a GUC.
> If the behavior change is big enough that it's going to break clients,
> adding a GUC isn't a sufficient remedy. If it's not, adding a GUC is
> unnecessary.
There's plenty of agreeme
> Thank you for updating the patch.
>
> I did not get error with applying, and compiling.
> It works fine. I think this function code has no problem.
> Could you please submit patch to commit fest app?
Thanks for the review!
As you pointed out, submitted patch to commit fest app.
Regards,
--
F
Hi All,
This is a "proof-of-concept" patch for a new model around role attributes
and fine grained permissions meant to alleviate the current over dependence
on superuser.
This is not yet complete and only serves as a proof-of-concept at this
point, but I wanted to share it in the hopes of receiv
On Mon, Aug 18, 2014 at 6:35 PM, Heikki Linnakangas
wrote:
>
> On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
>>
>> Marco Nenciarini wrote:
>>
>>> To calculate the md5 checksum I've used the md5 code present in pgcrypto
>>> contrib as the code in src/include/libpq/md5.h is not suitable for large
>>
On Fri, Aug 15, 2014 at 11:26:55PM -0400, Noah Misch wrote:
> Barring objections, I will commit your latest patch with some comments about
> why truncation is harmless for those two particular calls.
Done.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Committed after making several fixes, notably:
On Thu, Aug 14, 2014 at 03:59:57PM +0900, Michael Paquier wrote:
> --- a/src/test/isolation/Makefile
> +++ b/src/test/isolation/Makefile
> @@ -6,12 +6,15 @@ subdir = src/test/isolation
> top_builddir = ../../..
> include $(top_builddir)/src/Makefile
On Tue, Aug 19, 2014 at 12:34 PM, Noah Misch wrote:
> Committed after making several fixes, notably:
Thanks a lot, especially for the additional comments.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On Mon, Aug 18, 2014 at 7:50 PM, Heikki Linnakangas
wrote:
>
> I didn't follow the original discussions, but now that I look at this I
have to wonder:
>
> Why does pg_basebackup -T create the symlink pointing to the wrong
location in the first place, only to fix it later?
Good question.
>Wouldn'
On Mon, Aug 18, 2014 at 4:01 PM, Michael Paquier
wrote:
> On Mon, Aug 18, 2014 at 3:48 PM, Fujii Masao wrote:
>> On Mon, Aug 18, 2014 at 2:38 PM, Michael Paquier
>> wrote:
> And now looking at your patch there is additional refactoring possible
> with IDENTIFY_SYSTEM and pg_basebackup as well...
70 matches
Mail list logo
