-thinking the null semantics.
3. perhaps fix typmod
4. documentation
5. more tests
7. better parser
Regards,
Jeff Davis
rangetypes-20110114.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
2011/1/12 Alvaro Herrera alvhe...@commandprompt.com:
I think this code should live in the Wiki somewhere:
http://wiki.postgresql.org/wiki/Snippets
This file contains only the relevant remapping of pg_depend, folding
the internal linkages properly:
On Fri, Jan 14, 2011 at 09:39, Joel Jacobson j...@gluefinance.com wrote:
2011/1/12 Alvaro Herrera alvhe...@commandprompt.com:
I think this code should live in the Wiki somewhere:
http://wiki.postgresql.org/wiki/Snippets
This file contains only the relevant remapping of pg_depend, folding
the
On 14.01.2011 08:45, Fujii Masao wrote:
On Fri, Jan 14, 2011 at 4:13 AM, Magnus Hagandermag...@hagander.net wrote:
At the end of the backup by walsender, it forces a switch to a new
WAL file and waits until the last WAL file has been archived. So we
should change postmaster so that it doesn't
On 01/14/2011 02:21 AM, Kevin Grittner wrote:
I hope you have no objection to having the code you wrote included
in the test suite which is part of the patch. Well, if you do, I'll
pull it back out and invent something similar... ;-)
No objection.
- Anssi
--
Sent via pgsql-hackers mailing
Robert Haas robertmh...@gmail.com writes:
So far I have 6 people who have volunteered to be round-robin
reviewers, and 7 people who are listed as reviewers on the CF site
already. That leaves 45 patches without a reviewer, plus whatever
comes in in the next day or so. This is not going to
Functions to control recovery, to aid PITR and Hot Standby.
pg_is_xlog_replay_paused()
pg_xlog_replay_pause()
pg_xlog_replay_resume()
recovery.conf parameter: pause_at_recovery_target (bool)
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support,
On Fri, 2011-01-14 at 11:09 +, Simon Riggs wrote:
Functions to control recovery, to aid PITR and Hot Standby.
pg_is_xlog_replay_paused()
pg_xlog_replay_pause()
pg_xlog_replay_resume()
recovery.conf parameter: pause_at_recovery_target (bool)
And now with the correct patch.
--
Simon
On Mon, 2010-12-13 at 17:15 +, Peter Geoghegan wrote:
On 13 December 2010 16:08, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs si...@2ndquadrant.com wrote:
2. pg_validate_foreign_key('constraint name');
Returns immediately if FK is valid
On Fri, Jan 14, 2011 at 11:19, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14.01.2011 08:45, Fujii Masao wrote:
On Fri, Jan 14, 2011 at 4:13 AM, Magnus Hagandermag...@hagander.net
wrote:
At the end of the backup by walsender, it forces a switch to a new
WAL file and
2011/1/13 KaiGai Kohei kai...@ak.jp.nec.com:
I tried to pick up this patch to review.
It seems to me fine, enough simple and works as explained in the
implementation level, apart from reasonability of this feature.
(Tom was not 100% agree with this feature 1.5month ago.)
Did you check
On Fri, Jan 14, 2011 at 12:15, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2011-01-14 at 11:09 +, Simon Riggs wrote:
Functions to control recovery, to aid PITR and Hot Standby.
pg_is_xlog_replay_paused()
pg_xlog_replay_pause()
pg_xlog_replay_resume()
recovery.conf parameter:
On 14.01.2011 13:15, Simon Riggs wrote:
/*
+ * Recheck shared recoveryPause by polling.
+ *
+ * XXX It might seem we should do this via a shared Latch, but
+ * currently we only support one shared latch per process and
+ * that is already taken for Startup process. Polling is used
+ * in other
On Fri, 2011-01-14 at 12:41 +0100, Magnus Hagander wrote:
On Fri, Jan 14, 2011 at 12:15, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2011-01-14 at 11:09 +, Simon Riggs wrote:
Functions to control recovery, to aid PITR and Hot Standby.
pg_is_xlog_replay_paused()
On Fri, 2011-01-14 at 13:47 +0200, Heikki Linnakangas wrote:
On 14.01.2011 13:15, Simon Riggs wrote:
/*
+ * Recheck shared recoveryPause by polling.
+ *
+ * XXX It might seem we should do this via a shared Latch, but
+ * currently we only support one shared latch per process and
+ *
On 14.01.2011 14:01, Simon Riggs wrote:
On Fri, 2011-01-14 at 13:47 +0200, Heikki Linnakangas wrote:
On 14.01.2011 13:15, Simon Riggs wrote:
/*
+ * Recheck shared recoveryPause by polling.
+ *
+ * XXX It might seem we should do this via a shared Latch, but
+ * currently we only support one
On Thu, Jan 13, 2011 at 4:54 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 11, 2011 at 9:17 PM, Robert Haas robertmh...@gmail.com wrote:
[ abject plea for reviewers ]
[ second abject please for reviewers ]
OK, I believe I've sent an off-list email to everyone who volunteered
to
On 14.01.2011 14:10, Simon Riggs wrote:
Please make that the last commit in this area for next week.
I want to get a base from which to solidify the sync rep code, and
associated patches.
I'm not saying there will be a code clash, but there may be a clash of
detail or intention that will make
On Fri, 2011-01-14 at 14:08 +0200, Heikki Linnakangas wrote:
On 14.01.2011 14:01, Simon Riggs wrote:
On Fri, 2011-01-14 at 13:47 +0200, Heikki Linnakangas wrote:
On 14.01.2011 13:15, Simon Riggs wrote:
/*
+ * Recheck shared recoveryPause by polling.
+ *
+ * XXX It might seem we
On Fri, Jan 14, 2011 at 13:16, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14.01.2011 14:10, Simon Riggs wrote:
Please make that the last commit in this area for next week.
I want to get a base from which to solidify the sync rep code, and
associated patches.
I'm not
is assumed to
be used by FDWs.
You would be able to test these patches with 20110114 version of file_fdw
wrapper patches which will be posted in another thread.
Regards,
--
Shigeru Hanada
20110114-fdw_handler.patch.gz
Description: Binary data
20110114-foreign_scan.patch.gz
Description: Binary data
On Fri, 2011-01-14 at 14:16 +0200, Heikki Linnakangas wrote:
On 14.01.2011 14:10, Simon Riggs wrote:
Please make that the last commit in this area for next week.
I want to get a base from which to solidify the sync rep code, and
associated patches.
I'm not saying there will be a code
On 14.01.2011 14:18, Simon Riggs wrote:
On Fri, 2011-01-14 at 14:08 +0200, Heikki Linnakangas wrote:
On 14.01.2011 14:01, Simon Riggs wrote:
On Fri, 2011-01-14 at 13:47 +0200, Heikki Linnakangas wrote:
On 14.01.2011 13:15, Simon Riggs wrote:
/*
+ * Recheck shared recoveryPause by polling.
On Fri, Jan 14, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
My request is not unreasonable. Please be helpful, as you would expect
me to be if the roles were reversed.
I can't remember anyone other than you ever requesting that.
--
Robert Haas
EnterpriseDB:
On 14.01.2011 14:25, Simon Riggs wrote:
On Fri, 2011-01-14 at 14:16 +0200, Heikki Linnakangas wrote:
None of that should conflict seriously with the synch rep code, although
it's hard to tell without seeing the patch. And even if it does, we'll
just resolve the conflict, merge conflicts are not
On Fri, 2011-01-14 at 14:27 +0200, Heikki Linnakangas wrote:
Trouble is, if you wait on Latch X and other processes send wakeup
assuming you were waiting on Latch Y, then this will erroneously wake
you up.
The signal will wake up the process, but WaitLatch will quickly go back
to sleep
On Thu, Jan 13, 2011 at 22:32, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 13.01.2011 22:57, Josh Berkus wrote:
On 1/13/11 12:11 PM, Robert Haas wrote:
That's going to depend on the situation. If the database fits in
memory, then it's just going to work. If it fits on
On Thu, Jan 13, 2011 at 7:31 PM, Tatsuo Ishii is...@postgresql.org wrote:
Tatsuo Ishii is...@postgresql.org writes:
Please add this to the currently open CommitFest:
https://commitfest.postgresql.org/action/commitfest_view/open
Done. Comments are welcome. Unless there's objection, I will
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of jue ene 13 00:05:53 -0300 2011:
Srini Raghavan wrote:
Thank you very much for reviewing, appreciate the feedback.? As pointed
out by
you, it is always best to test it out with the latest version, so, I
tested the
On Tue, Jan 11, 2011 at 8:31 PM, Robert Haas robertmh...@gmail.com wrote:
In that case, can I have some comments on approaches mentioned in my OP?
Tom - I am willing to implement this if you think it's valuable, but
I'd like your input on the syntax.
On Fri, Jan 14, 2011 at 9:13 AM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of jue ene 13 00:05:53 -0300 2011:
Srini Raghavan wrote:
Thank you very much for reviewing, appreciate the feedback.? As pointed
out by
you, it is always
Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
Also, I don't really like the way this spreads knowledge of the
completionTag out all over the backend. I think it would be better to
follow the existing model used by the COPY and COMMIT commands,
whereby the return
Excerpts from Robert Haas's message of vie ene 14 11:18:16 -0300 2011:
I'd rather remove the deprecating warning.
+1
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via
On Fri, Jan 14, 2011 at 9:24 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
Also, I don't really like the way this spreads knowledge of the
completionTag out all over the backend. I think it would be better to
Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message:
I'd rather remove the deprecating warning.
+1
+1
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane t...@sss.pgh.pa.us writes:
Another little problem with the quick and dirty solution is that stuff
that's important enough to warrant a log_line_prefix escape is generally
thought to be important enough to warrant inclusion in CSV logs. That
would imply adding a column and taking the
Excerpts from Robert Haas's message of vie ene 14 00:03:53 -0300 2011:
On Thu, Jan 13, 2011 at 8:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
True. It strikes me also that the postmaster does provide some services
other than accepting new connections:
* ensuring that everybody gets killed
Review:
The only possible point of concern I see here is the naming of the C
identifier. Everything else in class 40 uses ERRCODE_T_R_whatever,
with T_R standing for transaction rollback. It's not obvious to me
that that convention has any real value, but perhaps we ought to
follow it
Alvaro Herrera alvhe...@commandprompt.com wrote:
If postmaster dies, and then another backend crashes, then your
backend running your honking big query could run across
corrupted state and then you'd be in serious trouble.
Worst of all, it could give bogus results without error. I really
Hi all!
In preperation of some further improvments to our infrastructure, the
sysadmin team needs to move coridian.postgresql.org (aka
commitfest.postgresql.org) and mintaka.postgresql.org
(media.postgresql.org) to a different host within the same datacenter.
We are planning to do that
On Jan14, 2011, at 17:22 , Kevin Grittner wrote:
Alvaro Herrera alvhe...@commandprompt.com wrote:
If postmaster dies, and then another backend crashes, then your
backend running your honking big query could run across
corrupted state and then you'd be in serious trouble.
Worst of all, it
On 01/12/2011 08:59 PM, Tom Lane wrote:
I'm not actually concerned about adding a few extra cycles to SET ROLE
for this. What bothered me more was the cost of adding another output
column to CSV log mode. That's not something you're going to be able to
finesse such that only people who care
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I seem to recall that the assign hook for role stores the string form of
the role name anyway.
Indeed it does, and it's already exposed through show_role() since it's
needed in guc.c. Based on my review and understanding of the comments
and calls, it
Andrew Dunstan and...@dunslane.net writes:
On 01/12/2011 08:59 PM, Tom Lane wrote:
I'm not actually concerned about adding a few extra cycles to SET ROLE
for this. What bothered me more was the cost of adding another output
column to CSV log mode. That's not something you're going to be able
On Fri, Jan 14, 2011 at 11:28 AM, Florian Pflug f...@phlo.org wrote:
I gather that the behaviour we want is for normal backends to exit
once the postmaster is gone, and for utility processes (bgwriter, ...)
to exit once all the backends are gone.
The test program I posted in this thread
On Fri, Jan 14, 2011 at 10:53 AM, Tatsuo Ishii is...@postgresql.org wrote:
Review:
The only possible point of concern I see here is the naming of the C
identifier. Everything else in class 40 uses ERRCODE_T_R_whatever,
with T_R standing for transaction rollback. It's not obvious to me
that
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Andrew Dunstan and...@dunslane.net writes:
I think it's time to revisit the design of CSV logs again, now we have
two or three releases worth of experience with it. It needs some
flexibility and refinement.
It would definitely be nice to support
Tatsuo Ishii is...@postgresql.org writes:
Review:
The only possible point of concern I see here is the naming of the C
identifier. Everything else in class 40 uses ERRCODE_T_R_whatever,
with T_R standing for transaction rollback. It's not obvious to me
that that convention has any real
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
Also, I don't really like the way this spreads knowledge of the
completionTag out all over the backend. I think it would be better to
follow the existing model used by the
On Fri, 2011-01-14 at 12:07 -0500, Tom Lane wrote:
I thought we were going to reject the patch outright anyway. The
compatibility consequences of changing command tags are not worth the
benefit, independently of how ugly the backend-side code may or may
not be.
+1
--
Simon Riggs
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Alvaro Herrera alvhe...@commandprompt.com wrote:
I'd rather remove the deprecating warning.
+1
+1
The reason for wanting to deprecate and ultimately remove that syntax is
so we can get rid of FREEZE as a reserved word.
We could probably
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
My request is not unreasonable. Please be helpful, as you would expect
me to be if the roles were reversed.
I can't remember anyone other than you ever requesting that.
Yes.
Here's the patch to add ENCODING option to COPY command.
The fundamental issue was explained months ago:
http://archives.postgresql.org/message-id/AANLkTikCt6bHXZjO_oX+JS7+G=jaq7gvzpu0owjcs...@mail.gmail.com
In short, client_encoding is not appropriate for copy operation so we
should need the
On Fri, 2011-01-14 at 12:04 -0500, Tom Lane wrote:
Tatsuo Ishii is...@postgresql.org writes:
Review:
The only possible point of concern I see here is the naming of the C
identifier. Everything else in class 40 uses ERRCODE_T_R_whatever,
with T_R standing for transaction rollback. It's
Tom Lane t...@sss.pgh.pa.us wrote:
The reason for wanting to deprecate and ultimately remove that
syntax is so we can get rid of FREEZE as a reserved word.
We could probably still allow the new-style syntax VACUUM (FREEZE)
Oh, OK. I can go along with that. If we're going that route,
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 10:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This appears to remove the BM_JUST_DIRTIED logic. Please explain why
that's not completely broken. Even if it isn't completely broken,
it would seem better to do something like that
On Fri, Jan 14, 2011 at 12:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 10:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This appears to remove the BM_JUST_DIRTIED logic. Please explain why
that's not completely broken. Even if it
On Thu, 2011-01-13 at 23:32 +0200, Heikki Linnakangas wrote:
On 13.01.2011 22:57, Josh Berkus wrote:
On 1/13/11 12:11 PM, Robert Haas wrote:
That's going to depend on the situation. If the database fits in
memory, then it's just going to work. If it fits on disk, it's less
obvious
On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
Something else that might be of interest: the patch as presented here
does NOT solve the deadlock problem originally presented by Joel
Jacobson. It does solve the second, simpler example I presented in my
blog article referenced above,
Robert Haas robertmh...@gmail.com wrote:
this seems to be speeding up the first run by 6x at the expense of
slowing down many subsequent runs by 10-15%.
If the overall throughput when measured far enough out to have hit a
steady state again is anywhere in the neighborhood of the unpatched
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
The reason for wanting to deprecate and ultimately remove that
syntax is so we can get rid of FREEZE as a reserved word.
Oh, OK. I can go along with that. If we're going that route,
though, shouldn't we
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 12:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Moreover this whole business of not treating hint-bit setting as
a page-dirtying operation is completely experimental/unproven IMO, so it
would be better to keep the patch footprint
On Fri, Jan 14, 2011 at 1:02 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
this seems to be speeding up the first run by 6x at the expense of
slowing down many subsequent runs by 10-15%.
If the overall throughput when measured far enough out to
On Fri, Jan 14, 2011 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 12:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Moreover this whole business of not treating hint-bit setting as
a page-dirtying operation is completely
On Fri, Jan 14, 2011 at 1:00 PM, David E. Wheeler da...@kineticode.com wrote:
On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
Something else that might be of interest: the patch as presented here
does NOT solve the deadlock problem originally presented by Joel
Jacobson. It does solve the
On Fri, 2011-01-14 at 07:30 -0500, Robert Haas wrote:
On Fri, Jan 14, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
My request is not unreasonable. Please be helpful, as you would expect
me to be if the roles were reversed.
I can't remember anyone other than you ever requesting
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
shouldn't we be getting support for the new syntax added, so
there can be a release or two supporting both?
You mean like 9.0?
Yeah, just like that.
If we're going to be supporting that long term, we
On Fri, Jan 14, 2011 at 12:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
Also, I don't really like the way this spreads knowledge of the
completionTag out all over the backend.
Excerpts from David E. Wheeler's message of vie ene 14 15:00:48 -0300 2011:
On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
Something else that might be of interest: the patch as presented here
does NOT solve the deadlock problem originally presented by Joel
Jacobson. It does solve
Excerpts from Robert Haas's message of vie ene 14 15:08:27 -0300 2011:
On Fri, Jan 14, 2011 at 1:00 PM, David E. Wheeler da...@kineticode.com
wrote:
On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
Something else that might be of interest: the patch as presented here
does NOT solve
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it reinforces my opinion that it's experimental ;-). But first
run of what, exactly?
See the test case in my OP. The runs in question are select sum(1) from
s.
And are you
Robert Haas robertmh...@gmail.com wrote:
I'm hoping some will pick it up and play with it some more (hint,
hint).
That was a bit of a pun, eh?
Anyway, there are so many ideas in this area, it's hard to keep them
all straight. Personally, if I was going to start with something,
it would
Robert Haas robertmh...@gmail.com writes:
If we're going to reject this patch on backwards-compatibility
grounds, we need to make an argument that the backward-compatibility
hazards are a real concern. So, again, has anyone complained about
the changes we made in this area in 9.0?
That 9.0
On Fri, Jan 14, 2011 at 1:34 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
I'm hoping some will pick it up and play with it some more (hint,
hint).
That was a bit of a pun, eh?
Unintentional...
Anyway, there are so many ideas in this area,
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Anyway, there are so many ideas in this area, it's hard to keep them
all straight. Personally, if I was going to start with something,
it would probably be to better establish what the impact is on
various workloads of *eliminating* hint
On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If we're going to reject this patch on backwards-compatibility
grounds, we need to make an argument that the backward-compatibility
hazards are a real concern. So, again, has anyone
On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs si...@2ndquadrant.com wrote:
This whole thing is confused. No change is appropriate here at all.
We issue ERRCODE_T_R_SERIALIZATION_FAILURE almost all of the time for
recovery conflicts.
We issue ERRCODE_ADMIN_SHUTDOWN only if the conflict is
On Fri, Jan 14, 2011 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Anyway, there are so many ideas in this area, it's hard to keep them
all straight. Personally, if I was going to start with something,
it would probably be to better
Robert Haas robertmh...@gmail.com wrote:
Background freezing plays havoc with Hot Standby
I must have missed or forgotten the issue of background vacuums
and hot standby. Can you summarize why that's worse than hitting
thresholds where autovacuum is freezing things?
this test is
Robert Haas robertmh...@gmail.com writes:
Tom - I am willing to implement this if you think it's valuable, but
I'd like your input on the syntax.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
It looks to me like the reason why there's a shift/reduce conflict is
not so much
Robert Haas robertmh...@gmail.com wrote:
Freezing sooner could be viewed as an alternative to hint bits.
Exactly. And as your test showed, things run faster frozen than
unfrozen with hint bits set.
Trouble is, it breaks Hot Standby, badly.
You're really starting to worry me here. Both
On Fri, 2011-01-14 at 13:58 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Tom - I am willing to implement this if you think it's valuable, but
I'd like your input on the syntax.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
It looks to me like the
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That 9.0 change was far less invasive than this: it only added a count
field to SELECT and CTAS result tags. Quite aside from the fact that
the tag name stayed the same, in the SELECT
On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Tom - I am willing to implement this if you think it's valuable, but
I'd like your input on the syntax.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
It looks to
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Um, yeah, I think you're having a problem keeping all the ideas straight
;-). The argument about forensics has to do with how soon we're willing
to freeze tuples, ie replace the XID
On Fri, Jan 14, 2011 at 2:01 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Trouble is, it breaks Hot Standby, badly.
You're really starting to worry me here. Both for performance and
to reduce the WAN bandwidth demands of our backup strategy we are
very aggressive with our freezing.
On lör, 2009-07-25 at 01:41 -0500, Jaime Casanova wrote:
On Fri, Jul 24, 2009 at 2:23 AM, Magnus Hagandermag...@hagander.net wrote:
1) it introduces a dependency for -lpgport when compiling a client
that uses libpq
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01511.php
On Fri, Jan 14, 2011 at 1:52 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
Background freezing plays havoc with Hot Standby
I must have missed or forgotten the issue of background vacuums
and hot standby. Can you summarize why that's worse
On Fri, Jan 14, 2011 at 2:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Um, yeah, I think you're having a problem keeping all the ideas straight
;-). The argument about forensics has to
Kevin Grittner kevin.gritt...@wicourts.gov writes:
If we're going to be supporting that long term, we should probably
change the note about FREEZE being deprecated, though.
So, still +1 on removing the wording about FREEZE being deprecated,
but instead we should mention what actually *is*
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Those things are related, though. Freezing sooner could be
viewed as an alternative to hint bits.
Freezing sooner isn't likely to reduce I/O compared to hint bits.
What that does is create I/O that you *have*
Robert Haas robertmh...@gmail.com wrote:
The critical issue is whether the tuples get frozen while they're
still invisible to some transactions on the standby server.
That's when you get query cancellations.
Oh, OK; I get that. That seems easy enough to at least mitigate to
a large degree
On Fri, Jan 14, 2011 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That 9.0 change was far less invasive than this: it only added a count
field to SELECT and CTAS result tags. Quite
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
2. Disallow the above abbreviated syntax; allow NOWAIT only after an
explicit IN ... MODE phrase. This would probably break a couple of
applications, but I bet a lot fewer than
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
So, still +1 on removing the wording about FREEZE being
deprecated, but instead we should mention what actually *is*
deprecated (the omission of the parentheses).
If we're going to do that, we should
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 2:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Freezing sooner isn't likely to reduce I/O compared to hint bits. What
that does is create I/O that you *have* to execute ... both in the pages
themselves, and in WAL.
It depends on
Le 14 janv. 2011 à 20:08, Robert Haas robertmh...@gmail.com a écrit :
On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So it looks to me like there are at least two fixes other than the ones
you enumerated:
1. Make NOWAIT a reserved word. Not good, but perhaps better
On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
In any case I'd rather break apps using LOCK foo NOWAIT than break
every application using any form of LOCK at all, which is what I think
your proposal will amount to in practice.
Can I suggest that we don't break anything at all?
On 01/14/2011 07:23 AM, Shigeru HANADA wrote:
You would be able to test these patches with 20110114 version of file_fdw
wrapper patches which will be posted in another thread.
Have you actually posted this version of file_fdw? I haven't seen it.
cheers
andrew
--
Sent via pgsql-hackers
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
In any case I'd rather break apps using LOCK foo NOWAIT than break
every application using any form of LOCK at all, which is what I think
your proposal will amount to in practice.
Can I suggest that
1 - 100 of 167 matches
Mail list logo
