Hi hackers,
The project I'm currently working with fsnapshot[1], is written in
plain plpgsql and I need to sort all the oids in their
creatable/droppable order.
This has already been properly implemented in pg_dump_sort.c using
Knuth's algorithm for topological sorting, with some special magic to
Robert Haas robertmh...@gmail.com writes:
Committed.
Thanks!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
David E. Wheeler da...@kineticode.com writes:
Just so long as you're aware that you might get more challenges on this going
forward.
Sure, thanks for the reminder. That said I also remember the reaction
when I used to scan the SHARE/contrib directory to find the extension
control file having
Long time ago, I propose regclass like function which does not throw
an error if the table is not found. Instead I want to let it return
InvalidOid or NULL.
Tatsuo Ishii is...@postgresql.org writes:
Is there any way to use regclass without having ERROR?
pgpool-II needs to find the oid from
On Tue, Jan 4, 2011 at 04:49, Andrew Dunstan and...@dunslane.net wrote:
On 01/03/2011 12:15 PM, I wrote:
The following patch allows me to build the 8.3 and 8.4 branches using
Visual Studio 2008, once the build system is patched. But I don't really
know why. HEAD and 9.0 build fine without
Heikki Linnakangas wrote:
You can of course LOCK TABLE as a work-around, if that's what you want.
What I was trying to suggest upthread is that while there are other
possible ways around this problem, the only one that has any hope of
shipping with 9.1 is to do just that. So from my
On 28.12.2010 22:44, Joel Jacobson wrote:
Sent from my iPhone
On 28 dec 2010, at 21:45, Gurjeet Singh singh.gurj...@gmail.com
mailto:singh.gurj...@gmail.com wrote:
The problem I see with suffixing a sequence id to the objects with
name collision is that one day the dump may name
On 28.12.2010 23:51, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 12/28/2010 04:44 PM, Joel Jacobson wrote:
Perhaps abbreviations are to prefer, e.g., myfunc_i, myfunc_i_c, etc
to reduce the need of truncating filenames.
I think that's just horrible. Does the i stand for
On 28.12.2010 17:00, Joel Jacobson wrote:
Dear fellow hackers,
Problem: A normal diff of two slightly different schema dump files
(pg_dump -s), will not produce a user-friendly diff, as you get all
changes in the same file.
Another Solution: I have used a python script for spliiting dump -s
Robert Haas wrote:
And even if it isn't, the MERGE syntax is insane if what you really
want to do is insert or update ONE record. If all we have is MERGE,
people will keep doing it with a PL/pgsql stored procedure or some
crummy application logic just so that they don't have to spend several
* Robert Haas wrote:
On Mon, Jan 3, 2011 at 8:11 AM, Christian Ullrichch...@chrullrich.net wrote:
this patch adds support for connecting to servers running on Windows
and requesting SSPI authentication. It does this by treating
AUTH_REQ_SSPI the same as AUTH_REQ_GSS if no native SSPI
Hi,
Please find attached the patch to support ALTER EXTENSION UPGRADE,
following exchanges made on this list — we can't really speak about
decisions here, apparently, until commit is done :)
The documentation is available online for easy browsing here:
On 04.01.2011 11:07, Tatsuo Ishii wrote:
Datum
pgpool_regclass(PG_FUNCTION_ARGS)
{
char*pro_name_or_oid = PG_GETARG_CSTRING(0);
Oid result;
PG_TRY();
{
result = DirectFunctionCall1(regclassin,
t...@fuzzy.cz wrote:
- I really am not sure about the changes made in pg_proc.h. I'm not sure
how to assign OIDs to the new functions (I've simply chosen values that
are were not used in this file), and I'm not sure about the other columns
(I've copied and modified another function with the same
It's not generally safe to suppress errors like that. You could leak
locks or tuple descriptors etc. And if the error is not no scuh
table, but e.g. out of memory, you don't want to suppress it anyway.
Thanks. I will create more invasive patch.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English:
Tomas Vondra wrote:
OK, so here goes the simplified patch - it tracks one reset timestamp
for a background writer and for each database.
Adding timestamps like this was something I wanted to do after adding
pg_stat_reset_shared to 9.0, so since you've beaten me to it I'll review
your
Joel Jacobson wrote:
To understand a change to my database functions, I would start by
looking at the top-level, only focusing on the names of the functions
modified/added/removed.
At this stage, you want as little information as possible about each
change, such as only the names of the
On Mon, Jan 03, 2011 at 10:23:03PM -0500, Robert Haas wrote:
Can you add this to the currently-open CommitFest, so we don't lose track of
it?
https://commitfest.postgresql.org/action/commitfest_view/open
Done.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
2011/1/4 Jeff Davis pg...@j-davis.com:
I have been updating my work in progress here:
http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes
Right now, it's not in a reviewable state, but those interested can
glance through the code.
Quick synopsis (for
Hello
I looked on patch
does work toast_raw_datum_size on packed varlena corectly?
regards
Pavel Stehule
2011/1/4 Noah Misch n...@leadboat.com:
On Mon, Jan 03, 2011 at 10:23:03PM -0500, Robert Haas wrote:
Can you add this to the currently-open CommitFest, so we don't lose track of
it?
* Jeff Davis:
4. For the GiST penalty function, and perhaps some picksplit algorithms,
it might be nice to know the length of a range, or do some other kinds
of math. It introduces a lot of complexity to try to define math
functions for each subtype, and try to make sure they behave sanely.
Hi Pavel,
On Tue, Jan 04, 2011 at 03:13:11PM +0100, Pavel Stehule wrote:
I looked on patch
Thanks.
does work toast_raw_datum_size on packed varlena corectly?
Yes, as best I can tell.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 01/04/2011 04:43 AM, Magnus Hagander wrote:
OK, what's going here is that, in the newer SDK, IPV6_V6ONLY is defined
unconditionally, but IPPROTO_IPV6 is only defined if _WIN32_WINNT is set to
0x0501 or higher. We defined _WIN32_WINNT as 0x0500 until 9.0, when we
changed it specifically to
Tatsuo Ishii is...@postgresql.org writes:
It's not generally safe to suppress errors like that. You could leak
locks or tuple descriptors etc. And if the error is not no scuh
table, but e.g. out of memory, you don't want to suppress it anyway.
Thanks. I will create more invasive patch.
Why
On Fri, 2010-12-31 at 11:11 +1300, Mark Kirkwood wrote:
I note that this uninitialized pages with standbys has cropped up from
time to time - I wonder if in most/all the cases folk were using
Pitrtools?
I deployed Pitrtools a lot when I was working for CMD, and I haven't
seen any issues with
Why is any of this necessary? It sure looks like you are solving a
problem at the wrong level.
Please read upthread.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list
Tatsuo Ishii is...@postgresql.org writes:
Why is any of this necessary? It sure looks like you are solving a
problem at the wrong level.
Please read upthread.
You haven't made any argument why this shouldn't be solvable at the
client side, or at worst with a plpgsql DO block; either of which
On Tue, Jan 04, 2011 at 04:44:32AM -0500, Greg Smith wrote:
Heikki Linnakangas wrote:
You can of course LOCK TABLE as a work-around, if that's what you want.
Presuming the code quality issues and other little quirks I've
documented (and new ones yet to be discovered) can get resolved
here,
Jeff Davis pg...@j-davis.com writes:
2. We need to use the subtype's IO functions, but those may not be
immutable. So, rather than create new IO functions for each range type,
I was thinking that I'd use just three (anyrange_i_in, anyrange_s_in,
and anyrange_v_in), and select the right one at
Joel Jacobson j...@gluefinance.com writes:
It's not possible to use a plain recursive query to do the trick (due
to 'i' bidirectional dependencies and dependency loops).
Well I came up with that while working on some extension related fun
dependency problems, I guess it could help you:
On Tue, Jan 04, 2011 at 09:29:55AM +0100, Joel Jacobson wrote:
Hi hackers,
The project I'm currently working with fsnapshot[1], is written in
plain plpgsql and I need to sort all the oids in their
creatable/droppable order. This has already been properly
implemented in pg_dump_sort.c using
On Tue, Jan 04, 2011 at 12:31:55PM +0100, Dimitri Fontaine wrote:
Hi,
Please find attached the patch to support ALTER EXTENSION UPGRADE,
Do you plan to have
ALTER EXTENSION ... UPGRADE TO VERSION ...
, or the more general,
ALTER EXTENSION ... ALTER VERSION TO ... ?
I get that this might
On 2011-01-04 6:27 PM, David Fetter wrote:
On Tue, Jan 04, 2011 at 04:44:32AM -0500, Greg Smith wrote:
Heikki Linnakangas wrote:
You can of course LOCK TABLE as a work-around, if that's what you want.
Presuming the code quality issues and other little quirks I've
documented (and new ones yet
On Tue, Jan 04, 2011 at 07:02:54PM +0200, Marko Tiikkaja wrote:
On 2011-01-04 6:27 PM, David Fetter wrote:
On Tue, Jan 04, 2011 at 04:44:32AM -0500, Greg Smith wrote:
Heikki Linnakangas wrote:
You can of course LOCK TABLE as a work-around, if that's what you want.
Presuming the code quality
On Tue, Jan 4, 2011 at 2:29 AM, Jeff Davis pg...@j-davis.com wrote:
I liked Robert's suggestion here:
http://archives.postgresql.org/message-id/aanlktiks_x93_k82b4f_ga634wci0oeb9ftrurf28...@mail.gmail.com
which says that the user can just define a canonicalize function that
will take a range
On Jan 4, 2011, at 12:46 AM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
Just so long as you're aware that you might get more challenges on this
going forward.
Sure, thanks for the reminder. That said I also remember the reaction
when I used to scan the
On Tue, 2011-01-04 at 15:51 +0900, Itagaki Takahiro wrote:
On Tue, Dec 28, 2010 at 22:17, Magnus Hagander mag...@hagander.net wrote:
We definitely need the very basic level for 9.1, and we can always
improve on it later :-)
pg_stat_walsender. It would then only need the columns for
On Sun, Dec 19, 2010 at 6:14 AM, Martijn van Oosterhout
klep...@svana.org wrote:
On Sat, Dec 18, 2010 at 11:59:33PM -0800, Jeff Janes wrote:
On Sat, Dec 18, 2010 at 10:11 PM, flyusa2010 fly flyusa2...@gmail.com
wrote:
hi, folks!
I see that shared cache is implemented by system v shared
On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote:
It doesn't allow for all of the suggested features. In particular, it
would not allow granules to be specified for discrete ranges. But on
balance, it seems like this is the most conceptually simple and I think
it satisfies the primary
On Tue, 2011-01-04 at 14:18 +, Florian Weimer wrote:
* Jeff Davis:
4. For the GiST penalty function, and perhaps some picksplit algorithms,
it might be nice to know the length of a range, or do some other kinds
of math. It introduces a lot of complexity to try to define math
All,
This is a pointless argument.
Eventually, we will be implementing all possible sync rep
configurations, because different users *need* different configurations.
Some users care more about durability, some more about availability,
and some more about response time. And you can't have all
On 1/2/11 12:35 AM, Heikki Linnakangas wrote:
Very likely. A synchronous standby can bring the master to a halt, while
an asynchronous one is rather harmless. If I were a DBA, and the data
wasn't very sensitive, I would liberally hand out async privileges to my
colleagues to set up reporting
On Tue, Jan 4, 2011 at 12:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
The sent pointer is needed whether or not we have sync rep. We should
also include application name, since the user may set that in the
standby for all the same reasons it is set elsewhere.
Small point: please lets not
Eh... I may be showing my status as a non-normal human, but I know
exactly what pg_stat_walsender is (it's the view that shows you the
status of the WAL senders you've allowed by configuring
max_wal_senders0) but I have no idea what pg_stat_replication_sent
and pg_stat_replication_received
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
2011/1/4 Jeff Davis pg...@j-davis.com:
I have been updating my work in progress here:
http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes
Right now, it's not in a reviewable state, but those
On Tue, 2011-01-04 at 10:28 -0800, Josh Berkus wrote:
The relevant question is: which configuration(s) can we have ready for
the next CommitFest and alpha release?
Based upon that series of conversations, I've reworked the design so
that there is (currently) only a single standby offering sync
On Sun, Jan 2, 2011 at 4:19 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2011-01-02 at 18:54 +0200, Heikki Linnakangas wrote:
I believe we all agree that there's different use cases that require
different setups. Both first-past-the-post and wait-for-all-to-ack
have their uses.
I'm not feeling well now, so I'm going to go to bed, not just to avoid
snapping at people. Even given that short interlude, I see no problem
about delivery.
Cool! Thanks Simon. Feel better.
Joshua D. Drake
--
PostgreSQL.org Major Contributor
Command Prompt, Inc:
On Tue, 2011-01-04 at 10:50 -0800, Josh Berkus wrote:
Eh... I may be showing my status as a non-normal human, but I know
exactly what pg_stat_walsender is (it's the view that shows you the
status of the WAL senders you've allowed by configuring
max_wal_senders0) but I have no idea what
hmmm I think pg_stat_standby might be more relevant but I definitely
agree something more newbie appropriate is in order.
I'd be fine with that name, too.
--
-- Josh Berkus
PostgreSQL Experts Inc.
On Tue, Jan 4, 2011 at 20:28, Josh Berkus j...@agliodbs.com wrote:
hmmm I think pg_stat_standby might be more relevant but I definitely
agree something more newbie appropriate is in order.
I'd be fine with that name, too.
That seems kind of backwards though - given that the view only
David Fetter da...@fetter.org writes:
Do you plan to have
ALTER EXTENSION ... UPGRADE TO VERSION ...
, or the more general,
ALTER EXTENSION ... ALTER VERSION TO ... ?
Well why not, but I'm not sure I understand what you have in mind here.
I don't exactly see how to install more than one
On Tue, Jan 4, 2011 at 2:31 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Jan 4, 2011 at 20:28, Josh Berkus j...@agliodbs.com wrote:
hmmm I think pg_stat_standby might be more relevant but I definitely
agree something more newbie appropriate is in order.
I'd be fine with that name,
David E. Wheeler da...@kineticode.com writes:
As Tom pointed out, you can do the same with naming conventions by having
scripts \i each other as appropriate.
This is a deprecated idea, though. We're talking about the
pg_execute_from_file() patch that has been applied, but without the
On 01/04/2011 07:51 PM, Simon Riggs wrote:
On Tue, 2011-01-04 at 10:28 -0800, Josh Berkus wrote:
The relevant question is: which configuration(s) can we have ready for
the next CommitFest and alpha release?
Based upon that series of conversations, I've reworked the design so
that there is
On Tue, Jan 4, 2011 at 1:18 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote:
It doesn't allow for all of the suggested features. In particular, it
would not allow granules to be specified for discrete ranges. But on
balance, it seems like this is
On Jan 4, 2011, at 11:48 AM, Dimitri Fontaine wrote:
As Tom pointed out, you can do the same with naming conventions by having
scripts \i each other as appropriate.
This is a deprecated idea, though. We're talking about the
pg_execute_from_file() patch that has been applied, but without
On Tue, Jan 4, 2011 at 2:50 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
On 01/04/2011 07:51 PM, Simon Riggs wrote:
On Tue, 2011-01-04 at 10:28 -0800, Josh Berkus wrote:
The relevant question is: which configuration(s) can we have ready for
the next CommitFest and alpha release?
On 04.01.2011 21:43, Robert Haas wrote:
On Tue, Jan 4, 2011 at 2:31 PM, Magnus Hagandermag...@hagander.net wrote:
On Tue, Jan 4, 2011 at 20:28, Josh Berkusj...@agliodbs.com wrote:
hmmm I think pg_stat_standby might be more relevant but I definitely
agree something more newbie appropriate
On Tue, Jan 04, 2011 at 10:50:12AM -0800, Josh Berkus wrote:
Eh... I may be showing my status as a non-normal human, but I know
exactly what pg_stat_walsender is (it's the view that shows you the
status of the WAL senders you've allowed by configuring
max_wal_senders0) but I have no idea
David E. Wheeler da...@kineticode.com writes:
* Prefer convention over configuration
The previous idea about the convention is not flying well with the very
recent proposal of ALTER EXTENSION ... UPGRADE TO VERSION ..., because
it would certainly require that the extension's name include its
On 02.11.2010 07:15, Fujii Masao wrote:
On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yeah, that's one approach. Another is to validate the TLI in the xlog page
header, it should always match the current timeline we're on. That would
feel more
On Jan 4, 2011, at 12:05 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
* Prefer convention over configuration
The previous idea about the convention is not flying well with the very
recent proposal of ALTER EXTENSION ... UPGRADE TO VERSION ..., because
it would
I've been thinking about how to fix GIN's assorted corner-case problems,
as has been discussed several times, most recently here:
http://archives.postgresql.org/pgsql-hackers/2010-10/msg00521.php
See also
http://wiki.postgresql.org/wiki/Todo#GIN
There are basically three related issues:
1. GIN
On Tue, Jan 4, 2011 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Existing GIN indexes are upwards compatible so far as on-disk storage
goes, but they will of course be missing entries for empty, null, or
null-containing items. Users who want to do searches that should find
such items will
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 4, 2011 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Existing GIN indexes are upwards compatible so far as on-disk storage
goes, but they will of course be missing entries for empty, null, or
null-containing items. Users who want to do
On 05/01/11 04:43, Devrim GÜNDÜZ wrote:
On Fri, 2010-12-31 at 11:11 +1300, Mark Kirkwood wrote:
I note that this uninitialized pages with standbys has cropped up from
time to time - I wonder if in most/all the cases folk were using
Pitrtools?
I deployed Pitrtools a lot when I was working for
Josh Berkus j...@postgresql.org writes:
So, again, I don't agree that a separate synchrep permission is useful,
or warranted.
+1
However, your arguments *do* make me backpedal on the issue of having a
list of synch rep roles on the master. I can easily imagine a DBA
needing to rapidly
What about the HBA here?
Hmmm. That's tempting; an synchronous HBA instead of a GUC? But that
doesn't solve the problem of standby #6 is failing, I want to kick it
off synch rep.
I'd be opposed to having a GUC *and* an HBA. making DBAs set things
independantly in two places just frustrates
Josh Berkus j...@postgresql.org writes:
What about the HBA here?
Hmmm. That's tempting; an synchronous HBA instead of a GUC? But that
doesn't solve the problem of standby #6 is failing, I want to kick it
off synch rep.
I'd be opposed to having a GUC *and* an HBA. making DBAs set things
On Tue, Jan 04, 2011 at 09:51:05AM -0800, Jeff Janes wrote:
Correct. The kernel ignores locking requests because it's a great way
to DOS a machine. For example, mlock() of large blocks of memory is
also not permitted for similar reasons.
Does it ignore such requests in general, or only
On Tue, Jan 4, 2011 at 4:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 4, 2011 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Existing GIN indexes are upwards compatible so far as on-disk storage
goes, but they will of course be missing
On 1/4/11 1:49 PM, Tom Lane wrote:
I don't think it's really worth the trouble. The GIN code has been
broken for these types of queries since day one, and yet we've had only
maybe half a dozen complaints about it. Moreover there's no practical
way to avoid trying to use the index, since in
I was just thinking that you could prepend a reject line at the right
place in the file.
Hmmm, that's worth thinking about. How do others feel about this?
--
-- Josh Berkus
PostgreSQL Experts Inc.
On Tue, Jan 04, 2011 at 08:31:19PM +0100, Dimitri Fontaine wrote:
David Fetter da...@fetter.org writes:
Do you plan to have
ALTER EXTENSION ... UPGRADE TO VERSION ...
, or the more general,
ALTER EXTENSION ... ALTER VERSION TO ... ?
Well why not, but I'm not sure I understand
On 1/4/11 10:18 AM, Jeff Davis wrote:
The main drawback here is that only a select group of people will be
defining discrete range types at all, because it would require them to
define a function first. Perhaps that's for the best, because, (as Tom
pointed out) we don't want someone using
On Wed, Jan 5, 2011 at 04:56, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I think pg_stat_replication is better than pg_stat_standby, but I'm
still not convinced we shouldn't go with the obvious
pg_stat_walsenders.
How about pg_stat_replication_activity? If I understood
On Tue, Jan 4, 2011 at 2:52 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Tue, Jan 04, 2011 at 09:51:05AM -0800, Jeff Janes wrote:
Correct. The kernel ignores locking requests because it's a great way
to DOS a machine. For example, mlock() of large blocks of memory is
also not
Simon Riggs wrote:
Based upon that series of conversations, I've reworked the design so
that there is (currently) only a single standby offering sync rep at any
one time. Other standbys can request to be sync standbys but they only
become the sync standby if the first one fails. Which was simple
Kevin Grittner wrote:
Greg Smith wrote:
I could see shipping this with the automatic heavy LOCK TABLE in
there.
How would you handle or document behavior in REPEATABLE READ
isolation? The lock doesn't do much good unless you acquire it
before you get your snapshot, right?
David Fetter wrote:
How about implementing an UPSERT command as take the lock, do the
merge? That way, we'd have both the simplicity for the simpler cases
and a way to relax consistency guarantees for those who would like to
do so.
Main argument against is that path leads to a permanent
Somebody asked about this on Depesz's blog today, and I think it's
come up here before too, so I thought it might be worth my writing up
a few comments on this. I don't think I'm going to have time to work
on this any time soon, but if someone else wants to work up a patch,
I'm game to review. I
On Sat, Jan 1, 2011 at 11:54 PM, Robert Haas robertmh...@gmail.com wrote:
Hanada-san, can you rebase the fdw_scan patch over what I committed
and post an updated version ASAP? It'd be better for Heikki or Tom to
work on that part of this than me, since they have a better
understanding of the
On Mon, Jan 3, 2011 at 5:50 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 3, 2011 at 17:23, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On the other hand, the REPLICATION
On Tue, Jan 4, 2011 at 7:41 PM, Robert Haas robertmh...@gmail.com wrote:
Somebody asked about this on Depesz's blog today, and I think it's
come up here before too, so I thought it might be worth my writing up
a few comments on this. I don't think I'm going to have time to work
on this any
On Tue, 4 Jan 2011 22:16:26 -0500
Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 1, 2011 at 11:54 PM, Robert Haas robertmh...@gmail.com wrote:
Hanada-san, can you rebase the fdw_scan patch over what I committed
and post an updated version ASAP? It'd be better for Heikki or Tom to
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
A couple thoughts:
1. Could the making a table logged be a non-exclusive lock if the
ALTER is allowed to take a full checkpoint?
If possible, that would certainly be better. If the bgwriter is
On Sat, 1 Jan 2011 23:54:05 -0500
Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 27, 2010 at 10:16 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas robertmh...@gmail.com wrote:
I'm working on getting a first chunk of this committed.
OK,
On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote:
On 1/4/11 10:18 AM, Jeff Davis wrote:
The main drawback here is that only a select group of people will be
defining discrete range types at all, because it would require them to
define a function first. Perhaps that's for the best,
Josh Berkus wrote:
I've been trying to diagnose in a production database why certain tables
never get autovacuumed despite having a substantial % of updates. The
obvious reason is locks blocking autovacuum from vacuuming the table ...
Missed this dicussion when it popped up but have plenty
On Tue, Jan 04, 2011 at 09:27:10PM -0500, Greg Smith wrote:
David Fetter wrote:
How about implementing an UPSERT command as take the lock, do the
merge? That way, we'd have both the simplicity for the simpler cases
and a way to relax consistency guarantees for those who would like to
do so.
91 matches
Mail list logo
