Re: [HACKERS] Streaming Replication on win32
Joe Conway wrote: > OK, so now I see why we want this fixed for dblink and walreceiver, but > doesn't this approach leave every other WIN32 libpq client out in the > cold? Is there nothing that can be done for the general case, or is it a > SMOP? The problem only applies to libpq calls from the backend. Client apps are not affected, only backend modules. If there's any other modules out there that use libpq, then yes, those have a problem too. A generic fix would be nice. Putting the wrapper functions in a new header file that's included in all backend modules that want to use libpq would work. Maybe the new header file could even be #included from libpq-fe.h, when compiling backend code (#ifndef FRONTEND), so you wouldn't need to modify dblink, walreceiver, or any 3rd party modules that use libpq at all. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] quoting psql varible as identifier
2010/1/22 Robert Haas : > On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule > wrote: >> 2010/1/21 Robert Haas : >>> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule >>> wrote: add to state structure field like lexer_error. This field will be checked before execution it could be ugly for metacommands, there will be lot of new checks :( >>> >>> Eh? The only places where we should need new tests are the places >>> that check PQExpBufferBroken() now - there are only 6 calls to that >>> function in src/bin/psql and not all of them need to be changed. The >>> places that do need to be changed will need to be modified to check >>> PQExpBufferBroken() || lexer_coughed_up_a_lung. >> >> no, it is only 6 calls because we don't check psql_scan_slash_option result. > > psql_scan_slash_option() already has a way to signal errors - it can > return NULL. Type any backslash command followed by a single quote... NULL means "no value". But I thing, so there is only one important - \set. For other can be enough some error message and empty value. > > I'm not saying I love the way those errors are handled, but if we make > this patch about revising the way psql does error handling, this is > not going to get committed for this release... what we need to do is > fit what we're trying to do into the existing model. > I try to find some simple and I'll send a patch. Pavel > ...Robert > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming Replication on win32
On 01/21/2010 10:33 PM, Heikki Linnakangas wrote: > Joe Conway wrote: >> I have not been really following this thread, but why can't we put the >> "#ifdef WIN32" and special definition of these functions into libpq. I >> don't understand why we need special treatment for dblink. > > The problem is that select() function on Windows isn't interrupted by > signals. That's because Unix-style signals don't exist on Windows, but > we've emulated them in the server with pipes. The select() function > doesn't know about that hack, so in the backend, we've replaced it with > pgwin32_select() that does, using a #define. Ah, thanks for the synopsis. > libpq doesn't use that #define and pgwin32_select(), because that's a > backend function. It won't work in regular client applications. > > If we just moved those dblink_PQexec/PQconnectdb() functions to libpq, > they wouldn't use pgwin32_select() and would thus be useless. OK, so now I see why we want this fixed for dblink and walreceiver, but doesn't this approach leave every other WIN32 libpq client out in the cold? Is there nothing that can be done for the general case, or is it a SMOP? Joe signature.asc Description: OpenPGP digital signature
Re: [HACKERS] Streaming Replication on win32
Joe Conway wrote: > +#ifdef WIN23 > ^ > I assume you meant WIN32 here ;-) Yeah. I admit I haven't tested this on Windows, I just commented out those #ifdef's and tested on Linux. Will need to verify that this actually solves the problem on Windows before committing. > +#define PQexec(conn, command) dblink_PQexec(conn, command) > +#define PQconnectdb(conninfo) dblink_PQconnectdb(conninfo) > > I have not been really following this thread, but why can't we put the > "#ifdef WIN32" and special definition of these functions into libpq. I > don't understand why we need special treatment for dblink. The problem is that select() function on Windows isn't interrupted by signals. That's because Unix-style signals don't exist on Windows, but we've emulated them in the server with pipes. The select() function doesn't know about that hack, so in the backend, we've replaced it with pgwin32_select() that does, using a #define. libpq doesn't use that #define and pgwin32_select(), because that's a backend function. It won't work in regular client applications. If we just moved those dblink_PQexec/PQconnectdb() functions to libpq, they wouldn't use pgwin32_select() and would thus be useless. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Largeobject Access Controls (r2460)
The attached patch is a revised version.
List of updates:
- cleanup: getBlobs() was renamed to getBlobOwners()
- cleanup: BlobsInfo was renamed to BlobOwnerInfo
- bugfix: pg_get_userbyid() in SQLs were replaced by username_subquery which
constins a right subquery to obtain a username for the given id.
It enables to run pg_dump under the concurrent role deletion.
- bugfix: Even if we give -a (--data-only) or -O (--no-owner) options,
or archive does not contain Owner information, it tried to write
out "ALTER LARGE OBJECT xxx OWNER TO ..." statement.
- bugfix: Even if we give -a (--data-only) or -x (--no-privileges) options,
it tried to write out "BLOB ACLS" section.
The last two are the problems I noticed newly. It needs to introduce them.
The BLOB section can contain multiple definitions of large objects, unlike
any other object classes. It is also a reason why I had to group large
objects by database user.
The Owner tag of BLOB section is used to identify owner of the large objects
to be restored, and also used in --use-set-session-authorization mode.
However, we need to inject "ALTER LARGE OBJECT xxx OWNER TO ..." statement
for each lo_create() in _LoadBlobs(), because we cannot know how many large
objects are in the section before reading the archive.
But the last patch didn't pay mention about -a/-O option and an archive
which does not have Owner: tag.
The BLOB ACLS section is categorized to SECTION_DATA, it follows the manner
in BLOB COMMENTS behavior. In same reason, it has to handle the -a/-x option
by itself, but the last patch didn't handle it well.
BTW, here is a known issue. When we run pg_dump with -s(--schema-only),
it write out descriptions of regular object classes, but does not write
out the description of large objects.
It seems to me the description of large objects are considered as a part
of data, not properties. However, it might be inconsistent.
The reason of this behavior is all the BLOB dumps are categorized to
SECTION_DATA, so -s option informs pg_backup_archiver.c to skip routines
related to large objects.
However, it may be a time to consider this code into two steps.
In the schema section stage,
- It creates empty large objects with lo_create()
- It restores the description of the large objects.
- It restores the ownership/privileges of the large objects.
In the date section stage,
- It loads actual data contents into the empty large objects with lowrite().
Thanks,
(2010/01/21 19:42), Takahiro Itagaki wrote:
>
> KaiGai Kohei wrote:
>
>>> I'm not sure whether we need to make groups for each owner of large objects.
>>> If I remember right, the primary issue was separating routines for dump
>>> BLOB ACLS from routines for BLOB COMMENTS, right? Why did you make the
>>> change?
>>
>> When --use-set-session-authorization is specified, pg_restore tries to
>> change database role of the current session just before creation of
>> database objects to be restored.
>>
>> Ownership of the database objects are recorded in the section header,
>> and it informs pg_restore who should be owner of the objects to be
>> restored in this section.
>>
>> Then, pg_restore can generate ALTER xxx OWNER TO after creation, or
>> SET SESSION AUTHORIZATION before creation in runtime.
>> So, we cannot put creation of largeobjects with different ownership
>> in same section.
>>
>> It is the reason why we have to group largeobjects by database user.
>
> Ah, I see.
>
> Then... What happen if we drop or rename roles who have large objects
> during pg_dump? Does the patch still work? It uses pg_get_userbyid().
>
> Regards,
> ---
> Takahiro Itagaki
> NTT Open Source Software Center
>
>
>
--
OSS Platform Development Division, NEC
KaiGai Kohei
*** a/src/bin/pg_dump/pg_backup_archiver.c
--- b/src/bin/pg_dump/pg_backup_archiver.c
***
*** 517,527 restore_toc_entry(ArchiveHandle *AH, TocEntry *te,
*/
if (AH->PrintTocDataPtr !=NULL && (reqs & REQ_DATA) != 0)
{
- _printTocEntry(AH, te, ropt, true, false);
-
if (strcmp(te->desc, "BLOBS") == 0 ||
! strcmp(te->desc, "BLOB COMMENTS") == 0)
{
ahlog(AH, 1, "restoring %s\n", te->desc);
_selectOutputSchema(AH, "pg_catalog");
--- 517,535
*/
if (AH->PrintTocDataPtr !=NULL && (reqs & REQ_DATA) != 0)
{
if (strcmp(te->desc, "BLOBS") == 0 ||
! strcmp(te->desc, "BLOB COMMENTS") == 0 ||
! strcmp(te->desc, "BLOB ACLS") == 0)
{
+ /*
+ * We don't need to dump ACLs, if -a or -x cases.
+ */
+ if (strcmp(te->desc, "BLOB ACLS") == 0 &&
+ (ropt->aclsSkip || ropt->dataOnly))
+ return retval;
+
+ _printTocEntry(AH, te, ropt, true, false);
+
ahlog(AH, 1, "restoring %s\n", te->desc);
_selectOutputSchema(AH, "pg_catalog");
***
*** 530,535 restore_toc_entry(ArchiveHandle *AH, TocEntry *te,
--- 538,545
}
else
{
+ _
Re: [HACKERS] quoting psql varible as identifier
On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule wrote: > 2010/1/21 Robert Haas : >> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule >> wrote: >>> add to state structure field like lexer_error. This field will be >>> checked before execution >>> it could be ugly for metacommands, there will be lot of new checks :( >> >> Eh? The only places where we should need new tests are the places >> that check PQExpBufferBroken() now - there are only 6 calls to that >> function in src/bin/psql and not all of them need to be changed. The >> places that do need to be changed will need to be modified to check >> PQExpBufferBroken() || lexer_coughed_up_a_lung. > > no, it is only 6 calls because we don't check psql_scan_slash_option result. psql_scan_slash_option() already has a way to signal errors - it can return NULL. Type any backslash command followed by a single quote... I'm not saying I love the way those errors are handled, but if we make this patch about revising the way psql does error handling, this is not going to get committed for this release... what we need to do is fit what we're trying to do into the existing model. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] warn in plperl logs as... NOTICE??
On Jan 21, 2010, at 4:55 PM, Andrew Dunstan wrote: > *shrug* I don't have a strong opinion about it, and it's pretty easy to > change, if there's a consensus we should. I have certainly found over the > years that perl warnings from some modules can be annoyingly verbose, which > is probably why the original patch didn't make them have a higher level in > Postgres. If this were a big issue we'd have surely heard about it before now > - there are plenty of plperl users out there. Using elog(WARNING) certainly makes a lot more sense to me… David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git out of sync vs. CVS
"Kevin Grittner" writes: > Tom Lane wrote: >> "Kevin Grittner" writes: >>> So add me to the list of people who think that if >>> these are going to be recurring, we should look at moving from >>> cvs to git as soon as 9.0 is released. >> >> The gating factor is not release schedule; it is the still- >> unaddressed tasks that must be done before we can consider moving. >> http://wiki.postgresql.org/wiki/Switching_PostgreSQL_from_CVS_to_Git > If you think people can work on that list without risk of delaying > the release, OK. I was assuming that such work would be too > disruptive to work on at this point in a release cycle, and might > possibly pull time from folks who would otherwise be working on the > release. Do you disagree? Oh, if you meant that people should start dealing with those tasks after release, that's fine with me. I read your comment to be that we should schedule the move for immediately after release, prerequisites or no. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: commit fests (was Re: [HACKERS] primary key error message)
Tom Lane wrote: > Now your original posts back in December were okay, since you were > just letting people know that you intended to work on this over a > long period. But IIRC you've made more than one post with actual > code in it that you seemed to be hoping people would review, and > that I thought was a distraction at this late stage of the cycle. Well, I've gotten to the first three milestones and have posted a patch for each. The first two were before the start of the CF, but I intentionally *didn't* add them to the CF and specifically asked people *not* to let them divert efforts from the release, which has apparently been respected. It wasn't a disingenuous request. Robert, in particular, said before the CF that he would look at the first patch when I had it ready, and has apparently not done so yet because of other priorities, which is as I would wish. I hit the third milestone after the start of the CF and posted it "for the record". If people find that distracting, I'll hold off until I get some indication that it won't be. I think it's a bit unfair to single me out because of that one post, but I think I can handle it. :-) I just want to make sure I'm not missing some gaff I didn't realize I was making. Given how small a portion of each year is actually officially open for feedback, I'd hate to think that posting a couple WIP patches during that narrow window was considered a breach of protocol. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL
On Jan 21, 2010, at 4:02 PM, Eric B. Ridge wrote: > On Jan 21, 2010, at 12:35 PM, David E. Wheeler wrote: > >> And where do you think baby powder comes from? Sheesh. > > You won the thread! Heh, who's the wise guy that posted the second comment on http://www.betanews.com/article/EU-clears-Oracle-Sun-If-MySQL-fails-theres-always-PostgreSQL/1264109388 ? -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Partitioning syntax
Robert Haas wrote: > people get bogged down and don't have time to finish the work. Ok, I moved this patch to the next commit fest for 9.1 alpha 1. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming Replication on win32
On 01/21/2010 04:46 AM, Heikki Linnakangas wrote: > Heikki Linnakangas wrote: >> Magnus Hagander wrote: >>> 2010/1/17 Heikki Linnakangas : We could replace the blocking PQexec() calls with PQsendQuery(), and use the emulated version of select() to wait. >>> Hmm. That would at least theoretically work, but aren't there still >>> places we may end up blocking further down? Or are those ok? >> >> There's also PQconnect that needs similar treatment (using >> PQconnectStart/Poll()), but that's it. > > So here's a patch implementing that for contrib/dblink. Walreceiver > needs the same treatment. > > The implementation should be shared between the two, but I'm not sure > how. We can't just put the wrapper functions to a module in > src/backend/port/, because the wrapper functions depend on libpq. Maybe > put them in a new header file as static functions, and include that in > contrib/dblink/dblink.c and src/backend/replication/libpqwalreceiver.c. +#ifdef WIN23 ^ I assume you meant WIN32 here ;-) +#define PQexec(conn, command) dblink_PQexec(conn, command) +#define PQconnectdb(conninfo) dblink_PQconnectdb(conninfo) I have not been really following this thread, but why can't we put the "#ifdef WIN32" and special definition of these functions into libpq. I don't understand why we need special treatment for dblink. Joe signature.asc Description: OpenPGP digital signature
Re: [HACKERS] Fix for memory leak in dblink
On 01/11/2010 07:43 PM, Takahiro Itagaki wrote: > There is a memory leak in dblink when we cancel a query during > returning tuples. It could leak a PGresult because memory used > by it is not palloc'ed one. I wrote a patch[1] before, but I've > badly used global variables to track the resource. > > The attached is a cleaned up patch rewritten to use a tuplestore > (SFRM_Materialize mode) to return tuples suggested at [2]. Since > we don't return from the dblink function in tuplestore mode, we > can surely release the PGresult with a PG_CATCH block even on error. > > Also, dblink_record_internal() and dblink_fetch() are rearranged > to share the same code to return tuples for code refactoring. > > [1] http://archives.postgresql.org/pgsql-hackers/2009-06/msg01358.php > [2] http://archives.postgresql.org/pgsql-hackers/2009-10/msg00292.php This looks good to me. I'll commit in the next 24 hours if there are no objections. Thanks, Joe signature.asc Description: OpenPGP digital signature
Re: [HACKERS] warn in plperl logs as... NOTICE??
Tom Lane wrote: Andrew Dunstan writes: Jim Nasby wrote: Why does warn; in plperl log as NOTICE in Postgres? Where would you like the warning to go? This has been this way for nearly 5 years, it's not new (and before that the warning didn't go anywhere). I think he's suggesting that it ought to translate as elog(WARNING) not elog(NOTICE). *shrug* I don't have a strong opinion about it, and it's pretty easy to change, if there's a consensus we should. I have certainly found over the years that perl warnings from some modules can be annoyingly verbose, which is probably why the original patch didn't make them have a higher level in Postgres. If this were a big issue we'd have surely heard about it before now - there are plenty of plperl users out there. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: commit fests (was Re: [HACKERS] primary key error message)
On Thu, Jan 21, 2010 at 5:35 PM, Peter Eisentraut wrote: > On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote: >> But let me ask this. For which >> release were you hoping to make this change? If 9.0, then it seems to >> me that you've missed the deadline, which - according to my >> understanding of the agreed-upon schedule - was six days ago. > > By that logic, the next release must be called 8.5, because the deadline > for proposing changes was six days ago. Well, I was assuming we were talking about feature freeze rather than "no one can ever commit anything", or we'd never get to a release, which is the point of this exercise AIUI. >> Or perhaps you feel that that deadline should only apply to >> non-committers? If so, we should be clear about that, because I have >> a few things which I would have liked to submit but was unable to get >> done before the start of the CommmitFest. I would be more than happy >> to finish them up and propose them now, but my understanding is that >> I'm not supposed to do that. > > My understanding is that the commit fest process is an offer or perhaps > even a promise to patch submitters that their stuff will be attended to > within 2 or 3 months, instead of the 10 months or infinity that might > have been the previous average. And in order to make that "attending" > happen, the development participants are encouraged to focus on > reviewing the submitted patches. Right. I agree. > But I don't think that should mean everyone has to drop everything when > the clock strikes midnight and must now only look at things that the > magic commitfest page has pre-approved. Nobody does that anyway. It I don't believe that something being on the CommitFest page implies any sort of approval. It just expresses the desire of the submitter for it to be reviewed. > just means what you submit now does not get the same "promise" of > attention. Of course if you start proposing new significant features > now then it might be obvious that the discussion and review process > cannot possibly be concluded by the time the release is scheduled, so > you might as well not bother. But if things have been discussed before > or are simple enough and you just didn't get the thing done in time, why > not finish it up. I don't think anyone could accuse you of neglecting > the CF, as you are known to do your share. So I personally encourage > you to try to finish what you have started. If no one wants to review > it and you don't want to take responsibility yourself, well then. And Well, that does seem to be endorsing a sort of two-tiered system. If I submit a patch and nobody looks at it, I can decide that silence means approval and commit it. If someone who is not a committer does the same thing, it dies, no matter how technically excellent it is. I am no longer in a position to be bothered by that, but I think if I were not a committer I might be. I wonder what others think about this. There's another issue, too. If a committer submits a patch, everybody else who cares about the issue has to drop what they're doing and look at it. Because if they don't, there's a good chance that in 24 hours plus or minus, it'll be in the tree. Several patches have blown by me in the last month or two - already committed before I got around to reading them, and I might have had an opinion on them, but it's too late to do anything about it now. I mean, it's not, really: I could still ask for something to be changed, but it's an uphill battle at this point. > if someone proposes something that might be as simple as the MySQL > compatibility thing, assuming a consensus, why not include it, instead > of bumping it to 2012-Next for the sake of the process. I agree to a certain extent, but if you are concerned about our release cycle being too long, as indicated by your use of the name 2012-Next, proposing a whole series of changes for changes during the last CommitFest may not be the best way to get there. Maybe they're small enough that it doesn't matter much, but I still think it would have been easier to deal with two weeks ago when we had a lot less going on. Anyway, I just work here. It's certainly not the end of the world... and there are certainly other things which are going to delay the release by a lot more than this will. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
Tom Lane wrote: > What I do think is that the quoted code snippet has no business being > outside the planner proper. It'd be better to put it in planner.c > or someplace like that. Ah, I see. My concern was the dummy planner approach is using internal functions of planner. It would be better if planner module exports a cost estimate function for cluster. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
"Larry Rosenman" writes: > On Thu, January 21, 2010 5:53 pm, Andreas Joseph Krogh wrote: >> Care to shed some light on what features (yes, we users care about >> features) warrant this major version-bump? Is there a link somewhere? > AFAIR, it was stated if Hot Standby AND Streaming Replication hit the > tree, the release number would go to 9.0. Yeah. The question of "when do we call it 9.0" has come up multiple times over the past few release cycles, and "when we get built-in replication" has always been one of the more popular answers. If HS+SR aren't enough to justify a major version bump, I'm not sure what would be. The other bit of rationale for this is that HS+SR are likely to induce a certain amount of, um, instability. Labeling the release with a dot-oh version number will help to set people's expectations about that. For comparison's sake, one of the main reasons for calling 8.0 8.0 was the native Windows port, and it certainly took a while for that to settle down. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] warn in plperl logs as... NOTICE??
Andrew Dunstan writes: > Jim Nasby wrote: >> Why does warn; in plperl log as NOTICE in Postgres? > Where would you like the warning to go? This has been this way for > nearly 5 years, it's not new (and before that the warning didn't go > anywhere). I think he's suggesting that it ought to translate as elog(WARNING) not elog(NOTICE). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: commit fests (was Re: [HACKERS] primary key error message)
On Thu, Jan 21, 2010 at 7:11 PM, Tom Lane wrote: > "Kevin Grittner" writes: >> Tom Lane wrote: >>> If you want an example of something I *do* have a process problem >>> with, it's Kevin Grittner's attempts > >> Hmmm Plural? I've made exactly one post on the subject since >> the CF started, unless you count review of Markus's dtester code, >> which he posted before the CF but didn't add to the CF page. Is >> reviewing that a process violation? Or was discussing it before the >> CF the process issue? > > I thought the whole topic should have been held off till after the CF, > probably till after the bulk of beta testing work is done. It's a > sufficiently large and difficult problem that nobody can really give you > any meaningful feedback without taking more time away from our current > set of problems than I think is appropriate. > > Now your original posts back in December were okay, since you were just > letting people know that you intended to work on this over a long > period. But IIRC you've made more than one post with actual code in it > that you seemed to be hoping people would review, and that I thought > was a distraction at this late stage of the cycle. I actually thought that was a good thing to do, versus developing totally out of site, though I admit I have had zero time to read the code, and probably won't for a while. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: commit fests (was Re: [HACKERS] primary key error message)
"Kevin Grittner" writes: > Tom Lane wrote: >> If you want an example of something I *do* have a process problem >> with, it's Kevin Grittner's attempts > Hmmm Plural? I've made exactly one post on the subject since > the CF started, unless you count review of Markus's dtester code, > which he posted before the CF but didn't add to the CF page. Is > reviewing that a process violation? Or was discussing it before the > CF the process issue? I thought the whole topic should have been held off till after the CF, probably till after the bulk of beta testing work is done. It's a sufficiently large and difficult problem that nobody can really give you any meaningful feedback without taking more time away from our current set of problems than I think is appropriate. Now your original posts back in December were okay, since you were just letting people know that you intended to work on this over a long period. But IIRC you've made more than one post with actual code in it that you seemed to be hoping people would review, and that I thought was a distraction at this late stage of the cycle. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
On Thu, January 21, 2010 5:53 pm, Andreas Joseph Krogh wrote: > On Thursday 21. January 2010 10.37.41 Dave Page wrote: >> In an attempt to pre-empt the normally drawn-out discussions about >> what the next version of PostgreSQL will be numbered. the core team >> have discussed the issue and following a lenghty debate lasting >> literally a few minutes decided that the next release shall be >> >> Wait for it >> >> 9.0. > > Care to shed some light on what features (yes, we users care about > features) warrant this major version-bump? Is there a link somewhere? AFAIR, it was stated if Hot Standby AND Streaming Replication hit the tree, the release number would go to 9.0. Both are in the tree. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Largeobject Access Controls (r2460)
(2010/01/21 19:42), Takahiro Itagaki wrote: > > KaiGai Kohei wrote: > >>> I'm not sure whether we need to make groups for each owner of large objects. >>> If I remember right, the primary issue was separating routines for dump >>> BLOB ACLS from routines for BLOB COMMENTS, right? Why did you make the >>> change? >> >> When --use-set-session-authorization is specified, pg_restore tries to >> change database role of the current session just before creation of >> database objects to be restored. >> >> Ownership of the database objects are recorded in the section header, >> and it informs pg_restore who should be owner of the objects to be >> restored in this section. >> >> Then, pg_restore can generate ALTER xxx OWNER TO after creation, or >> SET SESSION AUTHORIZATION before creation in runtime. >> So, we cannot put creation of largeobjects with different ownership >> in same section. >> >> It is the reason why we have to group largeobjects by database user. > > Ah, I see. > > Then... What happen if we drop or rename roles who have large objects > during pg_dump? Does the patch still work? It uses pg_get_userbyid(). Indeed, pg_get_userbyid() internally uses SnapshotNow always, then it can return "unknown (OID=%u)" in this case. The "username_subquery" should be here, instead. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
On Thursday 21. January 2010 10.37.41 Dave Page wrote: > In an attempt to pre-empt the normally drawn-out discussions about > what the next version of PostgreSQL will be numbered. the core team > have discussed the issue and following a lenghty debate lasting > literally a few minutes decided that the next release shall be > > Wait for it > > 9.0. Care to shed some light on what features (yes, we users care about features) warrant this major version-bump? Is there a link somewhere? -- Andreas Joseph Krogh Senior Software Developer / CTO +-+ OfficeNet AS| The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment.| | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] warn in plperl logs as... NOTICE??
Jim Nasby wrote: Why does warn; in plperl log as NOTICE in Postgres? On a related note, what's the logic behind perl DEBUG logging as DEBUG2 instead of DEBUG1 or DEBUG5? Still seems kind of odd, but at least nowhere near as surprising as warn becoming NOTICE... Where would you like the warning to go? This has been this way for nearly 5 years, it's not new (and before that the warning didn't go anywhere). cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: commit fests (was Re: [HACKERS] primary key error message)
Tom Lane wrote: > If you want an example of something I *do* have a process problem > with, it's Kevin Grittner's attempts Hmmm Plural? I've made exactly one post on the subject since the CF started, unless you count review of Markus's dtester code, which he posted before the CF but didn't add to the CF page. Is reviewing that a process violation? Or was discussing it before the CF the process issue? After looking at my emails, I'm honestly confused. If it was the milestone patch, and your plural was a slip, I'll hold off on further such posts. If it's something else, I want to understand what. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
One other point about this, before anyone asks: we will of course have to go through the source code and docs to s/8.5/9.0/. The plan is to do that between the conclusion of the current commitfest and the release of the final alpha version (which will therefore call itself 9.0alpha4 not 8.5alpha4). This delay is to avoid creating needless merge problems for as-yet-unapplied patches. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: commit fests (was Re: [HACKERS] primary key error message)
Tom Lane wrote: > If you want an example of something I *do* have a process problem > with, it's Kevin Grittner's attempts to get people to put a > significant number of cycles into thinking about true > serializability. > Right now is not the time for that to be happening. I've been > politely ignoring that thread, but ... Not my motive, but if you think that'll be the effect of posting milestone patches, I'll hold 'em back. Apologies if I caused a disruption. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: commit fests (was Re: [HACKERS] primary key error message)
Andrew Dunstan writes: > Peter Eisentraut wrote: >> But I don't think that should mean everyone has to drop everything when >> the clock strikes midnight and must now only look at things that the >> magic commitfest page has pre-approved. > Well, we used to have the idea of a feature freeze ... is that going to > apply at the end of the commitfest? Even a feature freeze would not IMO prevent considering the sort of small adjustment Peter was suggesting. We will doubtless be making far larger adjustments than that even quite late in the release cycle. (Particularly in the new HS/SR code.) I thought his patch wasn't a particularly good idea, but I didn't have a problem with it from a schedule or process standpoint. If you want an example of something I *do* have a process problem with, it's Kevin Grittner's attempts to get people to put a significant number of cycles into thinking about true serializability. Right now is not the time for that to be happening. I've been politely ignoring that thread, but ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
On Fri, Jan 22, 2010 at 12:29 AM, Andrew Chernow wrote: > >>> 9.0. >>> >> >> You don't have a code-name. All the cool kids have code-names for their >> projects. >> >> > Black Dog > > yup, I'm a zeppelin fan :) > +1 :) -- Regards, Michael Paquier NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Re: commit fests (was Re: [HACKERS] primary key error message)
On Jan 21, 2010, at 3:05 PM, Andrew Dunstan wrote: > Well, we used to have the idea of a feature freeze ... is that going to apply > at the end of the commitfest? > > I generally agree that we need to have a bit of wiggle room at this stage - > small and non-controversial items can be allowed to creep in still. Seems to me we can have discussion anytime, though a given patch might get more or less discussion at various times. But clearly something like this would just be entered for the first 9.1 commitfest, no? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] warn in plperl logs as... NOTICE??
Why does warn; in plperl log as NOTICE in Postgres? On a related note, what's the logic behind perl DEBUG logging as DEBUG2 instead of DEBUG1 or DEBUG5? Still seems kind of odd, but at least nowhere near as surprising as warn becoming NOTICE... -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: commit fests (was Re: [HACKERS] primary key error message)
Peter Eisentraut wrote: But I don't think that should mean everyone has to drop everything when the clock strikes midnight and must now only look at things that the magic commitfest page has pre-approved. Well, we used to have the idea of a feature freeze ... is that going to apply at the end of the commitfest? I generally agree that we need to have a bit of wiggle room at this stage - small and non-controversial items can be allowed to creep in still. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
commit fests (was Re: [HACKERS] primary key error message)
On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote: > But let me ask this. For which > release were you hoping to make this change? If 9.0, then it seems to > me that you've missed the deadline, which - according to my > understanding of the agreed-upon schedule - was six days ago. By that logic, the next release must be called 8.5, because the deadline for proposing changes was six days ago. > Or perhaps you feel that that deadline should only apply to > non-committers? If so, we should be clear about that, because I have > a few things which I would have liked to submit but was unable to get > done before the start of the CommmitFest. I would be more than happy > to finish them up and propose them now, but my understanding is that > I'm not supposed to do that. My understanding is that the commit fest process is an offer or perhaps even a promise to patch submitters that their stuff will be attended to within 2 or 3 months, instead of the 10 months or infinity that might have been the previous average. And in order to make that "attending" happen, the development participants are encouraged to focus on reviewing the submitted patches. But I don't think that should mean everyone has to drop everything when the clock strikes midnight and must now only look at things that the magic commitfest page has pre-approved. Nobody does that anyway. It just means what you submit now does not get the same "promise" of attention. Of course if you start proposing new significant features now then it might be obvious that the discussion and review process cannot possibly be concluded by the time the release is scheduled, so you might as well not bother. But if things have been discussed before or are simple enough and you just didn't get the thing done in time, why not finish it up. I don't think anyone could accuse you of neglecting the CF, as you are known to do your share. So I personally encourage you to try to finish what you have started. If no one wants to review it and you don't want to take responsibility yourself, well then. And if someone proposes something that might be as simple as the MySQL compatibility thing, assuming a consensus, why not include it, instead of bumping it to 2012-Next for the sake of the process. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL
On Jan 21, 2010, at 12:35 PM, David E. Wheeler wrote: > And where do you think baby powder comes from? Sheesh. You won the thread! eric -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming replication, retrying from archive
Dimitri Fontaine wrote: Heikki Linnakangas writes: Yeah, a lot of that logic and states is completely unnecessary until we have a synchronous mode. Even then, it seems complex. I hope we'll find something less complex, what I proposed is heavily inspired from londiste (Skytools) table addition to a replication set (parallel COPY), which works fine. Here's what I've been hacking: [...] So there's just two states: 1. Recovering from archive 2. Streaming We start from 1, and switch state at error. Oh yes that's even more simple! This gives nice behavior from a user point of view. Standby tries to make progress using either the archive or streaming, whichever becomes available first. So tools like pitrtools or walmgr.py will certainly continue being necessary to use in 9.0, right? Right now Streaming Replication does not do your backup for you, which some of the tools (e.g walmgr.py) do... Thinking about walmgr.py for a moment - it should be pretty easy (or possible anyway) to make it use streaming replication for server versions >= 9.0. Cheers Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming replication, retrying from archive
Heikki Linnakangas writes: > Yeah, a lot of that logic and states is completely unnecessary until we > have a synchronous mode. Even then, it seems complex. I hope we'll find something less complex, what I proposed is heavily inspired from londiste (Skytools) table addition to a replication set (parallel COPY), which works fine. > Here's what I've been hacking: [...] > So there's just two states: > > 1. Recovering from archive > 2. Streaming > > We start from 1, and switch state at error. Oh yes that's even more simple! > This gives nice behavior from a user point of view. Standby tries to > make progress using either the archive or streaming, whichever becomes > available first. So tools like pitrtools or walmgr.py will certainly continue being necessary to use in 9.0, right? -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] primary key error message
On Thu, Jan 21, 2010 at 4:24 PM, Peter Eisentraut wrote: >> Why bother? > > Because unique constraints and primary keys are different things and it > would be slightly less confusing that way. I don't really see why it would be any less confusing. You could argue that someone might not know that the primary key acts like a unique constraint, but if they don't, then they might be confused about what it means to violate it. Generally if the user is looking at something like \d they will see the primary key as well as any unique indices. And the name of the primary key will match the name from this error message. So I'm also not sure how someone could get pointed in the wrong direction in the first place. >> And why bother now, when we're in the middle of the last >> CommitFest and trying to move toward a release? > > Are you saying we can't discuss anything new during the commit fest? Of course, I have no control over what anyone discusses. This is a community and no one has a boss. But let me ask this. For which release were you hoping to make this change? If 9.0, then it seems to me that you've missed the deadline, which - according to my understanding of the agreed-upon schedule - was six days ago. Or perhaps you feel that that deadline should only apply to non-committers? If so, we should be clear about that, because I have a few things which I would have liked to submit but was unable to get done before the start of the CommmitFest. I would be more than happy to finish them up and propose them now, but my understanding is that I'm not supposed to do that. On the other hand, if you were hoping to make this change for 9.1, then obviously there is no issue of a deadline. However, there is still the issue of the CommitFest mandate, of which you are a proponent, which, in your exact words, says that one should not "work on new patches" during CommitFest and beta. http://archives.postgresql.org/pgsql-hackers/2009-06/msg01514.php I have previously expressed the view you might have been overreaching a bit in that email, because I don't think it's realistic to say that there is useful work for everyone to do during the entire time that we are in beta, and if there is nothing someone can do to get the release out sooner, then I think it's fine for them to work on their own patches. But that certainly isn't the case right now. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] primary key error message
On tor, 2010-01-21 at 16:29 -0500, Tom Lane wrote: > regression=# alter table foo add primary key (f1); > NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "foo_pkey" > for table "foo" > ERROR: could not create unique index "foo_pkey" > DETAIL: Key (f1)=(1) is duplicated. He he, that one doesn't even refer to a "constraint". Might also need fixing. ;-) > It is not incorrect to refer to a primary key as a unique constraint. Some things need a primary key that is not only a unique constraint. So having some clarity about that can be helpful. > Will you next be wanting the error messages about null values to > distinguish whether the NOT NULL constraint came from a primary key? Hadn't thought of that, but it could actually become relevant when we get named not null constraints. But anyway, if there is no interest in this, then forget about it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PITR backup history files with identical 2nd part file names
Rafael Martinez writes: > Tom Lane wrote: >> I think this is normal behavior now, if you have an unloaded server. >> pg_start_backup now forces a segment switch, so if nothing much else is >> happening it's quite likely that the recorded start point will be the >> beginning of the WAL segment (plus the page header size). > The strange thing is that a lot is happening. These clusters generate > several hundred WAL files a day. Well, by "loaded server" I meant "something sufficient busy to generate another WAL record in the extremely narrow time window between when pg_start_backup advances the WAL pointer and when it copies the WAL pointer". It might even be that those two things happen within a single acquisition of WALInsertLock and thus there isn't any window at all --- I didn't dig into the code closely enough to be sure about that. > I trust what you say on the subject :-) is only that in all the > years we have been using PITR, we have never seen identical values in > the 2nd part of the backup history file name (not one) Well, it was a pretty recent change that made pg_start_backup force a segment switch. Before that you'd have seen values ranging throughout the size of a WAL segment. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PITR backup history files with identical 2nd part file names
Tom Lane wrote: > Rafael Martinez writes: > >> All PITR backup history files created when running a PITR base backup on >> all PostgreSQL clusters running in this new server (at different hours >> during the night) got an identical 2nd part file name. > >> <24 digits>.0020.backup e.g.000202080060.0020.backup > > I think this is normal behavior now, if you have an unloaded server. > pg_start_backup now forces a segment switch, so if nothing much else is > happening it's quite likely that the recorded start point will be the > beginning of the WAL segment (plus the page header size). > The strange thing is that a lot is happening. These clusters generate several hundred WAL files a day. How is possible to get the same value *everytime* we run a base backup with many WAL files generated between runs and on different clusters? I trust what you say on the subject :-) is only that in all the years we have been using PITR, we have never seen identical values in the 2nd part of the backup history file name (not one) -- Rafael Martinez, Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] primary key error message
Peter Eisentraut writes: > On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote: >> This patch fails to cover all cases (index build being the obvious >> omission, but I think there might be other paths as well where the >> information is not so readily available). > This is the user-visible error message, and that's the only place it's > generated. Hardly ... regression=# create table foo (f1 int); CREATE TABLE regression=# insert into foo values(1),(1); INSERT 0 2 regression=# alter table foo add primary key (f1); NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "foo_pkey" for table "foo" ERROR: could not create unique index "foo_pkey" DETAIL: Key (f1)=(1) is duplicated. >> And I agree with Robert that the usefulness is at best highly debatable. > The usefulness is that they are different kinds of objects that are > defined and listed in different ways and it would be slightly helpful if > the error message pointed in the righter direction. It is not incorrect to refer to a primary key as a unique constraint. Will you next be wanting the error messages about null values to distinguish whether the NOT NULL constraint came from a primary key? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] primary key error message
On tor, 2010-01-21 at 15:47 -0500, Robert Haas wrote: > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote: > > Here is a small patch that changes the error message > > > >duplicate key value violates unique constraint "%s" > > > > into > > > >duplicate key value violates primary key "%s" > > > > when the constraint is in fact a primary key. > > > > Comments? > > Why bother? Because unique constraints and primary keys are different things and it would be slightly less confusing that way. > And why bother now, when we're in the middle of the last > CommitFest and trying to move toward a release? Are you saying we can't discuss anything new during the commit fest? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] primary key error message
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote: > Robert Haas writes: > > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote: > >> Here is a small patch that changes the error message > >> > >> duplicate key value violates unique constraint "%s" > >> > >> into > >> > >> duplicate key value violates primary key "%s" > >> > >> when the constraint is in fact a primary key. > >> > >> Comments? > > > Why bother? And why bother now, when we're in the middle of the last > > CommitFest and trying to move toward a release? > > This patch fails to cover all cases (index build being the obvious > omission, but I think there might be other paths as well where the > information is not so readily available). This is the user-visible error message, and that's the only place it's generated. > And I agree with Robert that the usefulness is at best highly debatable. The usefulness is that they are different kinds of objects that are defined and listed in different ways and it would be slightly helpful if the error message pointed in the righter direction. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PITR backup history files with identical 2nd part file names
Rafael Martinez writes: > After upgrading to 8.3.9 and moving some our PostgreSQL clusters to a > new server yesterday, we have experienced a strange thing this past night. > All PITR backup history files created when running a PITR base backup on > all PostgreSQL clusters running in this new server (at different hours > during the night) got an identical 2nd part file name. > <24 digits>.0020.backup e.g.000202080060.0020.backup I think this is normal behavior now, if you have an unloaded server. pg_start_backup now forces a segment switch, so if nothing much else is happening it's quite likely that the recorded start point will be the beginning of the WAL segment (plus the page header size). > Is it normal to get the same 2nd part of the file name all the time? How > is this value generated? It's just the current offset within the current WAL segment. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] primary key error message
Robert Haas writes: > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote: >> Here is a small patch that changes the error message >> >> duplicate key value violates unique constraint "%s" >> >> into >> >> duplicate key value violates primary key "%s" >> >> when the constraint is in fact a primary key. >> >> Comments? > Why bother? And why bother now, when we're in the middle of the last > CommitFest and trying to move toward a release? This patch fails to cover all cases (index build being the obvious omission, but I think there might be other paths as well where the information is not so readily available). And I agree with Robert that the usefulness is at best highly debatable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] primary key error message
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote: > Here is a small patch that changes the error message > > duplicate key value violates unique constraint "%s" > > into > > duplicate key value violates primary key "%s" > > when the constraint is in fact a primary key. > > Comments? Why bother? And why bother now, when we're in the middle of the last CommitFest and trying to move toward a release? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
On Thu, 2010-01-21 at 21:26 +0100, Stefan Kaltenbrunner wrote: > > http://www.postgresql.org/docs/current/static/release-6-5.html That was another great release IMHO. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
[HACKERS] primary key error message
Here is a small patch that changes the error message
duplicate key value violates unique constraint "%s"
into
duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
PS: Yes, this would need a handful of regression test updates if
accepted.
Index: src/backend/access/nbtree/nbtinsert.c
===
RCS file: /cvsroot/pgsql/src/backend/access/nbtree/nbtinsert.c,v
retrieving revision 1.176
diff -u -3 -p -r1.176 nbtinsert.c
--- src/backend/access/nbtree/nbtinsert.c 2 Jan 2010 16:57:35 - 1.176
+++ src/backend/access/nbtree/nbtinsert.c 20 Jan 2010 22:56:55 -
@@ -381,8 +381,11 @@ _bt_check_unique(Relation rel, IndexTupl
values, isnull);
ereport(ERROR,
(errcode(ERRCODE_UNIQUE_VIOLATION),
- errmsg("duplicate key value violates unique constraint \"%s\"",
- RelationGetRelationName(rel)),
+ (rel->rd_index->indisprimary
+ ? errmsg("duplicate key value violates primary key \"%s\"",
+ RelationGetRelationName(rel))
+ : errmsg("duplicate key value violates unique constraint \"%s\"",
+ RelationGetRelationName(rel))),
errdetail("Key %s already exists.",
BuildIndexValueDescription(rel,
values, isnull;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
Grzegorz Jaskiewicz wrote: On 21 Jan 2010, at 09:37, Dave Page wrote: In an attempt to pre-empt the normally drawn-out discussions about what the next version of PostgreSQL will be numbered. the core team have discussed the issue and following a lenghty debate lasting literally a few minutes decided that the next release shall be Wait for it 9.0. darn, looks like PostgreSQL developers can only count to 4 :) http://www.postgresql.org/docs/current/static/release-6-5.html :) Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
On 21 Jan 2010, at 09:37, Dave Page wrote: > In an attempt to pre-empt the normally drawn-out discussions about > what the next version of PostgreSQL will be numbered. the core team > have discussed the issue and following a lenghty debate lasting > literally a few minutes decided that the next release shall be > > Wait for it > > 9.0. darn, looks like PostgreSQL developers can only count to 4 :) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PITR backup history files with identical 2nd part file names
Hello After upgrading to 8.3.9 and moving some our PostgreSQL clusters to a new server yesterday, we have experienced a strange thing this past night. All PITR backup history files created when running a PITR base backup on all PostgreSQL clusters running in this new server (at different hours during the night) got an identical 2nd part file name. <24 digits>.0020.backup e.g.000202080060.0020.backup All of them got 0020.backup. as 2nd part of the file name. After checking old logfiles from other servers, we can say that this is the first time this happens. They used to be very different values each time we run a PITR base backup. We found this because a 'bug' in the script we use to create the PITR base backup. This script could not find out the WAL files to be deleted after one of the base backup was finished because 0020 could be found in all WAL file names in one of the clusters. This 'bug' has been already fixed in our script. After some more testing, it looks like we get the same 2nd part of the file name *everytime* we run a PITR base backup i.e. '.0020.backup'. This happens on 10 different postgreSQL clusters runnig on the same server. Is it normal to get the same 2nd part of the file name all the time? How is this value generated? This behavior is strange and I wonder if there is anything wrong with this new server. Everything else looks ok and works without problems. Thanks in advance. -- Rafael Martinez, Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Application name patch - v3
Le 15/01/2010 18:53, Guillaume Lelarge a écrit :
> Le 08/01/2010 23:22, Guillaume Lelarge a écrit :
>> Le 07/01/2010 19:13, Robert Haas a écrit :
>>> On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
>>> wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
> Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
>> Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
>>> Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge writes:
> Le 28/12/2009 17:06, Tom Lane a écrit :
>> I think we were stalled on the question of whether to use one array
>> or two parallel arrays. Do you want to try coding up a sample usage
>> of each possibility so we can see which one seems more useful?
> I'm interested in working on this. But I don't find the thread that
> talk
> about this.
Try here
http://archives.postgresql.org/message-id/4aae8ccf.9070...@esilo.com
>>>
>>> Thanks. I've read all the "new version of PQconnectdb" and "Determining
>>> client_encoding from client locale" threads. I think I understand the
>>> goal. Still need to re-read this one
>>> (http://archives.postgresql.org/message-id/6222.1253734...@sss.pgh.pa.us)
>>> and
>>> completely understand it (will probably need to look at the code, at
>>> least the PQconnectdb one). But I'm definitely working on this.
>>>
>>
>> If I try to sum up my readings so far, this is what we still have to do:
>>
>> 1. try the one-array approach
>>PGconn *PQconnectParams(const char **params)
>>
>> 2. try the two-arrays approach
>>PGconn *PQconnectParams(const char **keywords, const char **values)
>>
>> Instead of doing a wrapper around PQconnectdb, we need to refactor the
>> whole function, so that we can get rid of the parsing of the conninfo
>> string (which is quite complicated).
>>
>> Using psql as an example would be a good idea, AFAICT.
>>
>> Am I right? did I misunderstand or forget something?
>>
>
> I supposed I was right since noone yell at me :)
>
> I worked on this tonight. You'll find two patches attached, one for the
> one-array approach, one for the two-arrays approach. I know some more
> factoring can be done (at least, the "get the fallback resources..."
> part). I'm OK to do them. I just need to know if I'm on the right track.
>
Hmmm... sorry but... can i have some comments on these two patches, please?
>>>
>>> I would suggest adding your patch(es) to:
>>>
>>> https://commitfest.postgresql.org/action/commitfest_view/open
>>>
>>> Probably just one entry for the two of them would be most appropriate.
>>>
>>
>> Done. Thanks.
>>
>
> New patches because the old ones didn't apply anymore, due to recent CVS
> commits.
>
New patches for same reason.
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
Index: src/bin/psql/startup.c
===
RCS file: /opt/cvsroot_postgresql/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.158
diff -c -p -c -r1.158 startup.c
*** src/bin/psql/startup.c 2 Jan 2010 16:57:59 - 1.158
--- src/bin/psql/startup.c 4 Jan 2010 21:04:13 -
*** main(int argc, char *argv[])
*** 171,181
/* loop until we have a password if requested by backend */
do
{
! new_pass = false;
! pset.db = PQsetdbLogin(options.host, options.port, NULL, NULL,
! options.action == ACT_LIST_DB && options.dbname == NULL ?
! "postgres" : options.dbname,
! options.username, password);
if (PQstatus(pset.db) == CONNECTION_BAD &&
PQconnectionNeedsPassword(pset.db) &&
--- 171,190
/* loop until we have a password if requested by backend */
do
{
! const char *params[] = {
! "host", options.host,
! "port", options.port,
! "dbname", (options.action == ACT_LIST_DB &&
!options.dbname == NULL) ? "postgres" : options.dbname,
! "user", options.username,
! "password", password,
! "application_name", pset.progname,
! NULL, NULL
! };
!
! new_pass = false;
!
! pset.db = PQconnectdbParams(params);
if (PQstatus(pset.db) == CONNECTION_BAD &&
PQconnectionNeedsPassword(pset.db) &&
Index: src/interfaces/libpq/exports.txt
===
RCS file: /opt/cvsroot_postgresql/pgsql/src/interfaces/libpq/exports.txt,v
retrieving revision 1.24
diff -c -p -c -r1.24 exports.txt
*** src/interfaces/libpq/exports.txt 21 Jan 2010 14:58:53 - 1.24
--- src/interfaces/libpq/exports.txt 21 Jan 2010 19:40:50 -
*** PQconninfoParse 152
*** 155,157
--- 155,159
PQinitOpenSSL
Re: [HACKERS] quoting psql varible as identifier
2010/1/21 Robert Haas : > On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule > wrote: >> add to state structure field like lexer_error. This field will be >> checked before execution >> it could be ugly for metacommands, there will be lot of new checks :( > > Eh? The only places where we should need new tests are the places > that check PQExpBufferBroken() now - there are only 6 calls to that > function in src/bin/psql and not all of them need to be changed. The > places that do need to be changed will need to be modified to check > PQExpBufferBroken() || lexer_coughed_up_a_lung. no, it is only 6 calls because we don't check psql_scan_slash_option result. When we don't allow escaping syntax in slash statement, then it could be simple. we have to do some like: if buffer_is_broken(..) report "out of memory" else if global_error != true do end if Pavel > > It should be possible to do this pretty simply, I think. > > ...Robert > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Partitioning syntax
On Mon, Jan 18, 2010 at 3:55 AM, Takahiro Itagaki wrote: > Robert Haas wrote: >> A couple of preliminary comments on this: > > Thanks. > The attached is rebased on HEAD, with additional documentation. > >> 1. If we're thinking that this syntax should eventually result in >> inserts (and updates?) being redirected to the appropriate partition, >> then I think we should have that in the initial version. I don't >> think we really want to add the syntax with a plan to change its >> behavior incompatibly down the road. > > It's true that we need an alternative method for insert triggers, > but I'd like to submit it as another patch in the next development cycle. > I think the syntax proposed here is carefully chosen so that we will > not frequently modify modify them. But I think users have the right to expect that the behavior of a feature will be consistent. If, in 9.0, we add this feature and tell people to start using it, then when 9.1 comes out and includes automatic routing of inserts to the proper partition, their applications will break. I don't think there's enough value in this by itself to think that we're getting something by committing it now - it's better to let people do it the way they have been for 9.0, and then have a more complete implementation for 9.1. Maybe if we were at the very beginning of the release cycle we could think about committing this first and then making the other changes before release, but even that is something we usually shy away from, in case people get bogged down and don't have time to finish the work. >> 2. The documentation does not explain what partitioning by list or by >> range means, or what the difference between the two is. I think some >> kind of general introduction to the subject is essential. > > Oops, I've forgotten to update ddl.sgml for the new syntax. I rewrote > ddl-partition section to use the new syntax, with some other changes: > > 1. Use PARTITION BY RANGE and CREATE PARTITION for the example. > > 2. Recommend to define indexes for the parent table, and copy the > definition to each partition with CREATE PARTITION or > CREATE TABLE (LIKE INCLUDING ALL). > > 3. Use an EXECUTE USING rather than a huge IF-THEN-ELSE block > in the insert trigger. The new recommended code is: > EXECUTE 'INSERT INTO ' || to_relname(NEW) || ' VALUES ($1.*)' USING NEW; > We don't need to update the trigger function if partitions are > added or removed with this form. > > We could apply changes in 2 and 3 even without the partitioning patch. > I think we can define trigger functions with EXECUTE USING easliy > compared to before. I'm willing to split the doc patch if needed. > >> 3. This patch is large enough (+1951/-63) that we have to consider >> whether it makes sense to merge it at this point in the release cycle. >> It doesn't change much existing code, which is a point in its favor, >> but it's still a big patch. I guess we can wait until we're a little >> further along to make that decision. > > It depends on reviewers :) But I think the partitioning patch never > go to waste -- I'll continue to improve it if any feedbacks. I agree - it will not go to waste. I'm glad you're planning to continue working on it. I'll try to take a little bit more look at the code (or perhaps someone else will weigh in) but I don't think we should expect it to go in this time around. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] quoting psql varible as identifier
On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule wrote: > add to state structure field like lexer_error. This field will be > checked before execution > it could be ugly for metacommands, there will be lot of new checks :( Eh? The only places where we should need new tests are the places that check PQExpBufferBroken() now - there are only 6 calls to that function in src/bin/psql and not all of them need to be changed. The places that do need to be changed will need to be modified to check PQExpBufferBroken() || lexer_coughed_up_a_lung. It should be possible to do this pretty simply, I think. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
On Thu, Jan 21, 2010 at 1:28 PM, Leonardo F wrote: >> Well, the expression cases would be more likely to cost more if >> implemented as a sort, but that doesn't mean that a sort couldn't be a >> win. Besides, even if you blow off the expression case, what about >> nulls first/last, nondefault opclasses, etc? > > > Ok, let's split the problem in 2 parts: > > a) "choosing the right path" > b) "using seq scan + sort in case the planner (somehow) said it's faster" > > You're right: for a) nondefault opclasses and other things would make the > SPI version "wrong". So let's stick for the moment with the cost_sort > create_index_path etc calls for a). I think that the calls to > create_index_path > would also deal with every other possible index type (something that's > impossible with the SPI version). > > For b): > > I'm using the code in > > http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php > > That doesn't deal with expression indexes, nor with anything that is not > a btree index. But it's much faster on what people use the most (and not > slower on anything else). > > So my proposal would be: do the test seq_scan vs sort/index_scan only for > regular btree index, and integrate that test in the planner. > > That doesn't mean that sometime in the future we're not going to have full > support for all index types in seq scan + sort CLUSTER... but I would like > to have something that works faster on what people use, and not slower > in the other cases without waiting ages to have the "whole" thing... Keep in mind that this patch was after the deadline for 9.0, so there is probably not a huge rush to get this done. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
> Well, the expression cases would be more likely to cost more if > implemented as a sort, but that doesn't mean that a sort couldn't be a > win. Besides, even if you blow off the expression case, what about > nulls first/last, nondefault opclasses, etc? Ok, let's split the problem in 2 parts: a) "choosing the right path" b) "using seq scan + sort in case the planner (somehow) said it's faster" You're right: for a) nondefault opclasses and other things would make the SPI version "wrong". So let's stick for the moment with the cost_sort create_index_path etc calls for a). I think that the calls to create_index_path would also deal with every other possible index type (something that's impossible with the SPI version). For b): I'm using the code in http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php That doesn't deal with expression indexes, nor with anything that is not a btree index. But it's much faster on what people use the most (and not slower on anything else). So my proposal would be: do the test seq_scan vs sort/index_scan only for regular btree index, and integrate that test in the planner. That doesn't mean that sometime in the future we're not going to have full support for all index types in seq scan + sort CLUSTER... but I would like to have something that works faster on what people use, and not slower in the other cases without waiting ages to have the "whole" thing... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: regschema OID type
On Jan 21, 2010, at 10:06 AM, Tom Lane wrote: > Well, without a context that explains *why* you're doing that, it's hard > to consider what a better solution would look like. Personally I > usually prefer solutions involving WHERE oid = 'foo.bar'::regclass, > because that scales easily to either providing or omitting the schema > reference. It never occurred to me. And does `oid = bar::regclass` return true if bar is in a schema not in the search path? But yeah, I need to avoid errors, too. > If you're trying to avoid throwing an error on bad schema name, > a regschema type would not help you. Good point. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: regschema OID type
"David E. Wheeler" writes: > The names of schemas in which to find functions, tables, views, triggers, > etc. etc. I have lots of stuff like this: > SELECT true > FROM pg_catalog.pg_namespace n > JOIN pg_catalog.pg_class c ON n.oid = c.relnamespace > WHERE c.relkind = $1 >AND n.nspname = $2 >AND c.relname = $3 Well, without a context that explains *why* you're doing that, it's hard to consider what a better solution would look like. Personally I usually prefer solutions involving WHERE oid = 'foo.bar'::regclass, because that scales easily to either providing or omitting the schema reference. If you're trying to avoid throwing an error on bad schema name, a regschema type would not help you. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL-ism help patch for psql
On Jan 21, 2010, at 12:02 PM, Tom Lane wrote:
David Christensen writes:
Should the error messages between the SHOW cases and the others be
consistent ("ERROR: unsupported command" or similar)? It's worth
noting that this is only in the psql client, but we could simulate
the
ereport output from the server.
No. Not unless you want to simulate it to the point of honoring the
different verbosity settings, which would greatly expand the size of
the
patch. We do not try to make the response to "help" look like an
error
message, and I don't see the value of doing so here either.
(I think Florian's real problem with the proposed output is that it's
ugly, which I agree with --- the formatting is strange.)
I'm with you on that one; I tried to address that in the second
revision of the patch. But I'm definitely open to suggestions.
Regards,
David
--
David Christensen
End Point Corporation
da...@endpoint.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL-ism help patch for psql
David Christensen writes:
> Should the error messages between the SHOW cases and the others be
> consistent ("ERROR: unsupported command" or similar)? It's worth
> noting that this is only in the psql client, but we could simulate the
> ereport output from the server.
No. Not unless you want to simulate it to the point of honoring the
different verbosity settings, which would greatly expand the size of the
patch. We do not try to make the response to "help" look like an error
message, and I don't see the value of doing so here either.
(I think Florian's real problem with the proposed output is that it's
ugly, which I agree with --- the formatting is strange.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: regschema OID type
On Jan 21, 2010, at 11:56 AM, Tom Lane wrote: David Christensen writes: Enclosed is a patch adding a 'regschema' OID type. What in the world is the point of that? The regfoo types are for things that have schema-qualified names. Perhaps the naming is a bit disingenuous, and I'm not tied to it; I like the ability to translate between oid <-> name that regclass, regproc, etc. provide. This simplifies query lookups and manual examination of the system tables and for me at least fills a need. Do you have a better type name? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: regschema OID type
On Jan 21, 2010, at 9:57 AM, Tom Lane wrote: > Schema names of what? It sounds to me like you're failing to use the > existing regfoo types in appropriate places ... The names of schemas in which to find functions, tables, views, triggers, etc. etc. I have lots of stuff like this: SELECT true FROM pg_catalog.pg_namespace n JOIN pg_catalog.pg_class c ON n.oid = c.relnamespace WHERE c.relkind = $1 AND n.nspname = $2 AND c.relname = $3 I'd love to instead do something like: SELECT true FROM pg_catalog.pg_class c WHERE c.relkind = $1 AND c.relnamespace::regschema = $2 AND c.relname = $3 Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL-ism help patch for psql
2010/1/21 David Christensen :
>
> On Jan 21, 2010, at 11:48 AM, Florian Weimer wrote:
>
>> * David Christensen:
>>
>>> Currently, a session will look like the following:
>>>
>>> machack:machack:5485=# show tables;
>>> See:
>>> \d
>>> or \? for general help with psql commands
>>> machack:machack:5485=#
>>>
>>> Said formatting looks like it could use some improvement, open to
>>> suggestions, but something on a single line seems more useful.
>>
>> You should at least make clear that this is an error message due to an
>> unsupported command. The output above looks broken. Something like
>> this should be okay, I think:
>>
>> ERROR: unrecognized configuration parameter "tables"
>> NOTICE: use \d to list tables, or \? for general help with psql commands
>>
>> ERROR: unrecognized configuration parameter "databases"
>> NOTICE: use \l to list databases, or \? for general help with psql
>> commands
>
>
> That's a very good point as far as the visibility is concerned. Should the
> error messages between the SHOW cases and the others be consistent ("ERROR:
> unsupported command" or similar)? It's worth noting that this is only in
> the psql client, but we could simulate the ereport output from the server.
I don't think so it is the best idea. I like different message types,
because I able to identify place of error. If it is server or client
error.
Pavel
>
> Regards,
>
> David
> --
> David Christensen
> End Point Corporation
> da...@endpoint.com
>
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: regschema OID type
"David E. Wheeler" writes: > OOh, /me likey! This would save me a ton of code in pgTAP (about half its > queries have to join to pg_namespace to get schema names). Schema names of what? It sounds to me like you're failing to use the existing regfoo types in appropriate places ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL-ism help patch for psql
On Jan 21, 2010, at 11:48 AM, Florian Weimer wrote:
* David Christensen:
Currently, a session will look like the following:
machack:machack:5485=# show tables;
See:
\d
or \? for general help with psql commands
machack:machack:5485=#
Said formatting looks like it could use some improvement, open to
suggestions, but something on a single line seems more useful.
You should at least make clear that this is an error message due to an
unsupported command. The output above looks broken. Something like
this should be okay, I think:
ERROR: unrecognized configuration parameter "tables"
NOTICE: use \d to list tables, or \? for general help with psql
commands
ERROR: unrecognized configuration parameter "databases"
NOTICE: use \l to list databases, or \? for general help with psql
commands
That's a very good point as far as the visibility is concerned.
Should the error messages between the SHOW cases and the others be
consistent ("ERROR: unsupported command" or similar)? It's worth
noting that this is only in the psql client, but we could simulate the
ereport output from the server.
Regards,
David
--
David Christensen
End Point Corporation
da...@endpoint.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: regschema OID type
David Christensen writes: > Enclosed is a patch adding a 'regschema' OID type. What in the world is the point of that? The regfoo types are for things that have schema-qualified names. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] quoting psql varible as identifier
2010/1/21 Robert Haas :
> On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule
> wrote:
>> 2010/1/21 Robert Haas :
>>> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'd like to proceed by committing an initial patch which changes the
>> "Escaping Strings for Inclusion in SQL Commands" to use a
>> with one per function (as we do in
>> surrounding functions) and consolidates it with the following section,
>> "Escaping Binary Strings for Inclusion in SQL Commands". Then I'll
>> submit a patch implementing pqEscapeLiteral() and pqEscapeIdentifier()
>> as discussed here, and the doc diff hunks will actually be readable.
>
> Sounds like a plan.
Initial commit done, and follow-on patch attached. The docs took
longer to write than the code. I spent a fair amount of time trying
to make it all make sense, but suggestions are welcome.
>>>
>>> Committed after fixing a couple of oversights in my doc changes.
>>
>> thank you.
>>
>> I actualised patch
>>
>> I thing, we need one libpq change more.
>>
>> + static void
>> + appendLiteral(PGconn *conn, PQExpBuffer buf, const char *str)
>> + {
>> + char *escaped_str;
>> + size_t len;
>> +
>> + len = strlen(str);
>> + escaped_str = PQescapeLiteral(conn, str, len);
>> +
>> + if (escaped_str == NULL)
>> + {
>> + const char *error_message = PQerrorMessage(pset.db);
>> +
>> + if (strlen(error_message))
>> + psql_error("%s", error_message);
>> + }
>> + else
>> + {
>> + appendPQExpBufferStr(buf, escaped_str);
>> + free(escaped_str);
>> + }
>> + }
>>
>> the correct result of this function (when is some error) is broken
>> buffer. But function markPQExpBufferBroken is static.
>
> markPQExpBufferBroken is specifically designed to handle out of memory
> errors. I don't think we should try to generalize that to handle
> encoding violations or other things, at least not without some very
> careful thought about the consequences of so doing. I think we need
> to find some other way of signalling an error back to the caller,
> although it's not exactly obvious to me what the best way to do that
> is.
BufferBroken flag is used as signal for out of memory now. But
everybody can use it for his purposes. There isn't any limit (what I
know). More - the behave is similar like NULL. If you have a broken
buffer, then everything with this is broken. Theoretically we could to
add some parser state flag and check it over every scanner call - but
it is duplicate. minimally when escape function returns null because
is out of memory, then breaking the buffer is semantically correct.
Currently there isn't consistency in memory handling :( - from good
reasons. Bad allocation from libpq is finished with raising a error
message. Out of memory from psql is raising fatal error. I am not
sure, if we can better join these two worlds. Maybe we can add malloc
handler to libpq (maybe in future)?
Still there are two kind of bugs - memory and encoding. These bugs
should be handled differently. In both cases we cannot stop lexers -
because we have to find end of statement, we cannot to execute broken
command.
my plan
add to state structure field like lexer_error. This field will be
checked before execution
it could be ugly for metacommands, there will be lot of new checks :(
Pavel
>
> ...Robert
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: regschema OID type
On Jan 21, 2010, at 9:46 AM, David Christensen wrote: > It uses the same quoting mechanism as regclass, and I've tested against some > odd schema names such as "foo""schema"; I updated the docs as I was able, but > am not familiar enough with the regression tests to add those yet. I hope to > address that in a future revision. OOh, /me likey! This would save me a ton of code in pgTAP (about half its queries have to join to pg_namespace to get schema names). Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MySQL-ism help patch for psql
* David Christensen: > Currently, a session will look like the following: > > machack:machack:5485=# show tables; > See: > \d > or \? for general help with psql commands > machack:machack:5485=# > > Said formatting looks like it could use some improvement, open to > suggestions, but something on a single line seems more useful. You should at least make clear that this is an error message due to an unsupported command. The output above looks broken. Something like this should be okay, I think: ERROR: unrecognized configuration parameter "tables" NOTICE: use \d to list tables, or \? for general help with psql commands ERROR: unrecognized configuration parameter "databases" NOTICE: use \l to list databases, or \? for general help with psql commands (I hope that this is less controversial, too.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Patch: regschema OID type
Hey -hackers, Enclosed is a patch adding a 'regschema' OID type. I'm really just hoping to get this out there, don't worry about committing it at this point. This is something that I've always wanted in the field (yes, I'm lazy). Many thanks to RhodiumToad for pointers about the necessary system table entries and general advice. Example usage: machack:postgres:8555=# select relnamespace::regschema, relname from pg_class limit 10; relnamespace| relname +-- pg_catalog | pg_type pg_catalog | pg_attribute information_schema | foreign_data_wrapper_options information_schema | foreign_data_wrappers information_schema | _pg_foreign_servers information_schema | foreign_server_options information_schema | foreign_servers information_schema | _pg_user_mappings information_schema | user_mapping_options information_schema | user_mappings (10 rows) It uses the same quoting mechanism as regclass, and I've tested against some odd schema names such as "foo""schema"; I updated the docs as I was able, but am not familiar enough with the regression tests to add those yet. I hope to address that in a future revision. Thanks, David -- David Christensen End Point Corporation da...@endpoint.com regschema.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GUC failure on exception
On Jan 19, 2010, at 9:26 PM, Andrew Dunstan wrote: > The first thing I think we need to do is move the GUC processing code out of > _PG_init() and into plperl_init_interp(), protected by a flag to make sure > it's only called successfully once. I'm trying to work out a neat way to put > the value back if there is an exception, but it's a bit ugly. Will this solve the underlying bug in custom GUCs? I'm assuming there is such a bug. Won't this be an issue for other modules that have custom GUCs, potentially a security issue? The addition of new PL/Perl custom GUCs notwithstanding, it sure seems like a potential security vulnerability such as this should be addressed ASAP. Who knows this stuff? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL
On Jan 21, 2010, at 9:19 AM, Robert Haas wrote: > As far as I can see, there is absolutely zero reason to care about > whether the product is called Postgres or PostgreSQL. How about simply "Post"? Or just "SQL"? ;-P > If it were > called WeGrindUpTheBonesOfSmallChildrenSQL, maybe a change would be > worth considering. And where do you think baby powder comes from? Sheesh. > As it is, I submit that the product name is not on > in the top 10,000 things we should be worried about fixing, even if > there were a consensus that it were a good idea (which there isn't) > and even if -core had not already made a decision on this point (which > they have). What I think we SHOULD be worrying about right now is > getting 9.0 out the door, and I am 100% opposed to letting ourselves > getting sucked into this or any other discussion which is likely to > make that take longer than it likely already will. +1 David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] quoting psql varible as identifier
On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule wrote:
> 2010/1/21 Robert Haas :
>> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
>>> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
Robert Haas writes:
> I'd like to proceed by committing an initial patch which changes the
> "Escaping Strings for Inclusion in SQL Commands" to use a
> with one per function (as we do in
> surrounding functions) and consolidates it with the following section,
> "Escaping Binary Strings for Inclusion in SQL Commands". Then I'll
> submit a patch implementing pqEscapeLiteral() and pqEscapeIdentifier()
> as discussed here, and the doc diff hunks will actually be readable.
Sounds like a plan.
>>>
>>> Initial commit done, and follow-on patch attached. The docs took
>>> longer to write than the code. I spent a fair amount of time trying
>>> to make it all make sense, but suggestions are welcome.
>>
>> Committed after fixing a couple of oversights in my doc changes.
>
> thank you.
>
> I actualised patch
>
> I thing, we need one libpq change more.
>
> + static void
> + appendLiteral(PGconn *conn, PQExpBuffer buf, const char *str)
> + {
> + char *escaped_str;
> + size_t len;
> +
> + len = strlen(str);
> + escaped_str = PQescapeLiteral(conn, str, len);
> +
> + if (escaped_str == NULL)
> + {
> + const char *error_message = PQerrorMessage(pset.db);
> +
> + if (strlen(error_message))
> + psql_error("%s", error_message);
> + }
> + else
> + {
> + appendPQExpBufferStr(buf, escaped_str);
> + free(escaped_str);
> + }
> + }
>
> the correct result of this function (when is some error) is broken
> buffer. But function markPQExpBufferBroken is static.
markPQExpBufferBroken is specifically designed to handle out of memory
errors. I don't think we should try to generalize that to handle
encoding violations or other things, at least not without some very
careful thought about the consequences of so doing. I think we need
to find some other way of signalling an error back to the caller,
although it's not exactly obvious to me what the best way to do that
is.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify - what to do when the queue is full
On Thu, 2010-01-21 at 10:14 +0100, Joachim Wieland wrote: > On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis wrote: > > Here's the problem as I see it: > > You are writing a lot of true facts but I miss to find a real > problem... What exactly do you see as a problem? I worded that in a confusing way, I apologize. My point was that I don't think we need a lock, because I don't see any situation in which the notifications would be lost. > I have been working on simplifying the patch yesterday, I still need > to adapt comments and review it again but I am planning to post the > new version tonight. Then we have a common base again to discuss > further :-) Sounds good. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL
On Thu, Jan 21, 2010 at 11:59 AM, Pavel Stehule wrote: Better yet, how about we bite the bullet and make the name change official. Seems like a major version bump is the right time to do it. >> >>> I thought we ended up that thread already? >> >> Well, the thread may have ended, but the problem remains. Call >> it the 900 pound gorilla in a room full of elephants. I know >> many people are loathe to see the discussion come up again, >> but as long as the project is saddled with its ugly and >> unweildy official name, it has a large problem. > > it is your opinion - not my. I thing, so is nonsense returning to > closed chapters. I couldn't have said it better myself. As far as I can see, there is absolutely zero reason to care about whether the product is called Postgres or PostgreSQL. If it were called WeGrindUpTheBonesOfSmallChildrenSQL, maybe a change would be worth considering. As it is, I submit that the product name is not on in the top 10,000 things we should be worried about fixing, even if there were a consensus that it were a good idea (which there isn't) and even if -core had not already made a decision on this point (which they have). What I think we SHOULD be worrying about right now is getting 9.0 out the door, and I am 100% opposed to letting ourselves getting sucked into this or any other discussion which is likely to make that take longer than it likely already will. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
Leonardo F writes: > I hoped that since people mostly (>95%?) use plain btree indexes, > a patch that helped CLUSTER with using such indexes would be fine > (at least at first...). I guess that a patch that deals with all other types > of > indexes would be way more complicated (not at the "planning" stage, > but in the scan+sort phase)? Well, the expression cases would be more likely to cost more if implemented as a sort, but that doesn't mean that a sort couldn't be a win. Besides, even if you blow off the expression case, what about nulls first/last, nondefault opclasses, etc? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
> > I meant to add only ASC/DESC; I would leave all other cases > > (non-btrees, custom expression btrees) to use the old index-scan method. > > That hardly seems acceptable. Well I brought up that in an earlier post: http://old.nabble.com/Re%3A-About-%22Our-CLUSTER-implementation-is-pessimal%22-patch-p27179107.html I hoped that since people mostly (>95%?) use plain btree indexes, a patch that helped CLUSTER with using such indexes would be fine (at least at first...). I guess that a patch that deals with all other types of indexes would be way more complicated (not at the "planning" stage, but in the scan+sort phase)? > I hardly think that keeping yourself at arm's length from the planner > by getting cozy with SPI internals is a net improvement in modularity. So you think that code snippet that I sent earlier (the function that uses create_index_path etc) could be put in planner.c (almost) as it is? It looked clumsy to me (I liked the SPI code better) Leonardo -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL
2010/1/21 Greg Sabino Mullane : > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > >>> Better yet, how about we bite the bullet and make the name change >>> official. Seems like a major version bump is the right time >>> to do it. > >> I thought we ended up that thread already? > > Well, the thread may have ended, but the problem remains. Call > it the 900 pound gorilla in a room full of elephants. I know > many people are loathe to see the discussion come up again, > but as long as the project is saddled with its ugly and > unweildy official name, it has a large problem. it is your opinion - not my. I thing, so is nonsense returning to closed chapters. Regards Pavel > > It's really in the best interests of the project to make the > change as soon as possible, and undo the mistake of changing > it from Postgres in the first place. Changing it to coincide > with the interest bounce we'll get from the Oracle/MySQL > situation seems a no-brainer from an advocacy perspective. > > - -- > Greg Sabino Mullane g...@turnstep.com > PGP Key: 0x14964AC8 201001211135 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -BEGIN PGP SIGNATURE- > > iEYEAREDAAYFAktYgw0ACgkQvJuQZxSWSsjgSwCghMphV61CIRDBGGscItZxvVQ9 > E54AnjGqqYuXewjmwszaXX0sP7oWlg68 > =DQfT > -END PGP SIGNATURE- > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] quoting psql varible as identifier
2010/1/21 Robert Haas :
> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote:
>> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
>>> Robert Haas writes:
I'd like to proceed by committing an initial patch which changes the
"Escaping Strings for Inclusion in SQL Commands" to use a
with one per function (as we do in
surrounding functions) and consolidates it with the following section,
"Escaping Binary Strings for Inclusion in SQL Commands". Then I'll
submit a patch implementing pqEscapeLiteral() and pqEscapeIdentifier()
as discussed here, and the doc diff hunks will actually be readable.
>>>
>>> Sounds like a plan.
>>
>> Initial commit done, and follow-on patch attached. The docs took
>> longer to write than the code. I spent a fair amount of time trying
>> to make it all make sense, but suggestions are welcome.
>
> Committed after fixing a couple of oversights in my doc changes.
thank you.
I actualised patch
I thing, we need one libpq change more.
+ static void
+ appendLiteral(PGconn *conn, PQExpBuffer buf, const char *str)
+ {
+ char*escaped_str;
+ size_t len;
+
+ len = strlen(str);
+ escaped_str = PQescapeLiteral(conn, str, len);
+
+ if (escaped_str == NULL)
+ {
+ const char *error_message = PQerrorMessage(pset.db);
+
+ if (strlen(error_message))
+ psql_error("%s", error_message);
+ }
+ else
+ {
+ appendPQExpBufferStr(buf, escaped_str);
+ free(escaped_str);
+ }
+ }
the correct result of this function (when is some error) is broken
buffer. But function markPQExpBufferBroken is static.
Regards
Pavel Stehule
>
> ...Robert
>
patch.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL
"Greg Sabino Mullane" wrote: > many people are loathe to see the discussion come up again, > but as long as the project is saddled with its ugly and > unweildy official name, it has a large problem. I don't particularly like the official stance on pronouncing it, but other than that I see no problem. Just pronounce the "QL" in PostgreSQL the same way you do the "b" in subtle and have done with it. I'm not for changing the spelling of either one. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >> Better yet, how about we bite the bullet and make the name change >> official. Seems like a major version bump is the right time >> to do it. > I thought we ended up that thread already? Well, the thread may have ended, but the problem remains. Call it the 900 pound gorilla in a room full of elephants. I know many people are loathe to see the discussion come up again, but as long as the project is saddled with its ugly and unweildy official name, it has a large problem. It's really in the best interests of the project to make the change as soon as possible, and undo the mistake of changing it from Postgres in the first place. Changing it to coincide with the interest bounce we'll get from the Oracle/MySQL situation seems a no-brainer from an advocacy perspective. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201001211135 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAktYgw0ACgkQvJuQZxSWSsjgSwCghMphV61CIRDBGGscItZxvVQ9 E54AnjGqqYuXewjmwszaXX0sP7oWlg68 =DQfT -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git out of sync vs. CVS
Magnus Hagander writes: > So the list really isn't very long. I think it's perfectly possible to > clear it off before the release. Because we still only want to change > after the release, or are you saying once those are fixed, we can > change even if we happen to be in beta at the time? When and if we have the prerequisite tasks done, it'll be time enough to think about exactly when to schedule the move. Given the amount of movement on the prerequisites in the past year, I'm not planning to worry about it today. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
Leonardo F writes: >> By the time you make this actually work in all cases, it's probably >> going to be more of a mess than the other way; > I meant to add only ASC/DESC; I would leave all other cases > (non-btrees, custom expression btrees) to use the old index-scan method. That hardly seems acceptable. >> not to mention that it >> doesn't work *at all* without violating SPI internals. > You lost me there... You're poking into a data structure you shouldn't be poking into: /* Plans are opaque structs for standard users of SPI */ typedef struct _SPI_plan *SPIPlanPtr; I hardly think that keeping yourself at arm's length from the planner by getting cozy with SPI internals is a net improvement in modularity. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] lock_timeout GUC patch
Boszormenyi Zoltan writes: > You expressed stability concerns coming from this patch. > Were these concerns because of locks timing out making > things fragile or because of general feelings about introducing > such a patch at the end of the release cycle? I was thinking > about the former, hence this modification. Indeed, I am *very* concerned about the stability implications of this patch. I just don't believe that arbitrarily restricting which processes the GUC applies to will make it any safer. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
> By the time you make this actually work in all cases, it's probably > going to be more of a mess than the other way; I meant to add only ASC/DESC; I would leave all other cases (non-btrees, custom expression btrees) to use the old index-scan method. > not to mention that it > doesn't work *at all* without violating SPI internals. You lost me there... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] lock_timeout GUC patch
Tom Lane írta: > Robert Haas writes: > >> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote: >> >>> I would like a mini-review on the change I made in the latest >>> patch by introducing the validator function. Is it enough >>> to check for >>>(source == PGC_S_DEFAULT || source == PGC_S_SESSION) >>> to ensure only interactive sessions can get lock timeouts? >>> > > >> I'm not sure that I know how this should work, but that approach seems >> a little strange to me. Why would we not allow PGC_S_USER, for >> example? >> > > Why is this a good idea at all? I can easily see somebody feeling that > he'd like autovacuums to fail rather than block on locks for a long > time, for example. > You expressed stability concerns coming from this patch. Were these concerns because of locks timing out making things fragile or because of general feelings about introducing such a patch at the end of the release cycle? I was thinking about the former, hence this modification. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] lock_timeout GUC patch
Robert Haas writes: > On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane wrote: >> Why is this a good idea at all? I can easily see somebody feeling that >> he'd like autovacuums to fail rather than block on locks for a long >> time, for example. > What I can see happening is someone setting this GUC in > postgresql.conf and then being surprised that it applied to thinks > like walreceiver and autovacuum, in addition to user queries. Are we > even sure that that code would all behave sanely with this behavior? No, I'm not sure, as I said before ;-). But a 100%-arbitrary restriction like "it doesn't apply to background processes" will not make it noticeably safer. There is very damn little code that only executes in background and never anywhere else. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
Leonardo F writes: >> one idea could be to actually prepare a query using SPI for "select * from >> table order by " and then peek inside >> to see which plan was generated. > I like that!!! > Here's a first attempt, it looks like it's working... > (I still have to skip non-btree indexes and expression indexes, plus > add a ASC/DESC to the select) By the time you make this actually work in all cases, it's probably going to be more of a mess than the other way; not to mention that it doesn't work *at all* without violating SPI internals. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git out of sync vs. CVS
Tom Lane wrote: > I have noticed that CVS operations (at least from the user's > viewpoint) work in local time. So even if the clocks are synced, > a different TZ setting could conceivably lead to issues. Hmmm... If that were the issue I would think we'd've seen the problem more often. From reading over the Ruby code, it appears to me that if a commit happens when fromcvs is scanning for recent commits, and commit touches a part the scan has already passed, we'd see anomalies like this, although my weak Ruby skills leave me less than 100% sure. The same skill deficiency means it would take me at least three FTE days to fix the flaw in fromcvs, which I'd have to do off-hours. So add me to the list of people who think that if these are going to be recurring, we should look at moving from cvs to git as soon as 9.0 is released. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] lock_timeout GUC patch
On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote: >>> I would like a mini-review on the change I made in the latest >>> patch by introducing the validator function. Is it enough >>> to check for >>> (source == PGC_S_DEFAULT || source == PGC_S_SESSION) >>> to ensure only interactive sessions can get lock timeouts? > >> I'm not sure that I know how this should work, but that approach seems >> a little strange to me. Why would we not allow PGC_S_USER, for >> example? > > Why is this a good idea at all? I can easily see somebody feeling that > he'd like autovacuums to fail rather than block on locks for a long > time, for example. What I can see happening is someone setting this GUC in postgresql.conf and then being surprised that it applied to thinks like walreceiver and autovacuum, in addition to user queries. Are we even sure that that code would all behave sanely with this behavior? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] lock_timeout GUC patch
Robert Haas writes: > On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote: >> I would like a mini-review on the change I made in the latest >> patch by introducing the validator function. Is it enough >> to check for >> (source == PGC_S_DEFAULT || source == PGC_S_SESSION) >> to ensure only interactive sessions can get lock timeouts? > I'm not sure that I know how this should work, but that approach seems > a little strange to me. Why would we not allow PGC_S_USER, for > example? Why is this a good idea at all? I can easily see somebody feeling that he'd like autovacuums to fail rather than block on locks for a long time, for example. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
>one idea could be to actually prepare a query using SPI for "select * from
>table order by " and then peek inside
> to see which plan was generated.
I like that!!!
Here's a first attempt, it looks like it's working...
(I still have to skip non-btree indexes and expression indexes, plus
add a ASC/DESC to the select)
static bool use_index_scan(Relation OldHeap, Oid indexOid)
{
HeapTupleindexTuple;
Form_pg_index indexForm;
struct _SPI_plan *spiPlan;
char st[(NAMEDATALEN+1)*INDEX_MAX_KEYS+NAMEDATALEN+100];
int i;
TupleDescoldTupDesc;
bool retval = true;
PlannedStmt *plan;
CachedPlanSource *cps;
oldTupDesc = RelationGetDescr(OldHeap);
sprintf(st, "select * from %s order by ", OldHeap->rd_rel->relname.data);
indexTuple = SearchSysCache(INDEXRELID, ObjectIdGetDatum(indexOid),0, 0, 0);
if (!HeapTupleIsValid(indexTuple))
elog(ERROR, "cache lookup failed for index %u", indexOid);
indexForm = (Form_pg_index) GETSTRUCT(indexTuple);
for (i = 0; i < indexForm->indnatts; i++)
{
strcat(st, oldTupDesc->attrs[indexForm->indkey.values[i]-1]->attname.data);
if (i+1 < indexForm->indnatts)
{
strcat(st, ",");
}
}
ReleaseSysCache(indexTuple);
if (SPI_connect() != SPI_OK_CONNECT)
return false;
spiPlan = SPI_prepare(st, 0, NULL);
if (spiPlan == NULL)
{
SPI_finish();
return false;
}
cps = (CachedPlanSource*)(list_head(spiPlan->plancache_list)->data.ptr_value);
plan = (PlannedStmt*)(list_head(cps->plan->stmt_list)->data.ptr_value);
if (IsA(plan->planTree, Sort))
{
retval = false;
}
SPI_freeplan(spiPlan);
SPI_finish();
return retval;
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming Replication and archiving
Greg Stark wrote: > What would be useful is a tool which given a list of standby > databases and list of base backup images can apply a set of policy > rules to determine which base backups and archived logs to delete. > > The policy might look something like "keep one base backup per > week going back a month and one per day going back seven days and > keep archived logs going back far enough for any of these base > backups or any of these live replicas." > > Bonus points if you can say "also keep one base backup per month > going back three years with just enough archived logs to recover > the base backup to a consistent state". Hmmm... Our policy is "Keep the most recent base backup and all WAL files from the point needed to use it to current on the backup server local to the source database, keep the most recent two weekly backups and all the WAL files from the point needed to start the earlier to current on the central backup server (along with a warm standby instance running for each source to confirm that the backup and WAL files are usable), and keep the first weekly backup of each month and just enough WAL files for a consistent start of each on a mirrored SAN archive for one year." Just in case you're looking for real-life policies currently in use. By the way, the .backup files and the information from pg_controldata and pg_ctl status currently provide just enough information for this all to be run from bash scripts without much human attention, but the effort required to get there is far from trivial. I'm sure that something which made such a policy easy to implement would be useful to some shops. Hopefully that can be done without breaking current scripts. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
Takahiro Itagaki writes: > * I'd prefer to separate cost calculation routines from create_index_path() >and cost_sort(), rather than using a dummy planner. Don't go that way. The cost functions have enough dependencies on low-level planner functionality that making them be standalone would be a serious mess, both immediately and in terms of future maintenance. (As an example, someday we'll probably get around to having cost_sort actually look at the specific columns being sorted by, and that's going to involve a lot of interaction with pathkeys.) What I do think is that the quoted code snippet has no business being outside the planner proper. It'd be better to put it in planner.c or someplace like that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
9.0. You don't have a code-name. All the cool kids have code-names for their projects. Black Dog yup, I'm a zeppelin fan :) -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] attoptions
On Thu, Jan 21, 2010 at 07:30, Robert Haas wrote: > On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker wrote: >> Seems to me a comment about the above might be nice. Something like >> /* Things after here are should always be default null */ in >> pg_attribute.h ? > > Well... that wouldn't actually be a correct summary, so no. The point > is that variable-length fields are not used in tuple descriptors. > I'll add a comment about that. Yes that sounds much better, I was struggling to find the words. What I was trying to express was something along the lines of you cant have a non null value after these because you cant statically initialize them in genbki. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
Andrew Dunstan wrote: > "Bullwinkle" (This time for sure!) LOL But that trick never works... http://www.youtube.com/watch?v=e7mmrF-4rUE -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] lock_timeout GUC patch
On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote: > Thanks. So it means that this patch will considered for 9.1. Yeah, I think that's best. > I would like a mini-review on the change I made in the latest > patch by introducing the validator function. Is it enough > to check for > (source == PGC_S_DEFAULT || source == PGC_S_SESSION) > to ensure only interactive sessions can get lock timeouts? > This way autovacuum, replication and any other internal > processes get proper behaviour, i.e. the setting from > postgresql.conf is ignored and locks don't timeout for them. > Which other PGC_S_* settings can or must be enabled? I'm not sure that I know how this should work, but that approach seems a little strange to me. Why would we not allow PGC_S_USER, for example? Also, does this mean that if the setting is present in postgresql.conf, autovacuum will fail to start? It seems to me that rather than trying to restrict the PGC_S_* types for which this can be set, we should be trying to make the "internal processes" ignore the GUC altogether. I'm not sure if there's a clean way to do that, though. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] quoting psql varible as identifier
On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas wrote: > On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote: >> Robert Haas writes: >>> I'd like to proceed by committing an initial patch which changes the >>> "Escaping Strings for Inclusion in SQL Commands" to use a >>> with one per function (as we do in >>> surrounding functions) and consolidates it with the following section, >>> "Escaping Binary Strings for Inclusion in SQL Commands". Then I'll >>> submit a patch implementing pqEscapeLiteral() and pqEscapeIdentifier() >>> as discussed here, and the doc diff hunks will actually be readable. >> >> Sounds like a plan. > > Initial commit done, and follow-on patch attached. The docs took > longer to write than the code. I spent a fair amount of time trying > to make it all make sense, but suggestions are welcome. Committed after fixing a couple of oversights in my doc changes. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
