Re: [HACKERS] hstore == and deprecate =
On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Btw., the SQL standard also defines - for something else, so if you wanted to be really visionary, you could deprecate that one as an operator at the same time. Ouch. What does it define it to mean? Similar to C: Dereferencing a reference and accessing a member. But a reference would be a datatype no? So we could just regard that as an ordinary operator. I don't see a reason why it would conflict with use of the same operator name for other datatypes (unlike the situation with =). The right side of the - would be an identifier, like (some expr yielding a ref)-attribute or objref-method(args) -- 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] pg_upgrade output directory
On Sat, Jun 12, 2010 at 4:58 AM, Bruce Momjian br...@momjian.us wrote: However, I might have been too conservative. How do tools that generate multiple output files usually handle this situation? Do they output in to a subdirectory in $HOME, or in a subdirectory of the current directory, or just create multiple files without a subdirectory? Generally they put them in the current directory without subdirectories but take a parameter to specify a directory to use. That parameter could be mandatory though if you're afraid the current directory isn't a suitable place. -- greg -- 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] Proposal for 9.1: WAL streaming from WAL buffers
On Jun 12, 2010, at 3:10 , Josh Berkus wrote: Hm, but then Robert's failure case is real, and streaming replication might break due to an OS-level crash of the master. Or am I missing something? 1) Master goes out 2) floating transaction applied to standby. 3) Standby goes out 4) Power back on 5) master comes up 6) standby comes up It seems like, in that sequence, the standby would have one transaction which the master doesn't have, yet the standby thinks it can continue getting WAL from the master. Or did I miss something which makes this impossible? I did indeed miss something - with wal_sync_method set to either open_datasync or open_sync, all written WAL is also synced. Since open_datasync is the preferred setting according to http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#GUC-WAL-SYNC-METHOD, systems supporting open_datasync should be safe. My Ubuntu 10.04 box running postgres 8.4.4 doesn't support open_datasync though, and hence defaults to fdatasync. Probably because of this fragment in xlogdefs.h #if O_DSYNC != BARE_OPEN_SYNC_FLAG #define OPEN_DATASYNC_FLAG (O_DSYNC | PG_O_DIRECT) #endif glibc defines O_DSYNC as an alias for O_SYNC and warrants that with Most Linux filesystems don't actually implement the POSIX O_SYNC semantics, which require all metadata updates of a write to be on disk on returning to userspace, but only the O_DSYNC semantics, which require only actual file data and metadata necessary to retrieve it to be on disk by the time the system call returns. If that is true, I believe we should default to open_sync, not fdatasync if open_datasync isn't available, at least on linux. best regards, Florian Pflug -- 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] hstore == and deprecate =
Peter Eisentraut pete...@gmx.net writes: On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote: But a reference would be a datatype no? So we could just regard that as an ordinary operator. I don't see a reason why it would conflict with use of the same operator name for other datatypes (unlike the situation with =). The right side of the - would be an identifier, like (some expr yielding a ref)-attribute or objref-method(args) Yeah, but the *left* side still has to be a special datatype that doesn't exist today. So we have at least some chance of not usurping existing usages of the operator name. In principle you could have transformAExprOp transform the left side and then check for this case before trying to transform the right side. (And in any case, I haven't noticed anybody expressing any interest in implementing that part of the spec.) But actually, there's another issue here: hstore defines not one but three = operators: text = textyields hstore (with 1 element) text[] = text[]yields hstore (with N elements) hstore = text[]yields hstore (subset) It's reasonable to say that the first two are bad design, but I'm a bit less willing to say that the last one is. What shall we do with 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] hstore == and deprecate =
On Jun 12, 2010, at 14:57 , Tom Lane wrote: But actually, there's another issue here: hstore defines not one but three = operators: text = textyields hstore (with 1 element) text[] = text[]yields hstore (with N elements) hstore = text[]yields hstore (subset) It's reasonable to say that the first two are bad design, but I'm a bit less willing to say that the last one is. What shall we do with that? Hm, the last one seems to be more akin to hstore - textyields hstore (key removed) hstore - text[] yields hstore (keys in array removed) hstore - hstore yields hstore (keys in hstore removed) since it's not a constructor like the first two, but rather an (intersection-like) operation on an existing hstore. Inspired by the already existing hstore ? text[] yields boolean (true if set of keys subset of array) I suggest hstore text[] as a replacement. best regards, Florian Pflug -- 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 to show individual statement latencies in pgbench output
Hi To be able to asses the performance characteristics of the different wal-related options, I patched pgbench to show the average latency of each individual statement. The idea is to be able to compare the latency of the COMMIT with the ones of the other statements. This patch adds two new finds to the Command struct, elapsed and cnt, which accumulate the total time spent on each statement and the number of times it was executed. printResults essentially prings elapsed/cnt for each statement, followed by the statement itself. Patch is attached. best regards, Florian Pflug pgbench_statementlatency.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] Idea for getting rid of VACUUM FREEZE on cold pages
Greg Stark wrote: On Thu, Jun 3, 2010 at 11:41 AM, Greg Stark gsst...@mit.edu wrote: I think to make it work you need to store a whole 64-bit reference transaction id consisting of both a cycle counter and a transaction id. The invariant for the page is that every xid on the page can be compared to that reference transaction id using normal transactionid semantics. Actually I think the easiest way to do that is to set it to the oldest xid on the page. The first thing to do before comparing any transaction id on the page with a real transaction id would be to figure out whether the reference xid is comparable to the live xid, which if it's the oldest xid on the page implies they'll all be comparable. The way to maintain that invariant would be that any xid insertion on the page must advance the reference xid if it's not comparable to the newly inserted xid. It has to be advanced to the oldest xid that's still comparable with the newly inserted xid. Any xids on the page that are older than the new refernce xid have to be frozen or removed. I'm not sure how to do that without keeping clog forever though. So the more I think about this the more I think it's unavoidable that we would need to retain clog forever. I think the goal here is to be able to load data into the database and then never write the data ever again. Even if you visit the page years later after the transaction ids have wrapped around several times. In that case there's no avoiding that you'll need to know whether that transaction committed or aborted. I think we might need two bits, one commited and all visible, and another aborted and all vislble. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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] hstore == and deprecate =
On Jun 11, 2010, at 2:23 PM, Tom Lane wrote:
hstore(key := 'this', key2 := 'that')
hstore(key = 'this', key2 = 'that')
hstore(row('this' AS key, 'that' AS key2))
The last of those is probably the easiest to get to. We already have
hstore_from_record:
Is not the first one simply a function with any number of named params?
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] hstore == and deprecate =
On Jun 12, 2010, at 7:15 AM, Florian Pflug wrote: It's reasonable to say that the first two are bad design, but I'm a bit less willing to say that the last one is. What shall we do with that? Hm, the last one seems to be more akin to hstore - textyields hstore (key removed) hstore - text[] yields hstore (keys in array removed) hstore - hstore yields hstore (keys in hstore removed) Well, no, the keys aren't removed: you get back an hstore with only those keys (the lhs is unchanged). since it's not a constructor like the first two, but rather an (intersection-like) operation on an existing hstore. Inspired by the already existing hstore ? text[] yields boolean (true if set of keys subset of array) I suggest hstore text[] as a replacement. Yes, agreed. That just leaves text[] = text[]yields hstore (with N elements) Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an hstore(text[], text[]) 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] Idea for getting rid of VACUUM FREEZE on cold pages
Bruce Momjian br...@momjian.us writes: I think we might need two bits, one commited and all visible, and another aborted and all vislble. Huh? The latter means vacuumable. 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] hstore == and deprecate =
David E. Wheeler da...@kineticode.com writes:
On Jun 11, 2010, at 2:23 PM, Tom Lane wrote:
hstore(key := 'this', key2 := 'that')
hstore(key = 'this', key2 = 'that')
hstore(row('this' AS key, 'that' AS key2))
The last of those is probably the easiest to get to. We already have
hstore_from_record:
Is not the first one simply a function with any number of named params?
No, because the desire presumably would be to be able to use any set of
parameter names with that one function ... which absolutely flies in the
face of our current notion of what a parameter name means. You'd
essentially have to disable the ability to have function overloading.
(Which probably means it Ain't Happening.)
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] pg_upgrade output directory
Greg Stark wrote: On Sat, Jun 12, 2010 at 4:58 AM, Bruce Momjian br...@momjian.us wrote: However, I might have been too conservative. ?How do tools that generate multiple output files usually handle this situation? ?Do they output in to a subdirectory in $HOME, or in a subdirectory of the current directory, or just create multiple files without a subdirectory? Generally they put them in the current directory without subdirectories but take a parameter to specify a directory to use. That parameter could be mandatory though if you're afraid the current directory isn't a suitable place. Agreed. I have applied the attached patch which creates the files in the current directory. I think that will be fine and don't see any need for a directory parameter. I have kept the printing of the full path name in the output: Upgrade complete | Optimizer statistics is not transferred by pg_upgrade | so consider running: | vacuumdb --all --analyze-only | on the newly-upgraded cluster. | Running this script will delete the old cluster's data files: | /u/pg_migrator/pg_migrator/delete_old_cluster.sh I figured this would be helpful for people on Windows who might not know the actual directory used for the files. However, it does make the display kind of wide. Ideas? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + Index: contrib/pg_upgrade/check.c === RCS file: /cvsroot/pgsql/contrib/pg_upgrade/check.c,v retrieving revision 1.5 diff -c -c -r1.5 check.c *** contrib/pg_upgrade/check.c 23 May 2010 16:54:13 - 1.5 --- contrib/pg_upgrade/check.c 12 Jun 2010 17:01:23 - *** *** 381,387 prep_status(ctx, Creating script to delete old cluster); snprintf(*deletion_script_file_name, MAXPGPATH, %s/delete_old_cluster.%s, ! ctx-output_dir, EXEC_EXT); if ((script = fopen(*deletion_script_file_name, w)) == NULL) pg_log(ctx, PG_FATAL, Could not create necessary file: %s\n, --- 381,387 prep_status(ctx, Creating script to delete old cluster); snprintf(*deletion_script_file_name, MAXPGPATH, %s/delete_old_cluster.%s, ! ctx-cwd, EXEC_EXT); if ((script = fopen(*deletion_script_file_name, w)) == NULL) pg_log(ctx, PG_FATAL, Could not create necessary file: %s\n, Index: contrib/pg_upgrade/dump.c === RCS file: /cvsroot/pgsql/contrib/pg_upgrade/dump.c,v retrieving revision 1.1 diff -c -c -r1.1 dump.c *** contrib/pg_upgrade/dump.c 12 May 2010 02:19:10 - 1.1 --- contrib/pg_upgrade/dump.c 12 Jun 2010 17:01:23 - *** *** 21,27 exec_prog(ctx, true, SYSTEMQUOTE \%s/pg_dumpall\ --port %d --schema-only --binary-upgrade \%s/ ALL_DUMP_FILE \ SYSTEMQUOTE, ! ctx-new.bindir, ctx-old.port, ctx-output_dir); check_ok(ctx); } --- 21,27 exec_prog(ctx, true, SYSTEMQUOTE \%s/pg_dumpall\ --port %d --schema-only --binary-upgrade \%s/ ALL_DUMP_FILE \ SYSTEMQUOTE, ! ctx-new.bindir, ctx-old.port, ctx-cwd); check_ok(ctx); } *** *** 52,64 char filename[MAXPGPATH]; bool suppressed_username = false; ! snprintf(filename, sizeof(filename), %s/%s, ctx-output_dir, ALL_DUMP_FILE); if ((all_dump = fopen(filename, r)) == NULL) pg_log(ctx, PG_FATAL, Cannot open dump file %s\n, filename); ! snprintf(filename, sizeof(filename), %s/%s, ctx-output_dir, GLOBALS_DUMP_FILE); if ((globals_dump = fopen(filename, w)) == NULL) pg_log(ctx, PG_FATAL, Cannot write to dump file %s\n, filename); ! snprintf(filename, sizeof(filename), %s/%s, ctx-output_dir, DB_DUMP_FILE); if ((db_dump = fopen(filename, w)) == NULL) pg_log(ctx, PG_FATAL, Cannot write to dump file %s\n, filename); current_output = globals_dump; --- 52,64 char filename[MAXPGPATH]; bool suppressed_username = false; ! snprintf(filename, sizeof(filename), %s/%s, ctx-cwd, ALL_DUMP_FILE); if ((all_dump = fopen(filename, r)) == NULL) pg_log(ctx, PG_FATAL, Cannot open dump file %s\n, filename); ! snprintf(filename, sizeof(filename), %s/%s, ctx-cwd, GLOBALS_DUMP_FILE); if ((globals_dump = fopen(filename, w)) == NULL) pg_log(ctx, PG_FATAL, Cannot write to dump file %s\n, filename); ! snprintf(filename, sizeof(filename), %s/%s, ctx-cwd, DB_DUMP_FILE); if ((db_dump = fopen(filename, w)) == NULL) pg_log(ctx, PG_FATAL, Cannot write to dump file %s\n, filename); current_output = globals_dump; Index: contrib/pg_upgrade/function.c === RCS file: /cvsroot/pgsql/contrib/pg_upgrade/function.c,v retrieving revision 1.2 diff -c -c -r1.2 function.c ***
Re: [HACKERS] hstore == and deprecate =
David E. Wheeler da...@kineticode.com writes: Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an hstore(text[], text[]) Oh --- now that I look, both that and the hstore = text[] one are new in 9.0, which means it is not too late to reverse course. So at this point the proposal is: * Leave the text = text operator alone for now, but deprecate it, and document/recommend the underlying hstore(text,text) function instead. * Get rid of the new text[] = text[] operator altogether, and provide/document only the underlying hstore(text[], text[]) function. * Rename the new hstore = text[] operator to something else. (I'm not quite sold on Florian's proposal, but don't have a better idea to offer offhand.) I notice that in 8.4 and before, the function underlying text = text wasn't called hstore() but tconvert(). Which is going to be a serious PITA for anyone who wants to write cross-version-compatible SQL using hstore. Can we do anything about this? I don't think we want to revert to calling it tconvert(). Can we retroactively add the alternate name hstore() to previous versions, and suggest that people do that manually in existing hstore installations? 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] pg_regress --use-existing does not appear in --help
Jan Urba??ski wrote: Hi, per $SUBJECT. Applied. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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] hstore == and deprecate =
Tom Lane wrote: I notice that in 8.4 and before, the function underlying text = text wasn't called hstore() but tconvert(). Which is going to be a serious PITA for anyone who wants to write cross-version-compatible SQL using hstore. Can we do anything about this? I don't think we want to revert to calling it tconvert(). Can we retroactively add the alternate name hstore() to previous versions, and suggest that people do that manually in existing hstore installations? In general, I don't think we make enough use of supplying backward-compatible SQL scripts to fix things, so +1. Let's use the object-relational features we have to make things easier for users. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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] hstore == and deprecate =
On Jun 12, 2010, at 10:21 AM, Tom Lane wrote: David E. Wheeler da...@kineticode.com writes: Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an hstore(text[], text[]) Oh --- now that I look, both that and the hstore = text[] one are new in 9.0, which means it is not too late to reverse course. So at this point the proposal is: * Leave the text = text operator alone for now, but deprecate it, and document/recommend the underlying hstore(text,text) function instead. * Get rid of the new text[] = text[] operator altogether, and provide/document only the underlying hstore(text[], text[]) function. * Rename the new hstore = text[] operator to something else. (I'm not quite sold on Florian's proposal, but don't have a better idea to offer offhand.) +1 I notice that in 8.4 and before, the function underlying text = text wasn't called hstore() but tconvert(). Which is going to be a serious PITA for anyone who wants to write cross-version-compatible SQL using hstore. Can we do anything about this? I don't think we want to revert to calling it tconvert(). Can we retroactively add the alternate name hstore() to previous versions, and suggest that people do that manually in existing hstore installations? +1 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] Command to prune archive at restartpoints
Dimitri Fontaine dfonta...@hi-media.com writes: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: So to clean up all WAL files older than those needed by that base backup, you would simply copy-paste that location and call pg_cleanuparchive: pg_cleanuparchive /walarchive/ 0001002F Ok, idle though: what about having a superuser-only SRF doing the same? So I'm looking at what it'd take to have that code, and it seems it would be quite easy. I wonder if we want to return only a boolean (command success status) or the list of files we're pruning (that's the SRF part), but other than that, it's all about having the code provided by Simon in another place and some internal command support. Something strange though: I notice that the error and signal handling in pgarch.c::pgarch_archiveXlog (lines 551 and following) and in xlog.c::ExecuteRecoveryCommand (lines 3143 and following) are very different for no reason that I can see. Why is that? Also, should I try to send a patch implementing my proposal (internal command exposed as a function at the SQL level, and while at it, maybe the internal command pg_archive_bypass to mimic /usr/bin/true as an archive_command)? Regards, -- 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] Command to prune archive at restartpoints
Dimitri Fontaine dfonta...@hi-media.com writes:
Also, should I try to send a patch implementing my proposal (internal
command exposed as a function at the SQL level, and while at it, maybe
the internal command pg_archive_bypass to mimic /usr/bin/true as an
archive_command)?
I had to have a try at it, even if quick and dirty. I've not tried to
code the pg_archive_bypass internal command for lack of discussion, but
I still think it would be great to have it.
So here's a see my idea in code patch, that put the previous code by
Simon into a backend function. As the goal was not to adapt the existing
code intended as external to use the internal APIs, you'll find it quite
ugly I'm sure.
For example, this #define XLOG_DATA_FNAME_LEN has to go away, but that
won't help having the idea accepted or not, and as I'm only warming up,
I didn't tackle the problem. If you want me to do it, I'd appreciate
some guidance as how to, though.
It goes like this:
dim=# select pg_switch_xlog();
pg_switch_xlog
0/198
(1 row)
dim=# select pg_archive_cleanup('0/198');
DEBUG: removing pg_xlog/0001
DEBUG: removing pg_xlog/00010001
pg_archive_cleanup
t
(1 row)
I hope you too will find this way of interfacing is easier to deal with
for everybody (from code maintenance to user settings).
Regards,
--
dim
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
***
*** 599,605 static bool read_backup_label(XLogRecPtr *checkPointLoc);
static void rm_redo_error_callback(void *arg);
static int get_sync_bit(int method);
-
/*
* Insert an XLOG record having the specified RMID and info bytes,
* with the body of the record being the data chunk(s) described by
--- 599,604
***
*** 3056,3062 not_available:
}
/*
! * Attempt to execute an external shell command during recovery.
*
* 'command' is the shell command to be executed, 'commandName' is a
* human-readable name describing the command emitted in the logs. If
--- 3055,3065
}
/*
! * Attempt to execute an external shell command during recovery, or an
! * internal one if given one.
! *
! * There's only one supported internal commands today, which is named
! * pg_archive_cleanup.
*
* 'command' is the shell command to be executed, 'commandName' is a
* human-readable name describing the command emitted in the logs. If
***
*** 3094,3145 ExecuteRecoveryCommand(char *command, char *commandName, bool failOnSignal)
LWLockRelease(ControlFileLock);
/*
! * construct the command to be executed
*/
! dp = xlogRecoveryCmd;
! endp = xlogRecoveryCmd + MAXPGPATH - 1;
! *endp = '\0';
! for (sp = command; *sp; sp++)
{
! if (*sp == '%')
{
! switch (sp[1])
{
! case 'r':
! /* %r: filename of last restartpoint */
! sp++;
! StrNCpy(dp, lastRestartPointFname, endp - dp);
! dp += strlen(dp);
! break;
! case '%':
! /* convert %% to a single % */
! sp++;
! if (dp endp)
! *dp++ = *sp;
! break;
! default:
! /* otherwise treat the % as not special */
! if (dp endp)
! *dp++ = *sp;
! break;
}
}
! else
! {
! if (dp endp)
! *dp++ = *sp;
! }
! }
! *dp = '\0';
! ereport(DEBUG3,
! (errmsg_internal(executing %s \%s\, commandName, command)));
- /*
- * execute the constructed command
- */
- rc = system(xlogRecoveryCmd);
if (rc != 0)
{
/*
--- 3097,3164
LWLockRelease(ControlFileLock);
/*
! * if the command is internal, call the function
*/
! if( strcmp(command, pg_archive_cleanup) == 0 )
! {
! text *restart_filename = cstring_to_text(lastRestartPointFname);
! rc = DatumGetBool(DirectFunctionCall1(pg_archive_cleanup,
! restart_filename)) ? 0 : 1;
! ereport(DEBUG3,
! (errmsg_internal(calling %s \%s\, commandName, command)));
! }
! else
{
! /*
! * construct the command to be executed
! */
! dp = xlogRecoveryCmd;
! endp = xlogRecoveryCmd + MAXPGPATH - 1;
! *endp = '\0';
!
! for (sp = command; *sp; sp++)
{
! if (*sp == '%')
{
! switch (sp[1])
! {
! case 'r':
! /* %r: filename of last restartpoint */
! sp++;
! StrNCpy(dp, lastRestartPointFname, endp - dp);
! dp += strlen(dp);
! break;
! case '%':
! /* convert %% to a single % */
! sp++;
! if (dp endp)
! *dp++ = *sp;
! break;
! default:
! /* otherwise treat the % as not special */
! if (dp endp)
! *dp++ = *sp;
! break;
! }
! }
! else
! {
! if (dp endp)
! *dp++ = *sp;
}
}
! *dp = '\0';
! ereport(DEBUG3,
! (errmsg_internal(executing %s \%s\, commandName, command)));
!
! /*
! * execute the constructed command
! */
! rc = system(xlogRecoveryCmd);
! }
[HACKERS] Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?
Alvaro Herrera wrote: Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010: Yes, the folks at commandprompt need to be told about this. Loudly. It's a serious packaging error. Just notified Lacey, the packager (not so loudly, though); she's working on new packages, and apologizes for the inconvenience. [ Thread moved to hackers. 8.4.4 RPMs were built with debug flags. ] Uh, where are we on this? Has it been completed? How are people informed about this? Do we need to post to the announce email list? Does Yum just update them? How did this mistake happen? How many days did it take to detect the problem? Why has no news been posted here? https://public.commandprompt.com/projects/pgcore/news -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] It's possible to get pg_class oid from GETSTRUC macro?
After i read PostgreSQL documentation, i found that pg_attribute contain
attrelid that reference to pg_class oid. But after i look to
/src/include/catalog/pg_class.h there is no member named oid.
This what i trying to acomplish using heap_getnext function:
if (((Form_pg_class) GETSTRUCT(ht_1)-oid) == ((Form_pg_attribute)
GETSTRUCT(ht_2)-attrelid)
{
//do something
}
But its always failed in compile time since pg_class doesnt have oid
member. And it seem t_tableOid was not pg_class oid since when i
compare t_tableOid and (Form_pg_attribute) GETSTRUCT(ht_2)-attrelid
nothing match.
My question is, how to get oid from pg_class? or is there any other
solution you can suggest?
Thank you.
--
Mohammad Heykal Abdillah heykal.abdil...@gmail.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] It's possible to get pg_class oid from GETSTRUC macro?
On 13/06/10 15:28, Mohammad Heykal Abdillah wrote:
After i read PostgreSQL documentation, i found that pg_attribute contain
attrelid that reference to pg_class oid. But after i look to
/src/include/catalog/pg_class.h there is no member named oid.
This what i trying to acomplish using heap_getnext function:
if (((Form_pg_class) GETSTRUCT(ht_1)-oid) == ((Form_pg_attribute)
GETSTRUCT(ht_2)-attrelid)
{
//do something
}
But its always failed in compile time since pg_class doesnt have oid
member. And it seem t_tableOid was not pg_class oid since when i
compare t_tableOid and (Form_pg_attribute) GETSTRUCT(ht_2)-attrelid
nothing match.
My question is, how to get oid from pg_class? or is there any other
solution you can suggest?
Thank you.
Guess you could get the oid via:
HeapTupleGetOid(h_1);
regards
Mark
Re: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers
On 12/06/10 01:16, Josh Berkus wrote: Well, we're already not waiting for fsync, which is the slowest part. If there's a performance problem, it may be because FADVISE_DONTNEED disables kernel buffering so that we're forced to actually read the data back from disk before sending it on down the wire. Well, that's fairly direct to solve, no? Just disable FADVISE_DONTNEED if walsenders 0. We already do that. -- 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
