Tom Lane wrote:
The idea of input functions that alter system tables scares me.
An example:
SELECT 'system_u:object_r:sepgsql_table_t:SystemHigh'::security_label;
can insert a new tuple into pg_security, but it is not a desirable behavior.
To fix this, I'll remove security_label type and
On Fri, May 30, 2008 at 10:40 AM, Tom Lane [EMAIL PROTECTED] wrote:
But since you mention it: one of the plausible answers for fixing the
vacuum problem for read-only slaves is to have the slaves push an xmin
back upstream to the master to prevent premature vacuuming. The current
design of
On Fri, May 30, 2008 at 2:41 PM, Simon Riggs [EMAIL PROTECTED] wrote:
What I still
don't accept is that an unconstrained wait is justifiable. You've just
said its a minor detail, but that's not the way I see it. It might be a
second, but it might be an hour or more.
I am suggesting a timed
Zdenek Kotala wrote:
Radek Strnad napsal(a):
snip
I'm thinking of dividing the problem into two parts - in beginning
pg_collation will contain two functions. One will have hard-coded rules
for these basic collations (SQL_CHARACTER, GRAPHIC_IRV, LATIN1, ISO8BIT,
UCS_BASIC). It will compare
On Fri, May 30, 2008 at 1:56 AM, Simon Riggs [EMAIL PROTECTED] wrote:
Been thinking some more about this. You're right that the second scan
could re-dirty many pages and is probably something to avoid.
Right. IMHO it would help us a lot.
The main
issue I see is that you don't really know
On Thu, May 29, 2008 at 01:58:34PM -0700, David Fetter wrote:
If people on core had come to the idea that we needed to build in
replication *before* 8.3 came out, they certainly didn't announce it.
Now is a great time to mention this because it gives everybody time to:
1. Come to a
On 5/30/08, Gurjeet Singh [EMAIL PROTECTED] wrote:
On Fri, May 30, 2008 at 10:40 AM, Tom Lane [EMAIL PROTECTED] wrote:
But since you mention it: one of the plausible answers for fixing the
vacuum problem for read-only slaves is to have the slaves push an xmin
back upstream to the master to
I think it is good idea make a function returning set of records,
like xpath_table, but accepting xml data in a text paramiter.
Today if you have a function with a xml parameter, you have to save it in
a table to use xpath.
Thanks,
On Fri, May 30, 2008 at 3:31 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Perhaps we can start first scan, check xid after we scan each few
blocks. Once we find the xid is older, then we know the size of the
second scan can be limited to only those blocks already scanned. So the
two endpoints of
Kevin Grittner wrote:
On Wed, May 28, 2008 at 6:26 PM, in message
[EMAIL PROTECTED],
Florian G. Pflug [EMAIL PROTECTED] wrote:
I think we should put some randomness into the decision,
to spread the IO caused by hit-bit updates after a batch load.
Currently we have a policy of doing a
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-05-30 at 12:31 +0530, Gurjeet Singh wrote:
On Fri, May 30, 2008 at 10:40 AM, Tom Lane [EMAIL PROTECTED] wrote:
But since you mention it: one of the plausible answers for fixing the
vacuum problem for read-only
[EMAIL PROTECTED] writes:
I think it is good idea make a function returning set of records,
like xpath_table, but accepting xml data in a text paramiter.
Today if you have a function with a xml parameter, you have to save it in
a table to use xpath.
I believe you're mistaken. Why
On Thu, 2008-05-29 at 19:18 -0500, Decibel! wrote:
Is there a reason that we can't add a trigger to a table while a
select is running? This is a serious pain when trying to setup
londiste or slony.
This is constrained by locking.
There are a subset of DDL commands that might be able to
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-05-30 at 12:31 +0530, Gurjeet Singh wrote:
On Fri, May 30, 2008 at 10:40 AM, Tom Lane [EMAIL PROTECTED] wrote:
But since you mention it: one of the plausible answers for fixing the
vacuum problem for read-only slaves is to have the slaves push
Hi Tom,
Thanks for the reasoned reply. As you saw from point #2 in my comments, I
think you should do this feature. I hope this answers Josh Berkus' concern
about my comments.
You make a very interesting comment which seems to go to the heart of this
design approach:
About the only thing
On Fri, May 30, 2008 at 9:31 AM, Marko Kreen [EMAIL PROTECTED] wrote:
On 5/30/08, Gurjeet Singh [EMAIL PROTECTED] wrote:
I think it would be best to not make the slave interfere with the master's
operations; that's only going to increase the operational complexity of such
a solution.
I
On Fri, 2008-05-30 at 11:30 -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-05-30 at 12:31 +0530, Gurjeet Singh wrote:
On Fri, May 30, 2008 at 10:40 AM, Tom Lane [EMAIL PROTECTED] wrote:
But since you mention it: one
On Fri, 2008-05-30 at 12:31 +0530, Gurjeet Singh wrote:
On Fri, May 30, 2008 at 10:40 AM, Tom Lane [EMAIL PROTECTED] wrote:
But since you mention it: one of the plausible answers for
fixing the
vacuum problem for read-only slaves is to have the slaves push
an
On Thu, 29 May 2008 09:22:26 -0700 Steve Atkins wrote:
On May 29, 2008, at 9:12 AM, David Fetter wrote:
Either one of these would be great, but something that involves
machines that stay useless most of the time is just not going to work.
I have customers who are thinking about warm
On Thu, 29 May 2008 18:29:01 -0400 Tom Lane wrote:
Dimitri Fontaine [EMAIL PROTECTED] writes:
While at it, would it be possible for the simple part of the core
team statement to include automatic failover?
No, I think it would be a useless expenditure of energy. Failover
includes a
Hi Marko,
Replication requirements vary widely of course, but DDL support is shared by
such a wide range of use cases it is very difficult to see how any real
solution would fail to include it. This extends to change extraction APIs,
however, defined. The question of what DDL to replicate is
On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote:
Well, yes, but you do know about archive_timeout, right? No need to wait
2 hours.
Then you ship 16 MB binary stuff every 30 second or every minute but
you only have some kbyte real data in the logfile. This must be taken
into account,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I don't think so. This is a particular case. So my advice is to hack
test_config_settings() and add your custom values to trial_conns[] and
trial_bufs[].
Thanks. I dropped those to their bare minimums (1 and 16), and still did
not have
On Fri, 30 May 2008, Andreas 'ads' Scherbaum wrote:
Then you ship 16 MB binary stuff every 30 second or every minute but
you only have some kbyte real data in the logfile.
Not if you use pg_clearxlogtail (
http://www.2ndquadrant.com/replication.htm ), which got lost in the giant
March
On Thu, May 29, 2008 at 7:42 PM, Tom Lane [EMAIL PROTECTED] wrote:
The big problem
is that long-running slave-side queries might still need tuples that are
vacuumable on the master, and so replication of vacuuming actions would
cause the slave's queries to deliver wrong answers.
Another
On Fri, 2008-05-30 at 11:12 -0700, Robert Hodges wrote:
This is clearly an important use case but it also seems clear that
the WAL approach is not a general-purpose approach to replication.
I think we cannot make such a statement yet, if ever.
I would note that log-based replication is now
Howdy,
I just saw this in the docs:
Finally, NATURAL is a shorthand form of USING: it forms a USING list
consisting of exactly those column names that appear in both input
tables. As with USING, these columns appear only once in the output
table.
That sounds useful if I happen to have
On Thursday 29 May 2008 22:59:21 Merlin Moncure wrote:
On Thu, May 29, 2008 at 9:26 PM, Josh Berkus [EMAIL PROTECTED] wrote:
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the
Andreas 'ads' Scherbaum wrote:
On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote:
Well, yes, but you do know about archive_timeout, right? No need to wait
2 hours.
Then you ship 16 MB binary stuff every 30 second or every minute but
you only have some kbyte real data in the
On Thursday 29 May 2008 20:31:31 Greg Smith wrote:
On Thu, 29 May 2008, Tom Lane wrote:
There's no point in having read-only slave queries if you don't have a
trustworthy method of getting the data to them.
This is a key statement that highlights the difference in how you're
thinking about
On Friday 30 May 2008 01:10:20 Tom Lane wrote:
Greg Smith [EMAIL PROTECTED] writes:
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two.
Well,
I'm trying to cleanup header dependences and it seems hash_any and hash_uint32
function is candidate to move into separate c file in backend/utils/misc
directory. It significantly reduce amount of unnecessary includes from files
like network.c ( http://doxygen.postgresql.org/network_8c.html)
On Fri, 2008-05-30 at 13:19 -0700, David E. Wheeler wrote:
Howdy,
I just saw this in the docs:
Finally, NATURAL is a shorthand form of USING: it forms a USING list
consisting of exactly those column names that appear in both input
tables. As with USING, these columns appear only
Howdy,
I just saw this in the docs:
Finally, NATURAL is a shorthand form of USING: it forms a USING list
consisting of exactly those column names that appear in both input
tables. As with USING, these columns appear only once in the output
table.
That sounds useful if I happen to have
On Sat, May 31, 2008 at 1:52 AM, Greg Smith [EMAIL PROTECTED] wrote:
On Fri, 30 May 2008, Andreas 'ads' Scherbaum wrote:
Then you ship 16 MB binary stuff every 30 second or every minute but
you only have some kbyte real data in the logfile.
Not if you use pg_clearxlogtail (
Andreas 'ads' Scherbaum wrote:
On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote:
Well, yes, but you do know about archive_timeout, right? No need to wait
2 hours.
Then you ship 16 MB binary stuff every 30 second or every minute but
you only have some kbyte real
Magnus and I had the fortune to share a plane flight when leaving pgCon.
This gave us a chance to discuss my ideas around reforming PostgreSQL
configuration at some length. Here's what we came up with (Magnus will
presumably correct the parts I got wrong):
Currently, PostgreSQL,conf and our
On Sat, 2008-05-31 at 02:48 +0530, Gurjeet Singh wrote:
Not if you use pg_clearxlogtail
( http://www.2ndquadrant.com/replication.htm ), which got lost
in the giant March commitfest queue but should probably wander
into contrib as part of 8.4.
On Sat, 31 May 2008, Gurjeet Singh wrote:
Not if you use pg_clearxlogtail
This means we need to modify pg_standby to not check for filesize when
reading XLogs.
No, the idea is that you run the segments through pg_clearxlogtail | gzip,
which then compresses lightly used segments massively
On Fri, 2008-05-30 at 01:10 -0400, Tom Lane wrote:
Greg Smith [EMAIL PROTECTED] writes:
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two.
On Fri, 2008-05-30 at 14:50 +0530, Pavan Deolasee wrote:
On Fri, May 30, 2008 at 2:41 PM, Simon Riggs [EMAIL PROTECTED] wrote:
What I still
don't accept is that an unconstrained wait is justifiable. You've just
said its a minor detail, but that's not the way I see it. It might be a
Le vendredi 30 mai 2008, Tom Lane a écrit :
No, I think it would be a useless expenditure of energy. Failover
includes a lot of things that are not within our purview: switching
IP addresses to point to the new server, some kind of STONITH solution
to keep the original master from coming back
On Fri, 30 May 2008 16:22:41 -0400 (EDT) Greg Smith wrote:
On Fri, 30 May 2008, Andreas 'ads' Scherbaum wrote:
Then you ship 16 MB binary stuff every 30 second or every minute but
you only have some kbyte real data in the logfile.
Not if you use pg_clearxlogtail (
Zdenek Kotala wrote:
I'm trying to cleanup header dependences and it seems hash_any and
hash_uint32 function is candidate to move into separate c file in
backend/utils/misc directory. It significantly reduce amount of
unnecessary includes from files like network.c (
On Thu, 2008-05-29 at 10:12 -0400, Tom Lane wrote:
The Postgres core team met at PGCon to discuss a few issues, the largest
of which is the need for simple, built-in replication for PostgreSQL.
Historically the project policy has been to avoid putting replication
into core PostgreSQL, so as to
On Thu, 2008-05-29 at 09:57 +0530, Pavan Deolasee wrote:
On Thu, May 29, 2008 at 2:02 AM, Simon Riggs [EMAIL PROTECTED] wrote:
I'm not happy that the VACUUM waits. It might wait a very long time and
cause worse overall performance than the impact of the second scan.
Lets not get too
Andrew,
Sure there's a price to pay. But that doesn't mean the facility doesn't
exist. And I rather suspect that most of Josh's customers aren't too
concerned about traffic charges or affected by such bandwidth
restrictions. Certainly, none of my clients are, and they aren't in the
giant
On Fri, 2008-05-30 at 14:22 +0530, Pavan Deolasee wrote:
For large tables, two heap scans along with several additional page
writes doesn't seem to the cost we can afford, especially in IO-bound
application. IMHO a timed wait is not such a bad thing. Note that its
all about VACUUM which is a
On Wed, 2008-05-28 at 21:47 -0400, Mike wrote:
On Wed, May 28, 2008 at 8:30 PM, Mike [EMAIL PROTECTED] wrote:
When you say a bit of decoding, is that because the data written to the
logs
is after the query parser/planner? Or because it's written in several
chunks? Or?
Because that's
[Looks like this mail missed the hackers list on reply to all, I wonder
how it could happen... so I forward it]
On Thu, 2008-05-29 at 17:00 +0100, Dave Page wrote:
Yes, we're talking real-time streaming (synchronous) log shipping.
Is there any design already how would this be implemented ?
On Fri, 30 May 2008 17:05:57 -0400 Andrew Dunstan wrote:
Andreas 'ads' Scherbaum wrote:
On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote:
Well, yes, but you do know about archive_timeout, right? No need to wait
2 hours.
Then you ship 16 MB binary stuff every 30 second or every
Tatsuo Ishii wrote:
Andreas 'ads' Scherbaum wrote:
On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote:
Well, yes, but you do know about archive_timeout, right? No need to wait
2 hours.
Then you ship 16 MB binary stuff every 30 second or every minute but
a fur cap on his head. The sledge drove round the square twice, and Kay tied on
On Sat, May 31, 2008 at 3:41 AM, Greg Smith [EMAIL PROTECTED] wrote:
On Sat, 31 May 2008, Gurjeet Singh wrote:
Not if you use pg_clearxlogtail
This means we need to modify pg_standby to not check for filesize when
reading XLogs.
No, the idea is that you run the segments through
On Fri, 30 May 2008, Josh Berkus wrote:
1) Add several pieces of extra information to guc.c in the form of extra
gettext commands: default value, subcategory, long description,
recommendations, enum lists.
2) Incorporate this data into pg_settings
When you last brought this up in February
55 matches
Mail list logo
