Hi All,
On Tue, Oct 20, 2015 at 1:22 PM, Pavel Stehule
wrote:
>
> 2015-10-20 20:05 GMT+02:00 Robert Haas :
>
>> On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule
>> wrote:
>> > 2015-10-20 17:15 GMT+02:00 Robert Haas :
>> >> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule <
>> pavel.steh...@gmail.
On 2015-10-22 10:52:36 +0900, Michael Paquier wrote:
> We are close to the end of October, and the numbers are a bit more
> encouraging than at the beginning:
FWIW, I think this has been a commitfest with frustratingly low review
participation outside a few patches.
> Among the five patches marke
On 21.10.2015 02:05, Masahiko Sawada wrote:
On Sat, Oct 10, 2015 at 4:20 AM, Robert Haas wrote:
On Thu, Oct 8, 2015 at 1:52 PM, Andres Freund wrote:
I don't see the problem? I mean catversion will reliably tell you which format
the vm is in?
Totally agreed.
We could additionally use the
On Thu, Oct 22, 2015 at 1:28 AM, Robbie Harwood wrote:
> Michael Paquier writes:
>
>> Robbie,
>>
>> +#ifdef ENABLE_GSS
>> + if (pggss_encrypt(conn) < 0)
>> + return EOF;
>> +#endif
>>
>> @@ -1528,10 +1541,20 @@ socket_putmessage(char msgtype, const char *s,
>> size_t len)
>>
On 2015/10/20 9:36, Kouhei Kaigai wrote:
Even if we fetch whole-row of both side, join pushdown is exactly working
because we can receive less number of rows than local join + 2 of foreign-
scan. (If planner works well, we can expect join-path that increases number
of rows shall be dropped.)
One
On 2015-10-22 16:47:09 +0900, Michael Paquier wrote:
> Hm, and that's why you chose this way of going. My main concern about
> this patch is that it adds on top of the existing Postgres protocol a
> layer to encrypt and decrypt the messages between server and client
> based on GSSAPI. All messages
Hello Andres,
pgbench postgres -M prepared -c 72 -j 72 -P 5 -T 3600 -R4 -L100
progress: 365.0 s, 18392.1 tps, lat 94.857 ms stddev 23.917, lag 90.980 ms,
106244 skipped
100k skipped transactions at a rate limit of 40k? That doesn't seem right.
Argh. It's just because I used -P5. It's
On 2015/10/22 18:20, Fabien COELHO wrote:
>>
>>> progress: 365.0 s, 18392.1 tps, lat 94.857 ms stddev 23.917, lag 90.980
>>> ms, 106244 skipped
>>>
>>> 100k skipped transactions at a rate limit of 40k? That doesn't seem right.
>>
>> Argh. It's just because I used -P5. It's a bit confusing that the
On Thu, Oct 22, 2015 at 6:00 PM, Andres Freund wrote:
> On 2015-10-22 16:47:09 +0900, Michael Paquier wrote:
>> Hm, and that's why you chose this way of going. My main concern about
>> this patch is that it adds on top of the existing Postgres protocol a
>> layer to encrypt and decrypt the message
On 10/22/2015 12:36 AM, Alvaro Herrera wrote:
Andres Freund wrote:
That seems fairly insignificant. For one this is a rather infrequent and
expensive operation, for another every decent compiler can optimize
those away. Note that those duplicate strlen() calls are there in a lot
of places in wa
On 21 October 2015 at 10:07, Victor Wagner wrote:
> On 2015.10.14 at 13:41:51 +0300, Victor Wagner wrote:
>
>>
>> Attached patch which implements client library failover and
>> loadbalancing as was described in the proposal
>> <20150818041850.ga5...@wagner.pp.ru>.
>>
>
> I'm sending imporoved veri
On Mon, Oct 19, 2015 at 6:10 AM, Andres Freund wrote:
> 1) The progress passed to CheckpointWriteDelay() will often be wrong -
>it's calculated as num_written / num_to_write, but num_written is only
>incremented if the buffer hasn't since independently been written
>out. That's bad bec
On Tue, Oct 20, 2015 at 4:58 AM, Syed, Rahila wrote:
>>I think that you should add the flag or something which indicates whether
>>this backend is running VACUUM or not, into PgBackendStatus.
>>pg_stat_vacuum_progress should display the entries of only backends with that
>>flag set true. This de
Andres Freund writes:
> On 2015-10-22 16:47:09 +0900, Michael Paquier wrote:
>> Hm, and that's why you chose this way of going. My main concern about
>> this patch is that it adds on top of the existing Postgres protocol a
>> layer to encrypt and decrypt the messages between server and client
>>
On Tue, Oct 20, 2015 at 6:12 PM, Simon Riggs wrote:
> Not on your case in a big way, just noting the need for change there.
Yes, I appreciate your attitude. I think we are on the same wavelength.
> I'll help as well, but if you could start with enough basics to allow me to
> ask questions that
On Wed, Oct 21, 2015 at 9:04 AM, Amit Langote wrote:
> ... node *need* not be parallel aware?
Yes, thanks. Committed that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Argh. It's just because I used -P5. It's a bit confusing that the other
options are per second, and this is per interval...
I agree, but I'm unsure of a fix, beyond what is already done which is to
show units next to the figures...
ISTM that people expect "tps" for performance, even on severa
* Joe Conway (m...@joeconway.com) wrote:
> On 10/21/2015 12:46 PM, Tom Lane wrote:
> > Attached patch rips out CREATEUSER and NOCREATEUSER options lock, stock,
> > and barrel.
>
> Looks good to me.
>
> > Another possibility is to change them to actually mean CREATEROLE and
> > NOCREATEROLE. I th
Hello Andres,
there would be as much as was written since the last sleep, about 100
ms ago, which is not likely to be gigabytes?
In many cases we don't sleep all that frequently - after one 100ms sleep
we're already behind a lot.
I think that "being behind" is not a problem as such, it is r
Hello.
Currently using nodeToString and stringToNode you can not pass a full plan. In
this regard, what is the plan to fix it? Or in the under task parallel query
does not have such a problem?
> This turns out not to be straightforward to code, because we
> don't have a generic plan tree walker,
On Thu, Oct 22, 2015 at 07:15:35PM +0300, YUriy Zhuravlev wrote:
> Hello.
> Currently using nodeToString and stringToNode you can not pass a
> full plan. In this regard, what is the plan to fix it? Or in the
> under task parallel query does not have such a problem?
>
> > This turns out not to be s
Stephen Frost writes:
> * Joe Conway (m...@joeconway.com) wrote:
>> On 10/21/2015 12:46 PM, Tom Lane wrote:
>>> Attached patch rips out CREATEUSER and NOCREATEUSER options lock, stock,
>>> and barrel.
>> Looks good to me.
>>> Another possibility is to change them to actually mean CREATEROLE and
Syed, Rahila wrote:
> @@ -355,6 +356,7 @@ vacuum(int options, RangeVar *relation, Oid relid,
> VacuumParams *params,
> vac_update_datfrozenxid();
> }
>
> + pgstat_reset_activityflag;
> /*
>* Clean up working storage --- note we must do this after
>
On 2015-10-22 09:52:25 -0400, Robert Haas wrote:
> On Mon, Oct 19, 2015 at 6:10 AM, Andres Freund wrote:
> > 1) The progress passed to CheckpointWriteDelay() will often be wrong -
> >it's calculated as num_written / num_to_write, but num_written is only
> >incremented if the buffer hasn't
On Thu, Oct 22, 2015 at 12:15 PM, YUriy Zhuravlev
wrote:
> Hello.
> Currently using nodeToString and stringToNode you can not pass a full plan. In
> this regard, what is the plan to fix it? Or in the under task parallel query
> does not have such a problem?
It's already fixed. See commits
a0d9f6
On Thu, Oct 22, 2015 at 4:11 PM, Torsten Zühlsdorff
wrote:
> On 21.10.2015 02:05, Masahiko Sawada wrote:
>>
>> On Sat, Oct 10, 2015 at 4:20 AM, Robert Haas
>> wrote:
>>>
>>> On Thu, Oct 8, 2015 at 1:52 PM, Andres Freund wrote:
I don't see the problem? I mean catversion will reliably te
On Thursday 22 October 2015 12:53:49 you wrote:
> On Thu, Oct 22, 2015 at 12:15 PM, YUriy Zhuravlev
>
> wrote:
> > Hello.
> > Currently using nodeToString and stringToNode you can not pass a full
> > plan. In this regard, what is the plan to fix it? Or in the under task
> > parallel query does no
The Gather node, as currently committed, is neither projection-capable
nor listed as an exception in is_projection_capable_plan. Amit
discovered this in testing, and I hit it in my testing as well. We
could just mark it as being not projection-capable, but I think it
might be better to go the oth
On Thu, Oct 22, 2015 at 1:19 PM, YUriy Zhuravlev
wrote:
> And then another question:
> What do you think if the generated equalfuncs.c, copyfuncs.c, readfuncs.c,
> outfuncs.c from XML or JSON?
> In order not to change the code in four places when changing nodes.
It would be more useful, if we're
Robert Haas writes:
> The Gather node, as currently committed, is neither projection-capable
> nor listed as an exception in is_projection_capable_plan. Amit
> discovered this in testing, and I hit it in my testing as well. We
> could just mark it as being not projection-capable, but I think it
On Thursday 22 October 2015 13:25:52 you wrote:
> It would be more useful, if we're going to autogenerate code,
Are we going to use autogenerate code?
> to do it from the actual struct definitions.
I can gen xml/json from actual struct. I offered XML/JSON as the analysis of C
code much more diffi
On 10/22/15 2:20 AM, dinesh kumar wrote:
2. Using this function, if we provide any "NULL" argument to the function,
we should either skip it or report it. I see this is what the function
is doing.
postgres=# SELECT pg_report_log('INFO', 'NULL', false, NULL, NULL);
INFO: NULL
postgres=# SELE
On 21-10-2015 18:36, Andres Freund wrote:
On 2015-10-21 11:52:31 -0300, Euler Taveira wrote:
While testing wal2json, I faced some problems with pg_recvlogical. Attached
is a serie of patches that can improve pg_recvlogical. Patches #2 and #3 are
bugfixes (and should be applied to 9.5 too). Patch
On Thu, Oct 22, 2015 at 11:15 AM, Jim Nasby
wrote:
> On 10/22/15 2:20 AM, dinesh kumar wrote:
>
>>
>> 2. Using this function, if we provide any "NULL" argument to the function,
>> we should either skip it or report it. I see this is what the function
>> is doing.
>>
>> postgres=# SELECT pg_repo
On Thu, Oct 22, 2015 at 1:40 PM, YUriy Zhuravlev
wrote:
> On Thursday 22 October 2015 13:25:52 you wrote:
>> It would be more useful, if we're going to autogenerate code,
> Are we going to use autogenerate code?
I thought that's what you were proposing. Process the struct
definitions and emit .c
On Thu, Oct 22, 2015 at 1:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> The Gather node, as currently committed, is neither projection-capable
>> nor listed as an exception in is_projection_capable_plan. Amit
>> discovered this in testing, and I hit it in my testing as well. We
>> could just
On Tue, Oct 20, 2015 at 6:29 PM, Jim Nasby wrote:
> On 10/20/15 11:08 AM, CharSyam wrote:
>>
>> I fixed some typos in posgres.
>> They are all in comments. :)
>
> These all look good to me. RFC.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compan
Robert Haas wrote:
> On Thu, Oct 22, 2015 at 1:38 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> The Gather node, as currently committed, is neither projection-capable
> >> nor listed as an exception in is_projection_capable_plan. Amit
> >> discovered this in testing, and I hit it in my testin
On Wed, Oct 14, 2015 at 4:06 PM, Robert Haas wrote:
> On Wed, Oct 14, 2015 at 6:28 PM, dinesh kumar
> wrote:
> > I see this feature as an add on to do the parallel DML operations.
> > There won't be any problem, if operations are mutually exclusive.
> > I mean, each session operates on unique se
On Thu, Oct 22, 2015 at 3:18 PM, Alvaro Herrera
wrote:
>> You probably would, but sometimes that might not be possible; for
>> example, the tlist might contain a parallel-restricted function (which
>> therefore has to run in the leader).
>
> I don't understand your reply. Failing to parallelize t
On 10/22/15 3:20 AM, dinesh kumar wrote:
> postgres=# SELECT pg_report_log('INFO', 'NULL', false, NULL, NULL);
> INFO: NULL
>
> postgres=# SELECT pg_report_log('INFO', 'NULL', false, 'NULL', 'NULL');
> INFO: NULL
> DETAIL: NULL /-- Are you suggesting to change this behaviour/
> HINT: NULL
Th
On Tue, Oct 20, 2015 at 11:42 PM, Rajeev rastogi
wrote:
> Agreed. Attached is the patch with changes.
Well, I'm not buying this extra PostmasterIsAlive() call on every pass
through the main loop. That seems more expensive than we can really
justify. Checking this when we're already calling WaitL
Robert Haas writes:
> On Thu, Oct 22, 2015 at 1:40 PM, YUriy Zhuravlev
> wrote:
>> I can gen xml/json from actual struct. I offered XML/JSON as the analysis of
>> C
>> code much more difficult. But my current generator just use the structure
>> from
>> the header files (by pycparser).
> Anythi
On Fri, Oct 16, 2015 at 5:08 PM, Robert Haas wrote:
> The shm_mq code handles blocking mode and non-blocking mode
> asymmetrically in a couple of places, with the unfortunate result that
> if you are using non-blocking mode, and your counterparty dies before
> attaching the queue, operations on th
On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 22, 2015 at 1:40 PM, YUriy Zhuravlev
>> wrote:
>>> I can gen xml/json from actual struct. I offered XML/JSON as the analysis
>>> of C
>>> code much more difficult. But my current generator just use the structu
On Wed, Oct 21, 2015 at 1:51 AM, Amit Langote
wrote:
> This may just be nitpicking but I noticed that ATWrongRelkindError() could
> emit a better message in case of such errors during ALTER COLUMN DEFAULT
> and ALTER COLUMN SET STORAGE than "%s is of the wrong type" which is what
> it would emit
Robert Haas writes:
> On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane wrote:
>> I'm not sure that you could get to a point where you were
>> generating this stuff from anything that wasn't in essence an arcane
>> representation of the .c files. It might be slightly harder to make
>> errors of omission
On Thu, Oct 22, 2015 at 5:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane wrote:
>>> I'm not sure that you could get to a point where you were
>>> generating this stuff from anything that wasn't in essence an arcane
>>> representation of the .c files. I
On Wed, Oct 21, 2015 at 5:23 AM, Ashutosh Bapat
wrote:
> Increasing the sorting cost factor (when use_remote_estimates = false) from
> 1.1 to 1.2 makes the difference disappear.
>
> Since the startup costs for postgres_fdw are large portion of total cost,
> extra 10% of rest of the cost is compara
On Wed, Oct 21, 2015 at 1:31 PM, Jeff Janes wrote:
> It turns out it was pretty easy to set PD_ALL_VISIBLE on the new pages,
> since the code in hio that requests the relation to be extended already has
> info on the tuple's intended freeze status.
>
> Then you just need to refrain from clearing P
On Wed, Oct 21, 2015 at 1:33 PM, Jim Nasby wrote:
> Currently, xid_age() returns INT_MAX for a permanent xid. The comment in the
> function that 'Permanent XIDs are always infinitely old' may be technically
> correct, but returning INT_MAX is a useless behavior because it actually
> makes it look
On Wed, Oct 21, 2015 at 8:54 PM, Thomas Munro
wrote:
> Here is a new version merging the recent CREATE EXTENSION ... VERSION
> patch from master.
>
> (Apologies for sending so many versions. tab-complete.c keeps moving
> and I want to keep a version that applies on top of master out there,
> for
ISTM it should be possible to avoid sending full page writes to a
streaming replica once the replica has reached a consistent state. I
assume that the replica would still need to write full pages to it's
disk in case of a crash, but the sender could insert special WAL records
to tell it when to
Robert Haas writes:
> On Wed, Oct 21, 2015 at 8:54 PM, Thomas Munro
> wrote:
>> (Apologies for sending so many versions. tab-complete.c keeps moving
>> and I want to keep a version that applies on top of master out there,
>> for anyone interested in looking at this. As long as no one objects
>>
Jim Nasby writes:
> ISTM it should be possible to avoid sending full page writes to a
> streaming replica once the replica has reached a consistent state. I
> assume that the replica would still need to write full pages to it's
> disk in case of a crash, but the sender could insert special WAL
Hi
2015-10-22 22:03 GMT+02:00 Peter Eisentraut :
> On 10/22/15 3:20 AM, dinesh kumar wrote:
> > postgres=# SELECT pg_report_log('INFO', 'NULL', false, NULL, NULL);
> > INFO: NULL
> >
> > postgres=# SELECT pg_report_log('INFO', 'NULL', false, 'NULL', 'NULL');
> > INFO: NULL
> > DETAIL: NULL /-
On Oct 22, 2015 23:38, "Tom Lane" wrote:
>
> Jim Nasby writes:
> > ISTM it should be possible to avoid sending full page writes to a
> > streaming replica once the replica has reached a consistent state. I
> > assume that the replica would still need to write full pages to it's
> > disk in case o
Tom Lane wrote:
> What I would like is to find a way to auto-generate basically this entire
> file from gram.y. That would imply going over to something at least
> somewhat parser-based, instead of the current way that is more or less
> totally ad-hoc. That would be a very good thing though, bec
On 10/22/15 4:18 PM, Robert Haas wrote:
On Wed, Oct 21, 2015 at 1:33 PM, Jim Nasby wrote:
Currently, xid_age() returns INT_MAX for a permanent xid. The comment in the
function that 'Permanent XIDs are always infinitely old' may be technically
correct, but returning INT_MAX is a useless behavior
On 10/22/15 4:42 PM, Pavel Stehule wrote:
the behave of pg_report_log should not be exactly same as RAISE
statement in PLpgSQL.
That makes no sense to me. Having different behaviors is just going to
lead to confusion.
If this function will be exactly same, then it
lost a sense and anybody c
2015-10-22 20:15 GMT+02:00 Jim Nasby :
> On 10/22/15 2:20 AM, dinesh kumar wrote:
>
>>
>> 2. Using this function, if we provide any "NULL" argument to the function,
>> we should either skip it or report it. I see this is what the function
>> is doing.
>>
>> postgres=# SELECT pg_report_log('INFO'
On 10/22/15 4:42 PM, Magnus Hagander wrote:
> How are you going to make that work without LSNs in the WAL received by
> the replica diverging from those in the master's WAL?
>
We could in theory send a "this would be been a fpi but it's skipped"
record which would only exist in streaming and
2015-10-22 23:54 GMT+02:00 Jim Nasby :
> On 10/22/15 4:42 PM, Pavel Stehule wrote:
>
>> the behave of pg_report_log should not be exactly same as RAISE
>> statement in PLpgSQL.
>>
>
> That makes no sense to me. Having different behaviors is just going to
> lead to confusion.
>
> If this function w
On 2015-10-22 16:34:38 -0500, Jim Nasby wrote:
> ISTM it should be possible to avoid sending full page writes to a streaming
> replica once the replica has reached a consistent state. I assume that the
> replica would still need to write full pages to it's disk in case of a
> crash, but the sender
On Thu, Oct 22, 2015 at 5:51 PM, Jim Nasby wrote:
> It's also a permanent ID when the relation is first created.
No it isn't. If it were, the first insert into the table would have
to update the pg_class tuple, which it certainly doesn't. Before we
had MVCC catalog scans, that wouldn't have bee
On 10/22/15 4:59 PM, Pavel Stehule wrote:
It prevents everyone from reinventing the 'create a function wrapper
around RAISE' wheel that several people on this list alone have
admitted to. I think there's plenty of value in that.
I have different opinion, I am sorry. The RAISE statem
On Thu, Oct 22, 2015 at 5:57 PM, Jim Nasby wrote:
>> We could in theory send a "this would be been a fpi but it's skipped"
>> record which would only exist in streaming and just make the standby
>> write a noop of some kind? It would still be on the standby but it would
>> at least not consume the
On Thu, Oct 22, 2015 at 02:36:53PM -0700, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Oct 21, 2015 at 8:54 PM, Thomas Munro
> > wrote:
> >> (Apologies for sending so many versions. tab-complete.c keeps moving
> >> and I want to keep a version that applies on top of master out there,
> >> f
On 2015-10-22 18:07:06 -0400, Robert Haas wrote:
> > BTW, ignoring relfrozenxid = 0 also isn't as easy as you'd think:
> >
> > select count(*) from pg_class where relfrozenxid <> 0;
> > ERROR: operator does not exist: xid <> integer at character 50
>
> It takes a few more characters than that, bu
2015-10-23 0:07 GMT+02:00 Jim Nasby :
> On 10/22/15 4:59 PM, Pavel Stehule wrote:
>
>> It prevents everyone from reinventing the 'create a function wrapper
>> around RAISE' wheel that several people on this list alone have
>> admitted to. I think there's plenty of value in that.
>>
>>
Andres Freund wrote:
> FWIW, adding an <> operator for xid seems like a perfectly good idea.
+1 (two of them actually -- another one for <>(xid,int) which mirrors
the =(xid,int) we already have).
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On 10/22/15 5:03 PM, Andres Freund wrote:
On 2015-10-22 16:34:38 -0500, Jim Nasby wrote:
ISTM it should be possible to avoid sending full page writes to a streaming
replica once the replica has reached a consistent state. I assume that the
replica would still need to write full pages to it's dis
On 10/22/15 5:11 PM, Robert Haas wrote:
It's true that if the standby didn't have the master's FPIs, it could
generate its own in some side location that behaves like a separate
WAL stream or a double-write buffer. But that would be a heck of a
lot of work to implement for an uncertain benefit.
On 2015-10-22 17:47:01 -0500, Jim Nasby wrote:
> On 10/22/15 5:11 PM, Robert Haas wrote:
> >It's true that if the standby didn't have the master's FPIs, it could
> >generate its own in some side location that behaves like a separate
> >WAL stream or a double-write buffer. But that would be a heck
Jim Nasby wrote:
> But yes, this is all very hand-wavy without any actual data on what
> percentage of the WAL stream is FPIs. Looks like pageinspect doesn't work
> for WAL... does anyone have a script/tool that breaks out what percentage of
> a WAL file is FPIs?
pg_xlogdump -z
--
Álvaro Herrer
On 10/22/15 5:07 PM, Robert Haas wrote:
On Thu, Oct 22, 2015 at 5:51 PM, Jim Nasby wrote:
>It's also a permanent ID when the relation is first created.
No it isn't.
Is there no case where it can be a permanent XID for a table or toast table?
The other issue is relminmxid, which if you're lo
On 10/22/15 5:52 PM, Andres Freund wrote:
If the receiver didn't write the WAL before processing it then it can just
>stick the page image into the WAL it's writing for itself. Probably not good
>for syncrep, but I don't think you'd want this on for syncrep anyway.
To me this sounds like a recip
On 2015-10-22 17:59:06 -0500, Jim Nasby wrote:
> The WAL would *not* differ.
It would. Hint bits and all.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> The original post used only "0.0.0.0" and "::", not "localhost" or anything
> else entailing name resolution. As I wrote above, Kondo proposed for pg_ctl
> to use PQping("host='127.0.0.1'") in place of PQping("host='0.0.0.0'").
> That's all. pg_ctl would continue to use PQping("host='localhost'
David Fetter writes:
> On Thu, Oct 22, 2015 at 02:36:53PM -0700, Tom Lane wrote:
>> I have no very good idea how to do that, though. Bison does have a
>> notion of which symbols are possible as the next symbol at any given
>> parse point, but it doesn't really make that accessible. There's a lac
On Thu, Oct 22, 2015 at 7:05 PM, Tom Lane wrote:
> I think it's already true that the previous lines of the query buffer
> are stashed somewhere that psql knows about,
Just skimming but:
"""
\p or \print
Print the current query buffer to the standard output.
"""
http://www.postgresql.org/
Tatsuo Ishii writes:
>> The original post used only "0.0.0.0" and "::", not "localhost" or anything
>> else entailing name resolution. As I wrote above, Kondo proposed for pg_ctl
>> to use PQping("host='127.0.0.1'") in place of PQping("host='0.0.0.0'").
>> That's all. pg_ctl would continue to us
On 10/22/15 5:53 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
But yes, this is all very hand-wavy without any actual data on what
percentage of the WAL stream is FPIs. Looks like pageinspect doesn't work
for WAL... does anyone have a script/tool that breaks out what percentage of
a WAL file is FP
On 2015-10-22 16:15:10 -0700, Tom Lane wrote:
> AFAICS, the only hard-wired hostname reference in pg_ctl is "localhost",
> not "127.0.0.1" (much less "0.0.0.0"). So what you're proposing doesn't
> seem to me to have anything to do with what's there. I continue to think
> that the OP's complaint i
On Thu, Oct 22, 2015 at 6:57 PM, Jim Nasby wrote:
> Is there no case where it can be a permanent XID for a table or toast table?
I don't think so.
> The other issue is relminmxid, which if you're looking at relfrozenxid you'd
> want to look at as well. So you can't do a simple WHERE here.
I don
On Thu, Oct 22, 2015 at 04:05:06PM -0700, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Oct 22, 2015 at 02:36:53PM -0700, Tom Lane wrote:
> >> I have no very good idea how to do that, though. Bison does have a
> >> notion of which symbols are possible as the next symbol at any given
> >> par
Jim Nasby wrote:
> On 10/22/15 5:53 PM, Alvaro Herrera wrote:
> >Jim Nasby wrote:
> >
> >>But yes, this is all very hand-wavy without any actual data on what
> >>percentage of the WAL stream is FPIs. Looks like pageinspect doesn't work
> >>for WAL... does anyone have a script/tool that breaks out w
On 2015/10/23 6:06, Robert Haas wrote:
> On Wed, Oct 21, 2015 at 1:51 AM, Amit Langote
> wrote:
>> Attached adds those.
>
> Good catch. Committed and back-patched to 9.5.
>
> (Yes, one of these problems goes back to 9.3, but it's a minor issue
> so I didn't bother. If someone really feels the
On 10/21/15 3:14 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
While warning a client that just did a Slony-based version upgrade to make
sure to freeze the new database, it occurred to me that it should be safe to
freeze without the cleanup lock. This is interesting because it would allow
a scan_a
Jim Nasby wrote:
> That would be the minimal-impact version, yes. But I suspect if we went
> through the trouble to do that, it would be just as easy to attempt the
> freeze regardless of what scan_all is set to.
You mean if !scan_all we conditional-get the cleanup lock, if we get it
then prune,
On 2015-10-22 20:27:20 -0300, Alvaro Herrera wrote:
> You can run the new one in old pg_xlog ...
You can? The xlog format between 9.4 and 9.5 changed, so I can't see how
that'd work?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Tue, Oct 13, 2015 at 5:59 PM, Robert Haas wrote:
> - Although the changes in parallelpaths.c are in a good direction, I'm
> pretty sure this is not yet up to scratch. I am less sure exactly
> what needs to be fixed, so I'll have to give some more thought to
> that.
Please find attached a prop
Andres Freund writes:
> Perhaps we should start to emit a notice at startup if localhost doesn't
> resolve to either v4 or v6 definitions. The few environments where
> that's indeed intentionally not the case, should be fine with such a
> message at pgstat startup.
I think there's already a compl
David Fetter writes:
> On Thu, Oct 22, 2015 at 04:05:06PM -0700, Tom Lane wrote:
>> Given the license issues around GNU readline, requiring it seems like
>> probably a non-starter.
> I should have made this more clear. I am not an IP attorney and don't
> play one on TV, but this is what I've got
On Fri, Oct 23, 2015 at 7:37 AM, Jim Nasby wrote:
> What I'm wondering is how compressible a 'normal' FPI is. Certainly if the
> hole is zero'd out and the page is mostly empty you'll get great
> compression. What about other workloads? For reference, if a 'FPI
> placeholder' WAL record is 16 bytes
On Fri, Oct 23, 2015 at 8:42 AM, Andres Freund wrote:
> On 2015-10-22 20:27:20 -0300, Alvaro Herrera wrote:
>> You can run the new one in old pg_xlog ...
>
> You can? The xlog format between 9.4 and 9.5 changed, so I can't see how
> that'd work?
That's not going to work.
--
Michael
--
Sent vi
On 2015-10-22 16:26:10 -0700, David Fetter wrote:
> To be affective negatively by libreadline's viral license, an entity
> would need to fork the psql client in proprietary ways that they did
> not wish not to make available to end users, at the same time linking
> in libreadline.
> Maybe I'm miss
On Thu, Oct 22, 2015 at 04:15:10PM -0700, Tom Lane wrote:
> Tatsuo Ishii writes:
> >> The original post used only "0.0.0.0" and "::", not "localhost" or anything
> >> else entailing name resolution. As I wrote above, Kondo proposed for
> >> pg_ctl
> >> to use PQping("host='127.0.0.1'") in place
On 21 October 2015 at 13:31, Jeff Janes wrote:
> On Tue, Oct 20, 2015 at 7:02 AM, Robert Haas
> wrote:
>
>> On Sun, Oct 18, 2015 at 5:23 PM, Jeff Janes wrote:
>> > I'm planning on adding a todo item to have COPY FREEZE set
>> PD_ALL_VISIBLE.
>> > Or is there some reason this can't be done?
>> >
On 18 October 2015 at 17:23, Jeff Janes wrote:
> I'm planning on adding a todo item to have COPY FREEZE set
> PD_ALL_VISIBLE. Or is there some reason this can't be done?
>
> Since the whole point of COPY FREEZE is to avoid needing to rewrite the
> entire table, it seems rather perverse that the
1 - 100 of 112 matches
Mail list logo
